This is not a lilo bug. The problem is that lilo's map installer did not get run during the kernel upgrade process. The fact that the user was able to boot his old de-installed kernel is proof of this. The /boot/map file still pointed to the blocks in the file system which formerly contained the old kernel and its initial RAM file system image. And since, fortunately, those blocks had not yet been reused, the data was still there. Modules which were loaded from the initial RAM file system image loaded OK. But once the switch was made from the initial RAM file system to the permanent root file system, further module loads could not be done, since the modules had been erased. When the user manually ran lilo's map installer at the command line, the problem disappeared.
The real question is, "Why didn't the map installer get run during the kernel upgrade?" There is not sufficient data in the bug log to determine the answer to that question, but I have observed that "do_bootloader = yes" in /etc/kernel-img.conf no longer causes lilo to be run when a new kernel is installed. I believe that this change in behavior was caused by changes to the kernel maintainer scripts made around the time of the switch to grub version 1 as the default boot loader. "do_bootloader = yes" in /etc/kernel-img.conf still causes zipl to be run on the s390 port, a port that neither version of grub supports. "do_bootloader = yes" should still be specified in /etc/kernel-img.conf, however, so that "update-initramfs -u" will cause lilo's map installer to be run when an initial RAM file system is updated (but not when it is initially created). So is this a bug in the kernel maintainer scripts? Or is it a feature? I don't know. I'll leave that up to the kernel maintainers to decide. A full discussion of how to make sure that lilo's map installer gets run during the installation of a new kernel, taking into account all types of kernels (official stock Debian kernels, custom kernels created by make-kpkg, custom kernels created by "make deb-pkg", etc., is beyond the scope of this bug log. Interested readers may wish to look at my web page on kernel building, particularly step 10, for further information. http://www.wowway.com/~zlinuxman/Kernel.htm The instructions for "customizing the Lenny environment" will work in Squeeze or Sid also, provided that you use only official stock Debian kernels. If you use custom kernels in Squeeze or later, you *must* use hook scripts to ensure that any post-installation activities, such as the creation of an initial RAM file system, updating symlinks, or running a boot loader, take place. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2000712474.159302.1275230137351.javamail.r...@md01.wow.synacor.com
