If you followed the instructions and your disk won't boot, the first step is to determine where the boot is failing. In general, the further along it gets the easier it is to diagnose (though not necessarily to fix!). These steps are arranged more-or-less chronologically.
configure
script, but Yard relieson many external programs which are continually changing.
$device
and Yard
produces the error:
Error: You've declared file system size ($fs_size) to be 4096 K
but Linux says /dev/ram0 may only hold 0 K
Check your /etc/lilo.conf
file for a line like:
ramsize = 0
and increase it to something more reasonable, like 4096.
Remember to run lilo and reboot.
make_root_fs
from the sys()
complaining that a directory doesn't exist, this may be what is
happening. I don't know why this happens and I can't reproduce it
consistently. If it happens, try unmounting, deleting and re-creating
the file. This seems to get rid of the problem.
In the normal boot process you will see a message sequence like:
LILO loading floppylinux...
Uncompressing...done
Now booting the kernel
If the sequence halts or displays an error somewhere in this sequence, the problem is with LILO.
Not necessarily in LILO, but with LILO.With some exotic floppy disk geometries (usually involving disk capacities greater than 1440K) LILO's map compaction won't work, causing the LILO boot sequence to halt. If LILO halts and you're using a non-1440K floppy, this is likely the problem.
The fix is to set $LILO_COMPACT
to zero in
Config.pl and run Yard again. This will simply turn off LILO's map
compaction which should fix the problem (although kernel loading will slow
down considerably).
If that doesn't work, switch to a 1440K floppy and try again. If you really want to puzzle it out, go read the section ``Disk Geometry'' in LILO's README file -- and good luck.
If 1440K doesn't work, something is very broken. Make sure LILO has been installed correctly. If you don't normally use LILO to boot, re-install a recent version. As a last resort, remake your kernel with ``make mrproper''.
If you're using a double-disk rescue set, both floppies must be formatted identically. The boot loader becomes confused otherwise.
If the loader tells you it can't find a compressed root image, make
sure you gave Yard the correct floppy device (eg,
/dev/fd0H1722
for 1722K). If you've constructed a
single-disk rescue set and it prompts you to insert a root floppy
disk, that's probably a Yard problem (the rdev in
write_rescue_disk has failed for some reason and the
failure wasn't caught by Yard). Go back and look over
write_rescue_disk.log to make sure nothing failed.
If you get a message like:
Id xxx respawning too fast: disabled for n minutes
it's coming from init, usually indicating that your *getty*
The notation *getty* will be used to mean some getty-like program, eg getty, agetty, mgetty or getty_ps.or login is dying as soon as it starts up. Check the *getty* and login executables, and the libraries they depend upon. Make sure the invocations in /etc/inittab are correct.
If halting occurs after the root filesystem is loaded, the
problem is in Yard or in you. The first step is to check
write_rescue_disk.log
to make sure nothing failed.
If you ignored warnings from make_root_fs
or
check_root_fs
, look at them again. You should
probably look over all three log files to make sure things are as they
should be. make_root_fs.log
has a listing of where
each file was taken from -- make sure all your system files are coming
from the right places on your hard disk.
If you get strange messages from *getty*, it may mean the calling form
in /etc/inittab
is wrong. check_root_fs
does not perform much inittab call checking because the options are so
variable among the different *getty* programs
Different versions of agetty are reported to have different incompatible calling forms.. If you're using a different call and/or program from what you use in your hard disk
/etc/inittab
, double
check it.
When you login, you may get errors about commands that aren't present. This usually happens when an rc file uses a builtin command that does not exist in the rescue disk's shell, but did exist in the shell used to run Yard.
Check the Yard webpage:
http://www.cs.umass.edu/~fawcett/yard/
On that page I'll put notes which people have sent me about problems they've run into, before I've had a chance to fix and re-release Yard.
If you find a problem that that Yard didn't catch, but which it could have caught, please let me know and I'll try to add a check to check_root_fs.
If you think it's a Yard problem, you can try diagnosing it yourself. In fact, you may have better luck since you're more familiar with your setup. Otherwise, package up the three .log files along with your Bootdisk_Contents, Config.pl and Bootdisk_Contents.ls and send them to me with a reasonable description of what went wrong. This command should work:
tar cvzf yard_bug.tgz *.log *.ls Bootdisk_Contents Config.pl
Be sure to let me know what version you're using. You might check the yard webpage to make sure there isn't already a newer version of Yard that fixes your problem, or a note added there.