initramfs-tools trigger fails if modules aren't installed

[Akkana Peck]

I upgraded a system from gutsy to hardy. Before starting the do-release-upgrade -d, I removed all the kernel and modules packages that were installed under gutsy (I use my own kernel, because 2.6.24 has kernel bug 10118, and I was running out of disk space on /boot).

During the "setting up" stage, I hit problems: apt refused to do anything further and told me to run dpkg --configure -a. but dpkg --configure -a failed because the initramfs-tools trigger couldn't find the appropriate /lib/modules directory.

I eventually found a workaround:
rm /var/lib/dpkg/triggers/initramfs-tools

If initramfs-tools can't install without kernel modules installed, shouldn't it have a dependency on some modules package? Or, better still, maybe have the initramfs-tools trigger exit gracefully if it doesn't see any modules.

[Eric Bursley (eric-bursley)]

I also had this problem show up out of the blue on me last night. I removed a custom kernel several months ago and thought nothing of it until a recent update was pushed down to my system which caused dpkg to fail. The error:

Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.25-custom-pae-xeon
Cannot find /lib/modules/2.6.25-custom-pae-xeon
update-initramfs: failed for /boot/initrd.img-2.6.25-custom-pae-xeon
dpkg: subprocess post-installation script returned error exit status 1

Like I said, this kernel image hasn't been installed in months, and I removed it via synaptic. Even when I did a purge, of this package I couldn't get dpkg to finish what it had started with initramfs.

I renamed the /var/lib/dpkg/triggers/initramfs-tools file and that resolve the issue.

Where is initramfs-tools reading information from to know which initrd's it needs to create during the update process?

[Marco Pattaro (mpattaro)]

I had this problem for quite a long time now, actually I believe it does not compromise anything as long as you don't install or upgrade any kernel module needed at boot time. To answer your question, I don't know where update-initramfs reads informations from to know which initrd to update, but I solved the issue by calling:

update-initramfs -u -t -k `uname -r`

this way it replace any information about older initrd with the current one, so updating it every time the trigger is processed; I didn't try it yet, but I believe that you can simply add a new initrd trigger, without removing the formers, by calling update-initramfs without the "-t" option.

[Tristan Schmelcher (tschmelcher)]

I also experienced this issue (in Lucid) with a kernel whose package had since been removed. I found by strace'ing update-initramfs that it gets the kernel list from the contents of /var/lib/initramfs-tools/. There's one entry there per kernel. Deleting the one for my removed kernel fixed the problem.

[Andy Whitcroft (apw)]

It seems that initramfs-tools has become confused when a kernel was removed, perhaps as a result of the initrd seeming changed from its point of view. If that happens the kernel removal can continue without it removing the state and from there it will fail to update "all" initamfs images.