stale files in /var/lib/initramfs-tools after removing kernel

[knarf]

Binary package hint: initramfs-tools

Removing a kernel image and accompanying headers with apt-get remove --purge does not seem to remove the corresponding configuration file in /var/lib/initramfs-tools. This leads to problems when either grub, a kernel, initramfs-tools or any other package which leads to a grub menu rebuild is installed, updated or removed. Eg. after having removed a kernel image (2.6.23-t23-04 - a homebrew image made with make-kpkg) this happens when I try to use apt:

# apt-get install some_package
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.

# dpkg --configure -a
Setting up initramfs-tools (0.85eubuntu20) ...
update-initramfs: deferring update (trigger activated)

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

Removing the stale configuration files in /var/lib/initramfs-tools makes dpkg happy again

As to whether this is a bug in initramfs-tools (which could ignore or remove configuration files for which no corresponding kernel image is found) or the kernel package (which could contain a config file reference to /var/lib/initramfs-tools/version_number-release) I'll leave to the respective package maintainers.

[LinuxWebGuy (jeremy-linuxwebguy)]

I had the same issue happen to me. I created a custom kernel of 2.6.23, then removed it using the stock 2.6.22-14-generic kernel. Oddly enough, I also had a stale file for 2.6.22.9 in /var/lib/initramfs-tools, which I didn't install. I'm wondering if the issue lies in initramfs-tools? My custom kernel package was created with make-kpkg.

[Sorocean Anton (distortedbsd)]

I had same issue with 8.04. I removed through synaptic my custom kernel 2.6.25. And later during an update i noticed this:

Processing triggers for libc6 ...
ldconfig deferred processing now taking place
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.25.3-custom
Cannot find /lib/modules/2.6.25.3-custom
update-initramfs: failed for /boot/initrd.img-2.6.25.3-custom
dpkg: subprocess post-installation script returned error exit status 1

Managed to solve the issue by removing stale configuration files in /var/lib/initramfs-tools

[Chris Halse Rogers (raof)]

There seems to be a real problem here. Confirming, and marking as Medium importance; this seems to break an edge-case pretty seriously.

[Alex Ruddick (alexrudd0)]

I ran into this problem too while upgrading today on hardy-proposed. I upgrade on a regular basis (ie. several times a week), so I'm not sure why it only cropped up now.

I remember try to compile a custom kernel once, but never got far and don't remember what tool I used. It was a while ago, definitely before hardy.

The previously mentioned suggestion of removing the stale file in /var/lib/initramfs-tools worked perfectly.

[foxy123 (foxy)]

removing a leftover custom kernel file from /var/lib/initramfs-tools solves the problem.

[Horst Schirmeier (horst)]

This bug also exists in Karmic.

[Robert Key (robertkey)]

I also have this problem. I installed my own custom kernels and then purged them. Now when I run update-grub update-initramfs tries to update all those purged kernels. Thanks,
 Rob Key

[Robert Key (robertkey)]

I have just looked at /var/lib/initramfs-tools and all my old kernels that I have purged are still there including the currently installed kernels. Obviously this list is not being cleared. Should be easy to fix. Interesting though this does not happen under Debian testing.
Rob Key

[andrew thomas (atswartz)]

This problem existed in lucid at the time of 2.6.32-19 & 2.6.32-20. I am not sure if it has been fixed since I upgraded to maverick at that time. This problem does not exist in maverick.

[Andy Whitcroft (apw)]

I believe that comment #9 tells us this bug is no longer valid in any active release. Closing fixed.

[Brendan (brendan-rankin)]

Just for posterity's sake, I was able to solve my issue of older initrd's consuming all of the space in /boot by removing the ones whose kernel had been purged.

I had a /boot partition that was quite small and nearly every kernel upgrade would fail with "no space left on device" messages.