While compiling a new custom kernel (patched with the UnionFS) for my Slackware 12.0 install on a standard Pentium 4 I suddenly got the message:

"L 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99"

when LILO was trying to load. I've come to understand that this error means LILO stage 1 has loaded but stage 2 has failed to load.

I've read around a little and found a few solutions, such as using lilo -M to update the MBR (which supposedly could be broken). The HDD is fine, I've tested it with MHDD and it can also be booted from CD-ROM by passing the root= option to LILO.

My question is: What could cause this to happen, and how can I fix it? Why would this happen out of the blue? I compiled and rebooted the computer with my new kernel perhaps eight times, but then finally on the ninth reboot I suddenly get this error from LILO? I didn't do anything different, I simply do a "make; make modules; make modules_install", I then copy the bzImage kernel into /boot (and at the same time rename it to the proper name corresponding to the entry in lilo.conf).

I've also tried to simply reboot and add the kernel again, I've also tried to recompile, but according to the error the fault isn't with the kernel, but with lilo, like I wrote above i.e. that the second stage fails to load. Since I didn't touch lilo (in any other sense than executing the commanad "lilo") how could this happen?

lilo places the absolute address of the kernel in the MBR and uses that absolute address to find the kernel. You have moved the kernel to a new location within /boot and the absolute address no longer points to the kernel image.

Run lilo to create a new MBR and all should be well.

-------------------
Steve Stites

P.S. Grub does not rely on absolute disk address so renaming the kernel would work in grub.

It can't possibly be that, or we wouldn't be able to select from multiple kernels during the boot process. Looking in /boot/grub, which must be similar to lilo, I see stage1, stage1_5 for the various FS types, then stage2. From this, one must deduce that the MBR for grub has a hard pointer to at least the stage1 file. From there, grub loads some or all of its stage1_5 files, then loads stage2 and finally boots the kernel you've selected.

Yes, you are probably right. The problem is likely to be that posix_memalign has moved whatever the MBR has an absolute address for. I remember it as being for the kernel image but maybe it is for the map image that lilo creates when you issue the lilo command.

---------------------
Steve Stites