|
|
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: |
|
| ||||||||