OK!! I managed to work around this floating point exception stuff.

Here's how I did it!
1. removed lilo package (removepkg lilo)
2. installed lilo from source
3. rebooted with a live CD (in this case, Gentoo 2004.3 Minimal Installation Live CD)
4. mounted my / device (mnt -t ext3 /dev/hda3 /mnt/gentoo)
5. chrooted to my / device (chroot /mnt/gentoo)
6. mounted my /boot partition (mnt -t ext2 /dev/hda1 /boot)
7. ran lilo
8. rebooted... Success

Some notes -
- steps 1 and 2 are likely not necessary. They were an attempt at not having to do the rest of it.
- this assumes you have your new kernel already saved in your /boot partition, and your new lilo.conf file correct and ready to go.

I agree that it seems very unlikely that a boot loader would need or use floating point, and I suspect that something is being mistaken for a floating point operation, with an exception as the result.

I get the lilo error from time to time, including this morning after I'd built and installed 2.6.17.7, and there seems to be a pattern to it. It's always after building and installing a new kernel, prior to rebooting to start the new one. Previous runs of lilo under the current kernel got no exception.

In particular:

I always keep two kernels, each in its own directory under /boot. Recently these were /boot/2.6.17.3 and /boot/2.6.17.4. Each contains a System.map and a vmlinuz. After building/installing 2.6.17.6 while running 2.6.17.4, I got the lilo error. This had happened once before, but not for several months. And fortunately, as before, it happened prior to its updating /boot/map, so I was able to boot 2.6.17.3 and run lilo under it. I got no error this time: .3, .4 and .6 were added, and .6 booted without problems. I deleted .4 and kept .3 and .6. As mentioned above, I built and installed .7 this morning and got the error again, but I had to leave for work and couldn't try it with .3, which I'll do this evening.

The pattern seems to involve running lilo under the kernel that is in use when you build a new one: ie, I had no problems with lilo under .4 until I'd built .6, and none under .6 until I'd built .7. But, on the other hand, this didn't occur when I'd built .3.

I have no idea what might be causing this nuisance, but I suggest that people who experience it always keep an earlier kernel that was not in use when the new one was built, update lilo.conf to include the new one, boot the older one and run lilo under it, then boot the newly built one.

This evening, if lilo succeeds with .3 -- ie, it adds .3, .6 and .7 --, then as an experiment I'm going to boot .6 instead of .7 and run lilo under it. I have a suspicion that the error won't occur this time. I'll report my findings here afterward.

I tested my hypothesis last night. When I booted 2.6.17.3, lilo ran fine and added .3, .6 and .7. I then booted .6 and ran it again without error. Likewise with .7.

So the problem does have something to do with lilo being run under the kernel that was running when the new kernel was built, and it disappears after a reboot. Two reboots are thus required to get the new kernel recognized and running. I have no idea why, and I'll probably email the lilo contact person about it, as I didn't see it mentioned in his list of problem reports.