[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel



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    
 : :'  :
 `. `'`
   `-


Reply to: