This can be caused by a buggy BIOS which does not properly match up BIOS disks with OS disks. This can be fixed by using the disk parameter in /etc/lilo.conf, which when used with the bios keyword allows you to map BIOS disks to Linux disks. For example, I was just able to recover a server where an IDE CD-ROM, /dev/hda, was the primary master and an IDE hard disk, /dev/hdb, was the primary slave, with this entry in /etc/lilo.conf:
This may or may not require further tweaking for your setup. All I know is that if I'd seen this option on the web instead of extracting it from a Mandrake /etc/lilo.conf, I'd have saved a day's work. :-)
I had an old Compaq on which I had updated the BIOS but the /boot directory was far into the large hard drive. I wasn't able to tweak the autodetect parameters in BIOS, so I didn't have all the information in how it was set up. I would always get stuck at the "L" screen, though a boot disk (linux root=/dev/hda1) would work fine.
to set disk access mode to LBA32 (I think this is the default). Once this was written to the MBR (/dev/hda) everything worked fine.
It would be helpful to note that users with older hardware, who encounter the L 99 99 99 99 ... error, that adding "linear" in lilo.conf may solve the problem. (It did for me!)
There is a significant amount of conflicting information about error code 99. It appears to be associated with a BIOS disk error - mismatch of geometry, read failure, or something like that. According to the lilo man page, 99 indicates "invalid second stage index sector" and is usually associated with a bad map file or a geometry mismatch between lilo and the BIOS.
What solved it for me was moving lilo to the MBR instead of the first sector of the disk.
This error occurs if there are multiple disks in the system with the same Volume ID. Older versions of lilo didn't bother with the Volume ID - they ignored it and used the BIOS name of the disk. Newer versions of lilo will check it however, and this relies on the Volume ID being unique. Lilo will refuse to install if there are duplicate Volume IDs
There are a couple of ways in which the Volume ID can be non-unique - either a boot manager process was installed to both disks and it set the Volume ID to some constant value, or it was left over from a low-level format.
# lilo -T vol-ID BIOS Volume ID 0x80 9DC96E9E 0x81 A03D6CFB
lilo -z -M <devicename>
Where <devicename> corresponds to one of your disk devices, eg /dev/hdc or /dev/sdb.
Note: it is very important that you do NOT wipe the Volume ID of a disk that has Windows 2000 or XP installed on it, as this will probably render the OS unbootable. Typically Windows is installed on the first disk in the system - /dev/hda or /dev/sda, so you should pick the highest disk name instead.
I ended up resolving the L 99 problem with lilo by using grub; the problem stems from both the EPIA's bios and the constraint of using a laptop style cdrom on the IDE chain, forcing your hard drive to slave status. Details on grub as an alternative can be found under EPIA-Grub