The issue is this difference: --- /var/lib/dpkg/info/linux-image-2.6.18-6-686.postinst 2009-05-05 07:43:48.000000000 +0200 +++ /var/lib/dpkg/info/linux-image-2.6.24-etchnhalf.1-686.postinst 2009-07-27 06:37:00.000000000 +0200 @@ -25,7 +25,7 @@ $|=1; # Predefined values: -my $version = "2.6.18-6-686"; +my $version = "2.6.24-etchnhalf.1-686"; my $link_in_boot = ""; # Should be empty, mostly my $no_symlink = ""; # Should be empty, mostly my $reverse_symlink = ""; # Should be empty, mostly @@ -34,8 +34,8 @@ my $do_bootfloppy = "Yes"; # target machine defined my $do_bootloader = "Yes"; # target machine defined my $move_image = ''; # target machine defined -my $kimage = "bzImage"; # Should be empty, mostly -my $loader = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo +my $kimage = ""; # Should be empty, mostly +my $loader = ""; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo my $image_dir = "/boot"; # where the image is located my $clobber_modules = ''; # target machine defined my $relative_links = ""; # target machine defined
The $loader change prevents lilo from being automatically run after installing the image. I've been running into this problem for a while, and until now just made one of the two workarounds I suspect most users choose: a) replace lilo with grub b) run lilo manually after installing a new linux-image I do however manage a few servers where installing grub has been considered too risky at the moment (due to no-way-out-if-it-blows-up). So they still have lilo. However, running lilo is also risky with the newer kernel images due to this bug. Security updates may overwrite the lilo default image, causing a boot failure unless lilo is run manually first. I only have serial console access to these servers, so that means a dead server until I can arrange physical access (which is why I can't just install grub either). This makes the bug serious to me. Now, to stop whining and start working: I have tried to find the answer to the question in the subject, but have found nothing. Which suggests that the bug is just a mere accident when the build system was changed somewhere between the 2.6.18 and 2.6.24 etch images. It would be very nice if someone from the kernel team could verify that, and if the attached patch could be considered. The patch is made against the 2.6.24-etchnhalf.1 source, but does also apply to the 2.6.26-2 source. Please let me know if I should provide it in some other way. The point is that it needs to be applied to the current etch and lenny builds. Please note that similar bug reports seem to have been pushed back and forth between linux-image-* and lilo for a while. See e.g. bug #342542. Removing lilo is of course also an option for future releases, but it won't fix the bug wrt the etch and lenny linux-images. Bjørn
--- linux-2.6.24-2.6.24/debian/rules.real.orig 2009-07-31 12:07:59.000000000 +0200 +++ linux-2.6.24-2.6.24/debian/rules.real 2009-07-31 12:57:04.000000000 +0200 @@ -403,6 +403,9 @@ install-image_powerpc_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_KIMAGE = vmlinux +install-image_amd64_$(FEATURESET)_$(FLAVOUR)_plain_templates \ +install-image_i386_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_BOOTLOADER = lilo + install-image_s390_$(FEATURESET)_$(FLAVOUR)_plain_templates: ARG_BOOTLOADER = zipl install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_templates:
