Bug#505609: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
After examining the maintainer scripts, this does appear to be a bug in
the maintainer scripts. I compared output of dpkg-reconfigure between
two different systems: one running Etch and the other running Lenny.
Both had lilo installed as the boot loader. In both cases, the contents
of /etc/kernel-img.conf were as follows:
----------
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = yes
do_bootfloppy = no
do_initrd = yes
link_in_boot = yes
----------
Here is the output of dpkg-reconfigure on Etch:
----------
# dpkg-reconfigure linux-image-2.6.18-5-686
Running depmod.
Finding valid ramdisk creators.
Using mkinitramfs-kpkg to build the ramdisk.
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.18.dfsg.1-13 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(2.6.18.dfsg.1-13 was configured last, according to dpkg)
You already have a LILO configuration in /etc/lilo.conf
Running boot loader as requested
Testing lilo.conf ...
Testing successful.
Installing the partition boot sector...
Running /sbin/lilo ...
Installation successful.
#
----------
Here is the output of dpkg-reconfigure on Lenny:
----------
# dpkg-reconfigure linux-image-2.6.26-2-686
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.26-21lenny4 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(2.6.26-21lenny4 was configured last, according to dpkg)
#
----------
Notice the absence of any information about running the boot loader in the
Lenny output! The boot loader simply was not run, despite a request in
/etc/kernel-img.conf to run it.
I compared the two relevant maintainer scripts:
/var/lib/dpkg/info/linux-image.2.6.18-5-686.postinst
and
/var/lib/dpkg/info/linux-image.2.6.26-2-686.postinst
and quickly discovered the reason. The maintainer scripts for the
2.6.26 kernel define the $loader variable to be the null string.
The 2.6.18 maintainer script defines the $loader variable to be lilo.
To be specific,
line 38 of /var/lib/dpkg/info/linux-image-2.6.26-2-686.postinst
currently says:
my $loader = ""; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo
I changed it to say:
my $loader = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo
The new output is as follows:
----------
# dpkg-reconfigure linux-image-2.6.26-2-686
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.26-21lenny4 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(2.6.26-21lenny4 was configured last, according to dpkg)
You already have a LILO configuration in /etc/lilo.conf
Running boot loader as requested
Testing lilo.conf ...
Testing successful.
Installing the partition boot sector...
Running /sbin/lilo ...
Installation successful.
#
----------
There is no conflict with grub version 1 or grub version 2 here. If the user
has either version of grub installed, then the user will set
do_bootloader = no
in /etc/kernel-img.conf. In the case of grub version 1, he will also add
postinst_hook = update-grub
postrm_hook = update-grub
A similar change should be made to the preinst, prerm, and postrm scripts
for consistency. The Squeeze and Sid scripts have the same problem.
OK, I solved the mystery. Now someone on the kernel team actually has
to fix it.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: