update-initramfs should update all initrds

[Tormod Volden]

Packages like dmraid, evms, udev and usplash call update-initramfs in their .postinst scripts with the -u option only. Therefore only the current or latest initrd is updated, and none of the others that the user might has installed.

This should maybe be fixed in all the individual packages to use "-k all". (BTW the usage hint in update-initramfs says "ALL" with capitals, whilst the scripts checks for "all".)

A useful side-effect of the current behaviour is that the other initrds are kept as "backups" in case the newly created initrd does not work. However, other programs might depend on the new functionality in the new initrd.

[Dennis Kaarsemaker (dennis)]

This is done explictly with -u to not mess up older kernels which won't
work with eg a newer udev.

[Tormod Volden (tormodvolden)]

For instance, I have both a -386 and a -686 kernel installed (same versions). After upgrading a package (dmraid) the initrd was rebuild for the 686 kernel that I was using at that time. If I switch to the 386 kernel, an old initrd with incorrect/outdated dmraid stuff will be used.

"Normal" users will probably stick to one kernel flavour, though.

[Tormod Volden (tormodvolden)]

Another (true) example: I have both a -386 and a -k7 kernel installed. Because of some bugs I prefer to use the -386 kernel, and have this as default in grub. However, upgrading a package (like initramfs-tools) only updates the -k7 initrd which I am not using.

[Hervé Fache (rvfh)]

I can confirm this: for some performance tests that I suggested to run I have -386 and -k7, but -386 was more recently installed.
I installed an update which regenerated only -386, although -k7 was running at the time:
Unpacking replacement kubuntu-artwork-usplash ...
Setting up kubuntu-artwork-usplash (6.10-24) ...
update-initramfs: Generating /boot/initrd.img-2.6.17-6-386

root@sicilia:~# uname -a
Linux sicilia 2.6.17-6-k7 #2 SMP Fri Aug 11 22:11:15 UTC 2006 i686 GNU/Linux

I believe there is a better way to do it... unless the -686 and -k7 kernels end up being removed altogether of course!

[Jürgen Kreileder (jk)]

This also affects people who use upstream kernels, including rc versions. The current mechanism only updates e.g. 2.6.22-rc7 also 2.6.22 (final) is newer.

[archdrone (archdrone)]

I compiled 2.6.23 kernel into deb package then installed it but because I keep on using old 2.6.22 I removed the 2.6.23 (apt-get remove 2.6.23-custom). However now when I do `apt-get install whatever` I get error "E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem." so I tried
`dpkg --configure -a` and

>Nastavuji balík initramfs-tools (0.85eubuntu21) ...
>update-initramfs: deferring update (trigger activated)
>
>Processing triggers for initramfs-tools ...
>update-initramfs: Generating /boot/initrd.img-2.6.23.1-adr
>Cannot find /lib/modules/2.6.23.1-adr
>update-initramfs: failed for /boot/initrd.img-2.6.23.1-adr
.dpkg: podproces post-installation script vrátil chybový status 1

I investigated more and
`sudo update-initramfs -u` (which is used by dpkg):
>update-initramfs: Generating /boot/initrd.img-2.6.23.1-adr
>Cannot find /lib/modules/2.6.23.1-adr //because apt-get removed it
>update-initramfs: failed for /boot/initrd.img-2.6.23.1-adr
so this error propagates to dpkg --configure -a thus causing installing/upgrading with apt impossible.

As a workaround I created empty directory /lib/modules/2.6.23.1-adr

everything on almost up-to-date Kubuntu 8.04, 2.6.22-14-generic

[Tormod Volden (tormodvolden)]

archdrone, your problem is a different issue and a bug in your own deb package: when it was removed, it didn't delete all the 2.6.23 files from /boot.

[archdrone (archdrone)]

It did:) initramfs-update -u updated only the newest kernel in the system even if it wasn't used and tried even if related files in /boot weren't present.

[KeithIrwin (keithirwin)]

I was bitten by this recently. Conflicts between EVMS and the newest kernel version were causing my system to fail to boot. Removing EVMS did not initially fix the problem because it only updated the -generic initramfs rather than the -386 one which is the one I was currently booting. Whether or not previous versions should have their initramfs updated, it is abundantly clear that this should happen with all current versions and not just one.

In this case, doing otherwise resulted in a system which would not boot the default kernel until the initramfs was rebuilt by hand. That is fundamentally broken, and honestly, the severity of this bug is set too low given the potential consequences of running a kernel with whose initramfs either does not contain needed drivers or which contains drivers whose corresponding components have been removed.

[Sergio Costas (rastersoft-gmail)]

As I commented in bug #69199, updating from 710 to 8.04 beta installs both 386 and GENERIC kernels, and only updates the INITRAMFS for the former one, but not for the later, so the system only boots when choosing the 386 kernel. Running "update-initramfs -u all -k" fixes this problem. Anyway, the 386 is the kernel set as default, not the GENERIC.

[Johannes Veser (jveser)]

As I was hit by this problem recently, I'm glad to see that upstream initramfs-tools 0.90 adds a configuration setting to have 'update-initramfs -u' regenerate all initrds. The configuration variable 'update_initramfs' in 'update-initramfs.conf' could already be used in versions prior to 0.90 to disable 'update-initramfs -u' at all. Now it can also be set to 'all'.
See http://git.debian.org/?p=kernel/initramfs-tools.git;a=blob;f=debian/changelog;hb=8b4b8b0ced679130f768cb10df8f78c1bb513281

It's not in hardy, but it should work in intrepid, which currently uses initramfs-tools 0.92.

[maximilian attems (maks-debian)]

This can be set by admin, if he wishes so, but it definetly makes no sense as default, thus closing.