![]() |
![]() ![]() My system can't find the bootstrap.conf file |
Probably the most common problem faced by users setting up MkLinux boxes
is the failure of the system to find the bootstrap.conf file. This document
attempts to cover the most common causes of this problem. It is divided into
two broad sections: the general hardware problems section and the version-
specific section. Please note that this is by no means a complete list of causes. Please add anything else you find to the appropriate section.
David A. Gatwood
| |
Subcategories: Answers in this category: | |
Release-specific problems: DR3 (and pre-DR3): Installer: The most frequent causes of bootstrap.conf not found messages when working with the RedHat Installer (pre-DR3 and DR3) are: 1. an attempt to use an HFS+ partition (you must use standard HFS, _NOT_ HFS+). 2. specifying the wrong partition number in lilo.conf -- remember, adding partitions may cause numbering changes. 3. not specifying the partition number at all in lilo.conf 4. specifying the wrong drive letter, or specifying it as if you were using the DR2.1 numbering. See SCSI numbering below. 5. attempting to use a drive on a SCSI controller card. 6. miscellaneous problems with IDE drive booting (see hardware section). 7. miscellaneous problems with Quantum Fireball drives in certain hardware configurations (see hardware section). SCSI Numbering: If you are used to using DR2.1, you should note that the SCSI numbering changed between update 6 and pre-DR3. The partition number should be the same, but the letter for the drive is different. With pre-DR3 (and a few wip's before dr3alpha1), sda is the first drive on the first bus, sdb is the next drive, etc. until you run out of drives on that bus, followed by the drives on the next bus, etc. It should be noted that the majority of systems have only one usable bus (i.e. not cards). The exceptions are some varieties of 8100, the {7,8,9}500, {7,8,9}600, and possibly the 7300 (and clones of these systems). On systems with multiple busses, bus 0 is the internal bus, and bus 1 is the internal/external bus. If you find this too confusing (probably badly written), download a _current_ version of pdisk (you should be able to find it at ftp://ftp.mklinux.apple.com/pub/wip/pdisk ) and use that to determine both the correct drive letter and partition number. DR2.1: Under DR2.1, the SCSI numbering (lettering?) system is as follows: sdx# where x is... a -- SCSI ID 0 b -- SCSI ID 1 etc. Drives should not occupy the same SCSI ID, even on different busses, as one of them will not show up. This is one possible cause of bootstrap.conf not being readable, as is simply incorrectly choosing the letter. The number portion of the drive's number is the partition number. Be careful, since different partitioners give this number in different ways (some don't count the driver partition, etc.). If all else fails, download pdisk (from ftp.mklinux.apple.com) and ask it for the partition numbers. | |
General Hardware and Kernel Problems: 7500/7600: Users with the factory drive at SCSI ID 0 on the internal bus may not be able to boot from that drive. To find out if this is causing your boot problem, look for a line that says "MESH targets at: 0, 3". If you don't see your internal drive's SCSI ID number (normally 0), then your drive exhibits this problem. Two possible workarounds currently exist: either change the drive's SCSI ID, or move the drive to the (slower) internal/external bus (1). The first has the advantage of not degrading performance, but you'll have to find a jumper to bridge across two pins on the hard drive. For more information, see the FAQ-O-Matic entry on getting the PowerMac 7600/120 to boot (this applies equally to a very small number of 7500 and 7600/132 users as well). 7500/8500/9500: In some cases, certain drives will fail to work on these systems on the internal SCSI bus. This may or may not exhibit the same symptoms as the above. If you are using a current Mach Kernel and the system refuses to boot from your drive, try changing SCSI busses. To do this, simply fold the system open, unplug the SCSI cable from the motherboard and plug it into the connector right beside it. Machines with IDE Internal Drives: Desktop machines: New G3 desktop machines -- these machines have been reported to work by removing the internal IDE Zip drive. Also, be sure that the hard drive is on bus 0 and the CD-ROM drive is on bus 1. Apparently, at least in some cases, MkLinux will fail to start up if the drives are reversed. Swapping cables seems to fix this for some reason. Original G3 desktop machines It may be possible to boot these machines by swapping the hard drive and CD-ROM drive connectors. If, in booting, your system shows the internal hard drive at ide1 and the CD-ROM drive at ide0, reverse the cables on the backs of the two drives and try again. In general, though, these machines often require the SCSI disk workaround to boot MkLinux from an IDE drive. This usually manifests itself in the form of a signature error, followed by a complaint about partition n size zero. There are two workarounds currently known: 1. install on a different drive. This only impacts installations on IDE drives, and thus installing on (and from) a SCSI drive should avoid such problems. 2. partially install on a Zip cartridge or other SCSI drive -- see the "Zip Trick" at the bottom of this document. Other (603e) desktop machines with IDE drives: These machines may behave much like the original G3 desktop machines, and the "Zip Trick" may work. It should be noted that SCSI may not be supported on all systems. I'm not sure. Laptop machines: PowerBook support has improved dramatically recently, and this section attempts to reflect the changes. While some PowerBooks will boot with the stock Mach Kernel, several bugs in the adb handling code were worked around recently, and I've rolled all of the PowerBook-specific changes into a single test kernel. You can find this kernel at: ftp://globegate.utm.edu/pub/MkLinux/Mach_Kernel.powerbook.gz in addition, the test kernel without the PB2400-specific patches (very much a work-in-progress) is available as ...powerbook.gz.old just in case these changes cause problems for some other system (problems seem unlikely, and the current kernel works fine on my G3 laptop). additional information on various models is below. PB1400 Patches for PB1400 support were contributed by Andrew Fyfe (bandr@best.com). You can download the patches from: ftp://shell7.ba.best.com/pub/bandr/MkLinux-PB1400/ PB2400 This machine seems to have problems because of either a dangling or missing second IDE bus. I'm not sure which. This will result in a freeze during the hard drive probe. The current test kernel appears to allow partial support, though no complete successes have been reported. Please test this kernel, however, as your mileage may vary, and every problem report adds more information about the problems that remain. PB3400 This machine suffers similarly to the 2400 when the floppy drive is in the media bay (or with the bay empty). Inserting a CD-ROM drive instead seems to allow the machines to boot. This machine will boot with the stock kernel, but the PowerBook test kernel is recommended for stability reasons. PB5300 This machine appears to be broken in several respects, the most blatant of which is the lack of external SCSI support. I'm not familiar enough with the SCSI code (or indeed with the 5300) to speculate on why this is the case. Your mileage may vary.... PB G3 -- original This machine should boot (albeit with adb problems) even with the stock kernel. The PowerBook test kernel is still recommended for stability reasons. PB G3 Series This machine requires the PowerBook Test Kernel for booting off of the IDE drive. The stock kernel will not identify that any IDE drives/busses exist. Initial reports suggest that hard drives in the media bay will not be handled correctly (treated as CD-ROM drives) and won't be usable for install purposes, though it might be possible to use them for additional storage or for holding RPMS. As I have no media bay hard drive for mine, I'm not of much help on this one. Other PowerBooks: Various other PowerBooks have various problems. For instance, some machines have no external SCSI support. If you know the working/non-working status of machines not listed here or workarounds, etc. that should be listed here, please send me email at marsmail@globegate.utm.edu. Jaz Drives: Jaz drives may be the cause of unusual boot problems. This has been reported even in cases when the Jaz drive is not the boot drive. Some users have reported that inserting a cartridge before boot may prevent this behaviour. Internal Jaz drives seem to be particularly problematic (or more accurately, Jaz drives connected to the internal bus on dual- bus machines). Moving these to the external bus may prevent these problems in certain cases. Further, removable drives in general may show lots of "recovered errors". Some users have reported that turning off write verification may reduce these rather annoying messages. At this time, it is unclear what effect this may have on the integrity of data on the cartridges in question. Make such a change at your own risk. IBM Drives: Drives made by IBM may cause problems with the Mach Kernel's SCSI driver if target-initiated sync negotiation is turned on. If such a drive causes a kernel panic, try installing or removing the jumper marked TI from the drive and see if that fixes the problem. Also, some users have reported problems with certain IBM drives designed for SCSI-wide adapted down to normal SCSI when used on the internal SCSI bus of dual-bus machines. If you have such a drive and it causes kernel panics, try moving the drive to the external bus. "Zip Trick": This trick is designed for booting a handful of machines that, for whatever reason, have IDE drives whose contents cannot be read directly by the Mach Kernel (i.e. to read bootstrap.conf, etc.), but _are_ accessible once the vmlinux server starts up. The reason for this peculiar behavior is as yet unknown. Steps: 1. Place the installer on a zip cartridge, boot. 2. Install according to the instructions, on the IDE drive 3. Download a copy of the vmlinux server from your nearest DR3 mirror. This currently means to grab the file vmlinux.gz from within the latest wip directory (/pub/wip/98xxxx). 4. Decompress this as necessary with MacGzip or other utilities. 5. Place this vmlinux into the mach_servers folder on the zip cart. 6. Use BBedit or another program that understands Unix linefeeds to modify the bootstrap.conf file within the mach_servers folder (on the zip cartridge) as follows: a. Change the root device from /dev/ram to /dev/hda#, replacing # with the partition number of your root partition. b. Change the filename listed from vmlinux+installer to vmlinux c. Be sure to save with unix linefeeds. 7. Edit lilo.conf in your preferences folder (on whatever drive your computer is booting from). If it is set to boot from the ide drive (/dev/hda*), change it back to boot from the zip drive (the same value that it had for the install procedure). 8. Boot MkLinux.marsmail@globegate.utm.edu | |
If you get an error that states "Cannot set boot_device 'xxx'" be sure the partition you are refering to is not a HFS+ partition.tchnoalien@aol.com | |
[New Answer in "My system can't find the bootstrap.conf file"] |
Previous: |
![]() |
Next: |
![]() |
|