Force removal of unwanted linux-image-extra* packages

Question

To make a long story short, I am stuck with a handful of unwanted, half-configured image packages that I am trying to get rid of:

$ dpkg -l |grep linux-im
iF  linux-image-3.13.0-100-generic       3.13.0-100.147 i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iF  linux-image-3.13.0-101-generic       3.13.0-101.148 i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iF  linux-image-3.13.0-92-generic        3.13.0-92.139  i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iF  linux-image-3.13.0-93-generic        3.13.0-93.140  i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iF  linux-image-3.13.0-96-generic        3.13.0-96.143  i386 Linux kernel image for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-100-generic 3.13.0-100.147 i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-101-generic 3.13.0-101.148 i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-92-generic  3.13.0-92.139  i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-93-generic  3.13.0-93.140  i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP
iH  linux-image-extra-3.13.0-96-generic  3.13.0-96.143  i386 Linux kernel extra modules for version 3.13.0 on 32 bit x86 SMP

These images are in fact useless, because my 32-bit 14.04 system lives in an OpenVZ container, which is solely responsible for the kernel. As you can see, a much older one:

$ uname -r
2.6.32-042stab116.2

Thus, unlike most similar questions focusing on how to remove old kernel images after routine upgrades, what I am trying to do here is to COMPLETELY PURGE ALL THESE 3.13 PACKAGES, which should not be there in the first place.

---

Here's a summary of my attempts so far.

Trying to remove/purge the packages the usual ways (apt-get, apt, aptitude, it doesn't matter) does not seem to work, due to an apparent vicious circle.

sudo apt-get purge linux-image-3.13.0-100-generic linux-image-3.13.0-101-generic linux-image-3.13.0-92-generic linux-image-3.13.0-93-generic linux-image-3.13.0-96-generic linux-image-extra-3.13.0-100-generic linux-image-extra-3.13.0-101-generic linux-image-extra-3.13.0-92-generic linux-image-extra-3.13.0-93-generic linux-image-extra-3.13.0-96-generic

As you can see from the output, nothing gets actually removed. On the other hand, aptitude manages to get a little further:

sudo aptitude purge linux-image-3.13.0-100-generic linux-image-3.13.0-101-generic linux-image-3.13.0-92-generic linux-image-3.13.0-93-generic linux-image-3.13.0-96-generic linux-image-extra-3.13.0-100-generic linux-image-extra-3.13.0-101-generic linux-image-extra-3.13.0-92-generic linux-image-extra-3.13.0-93-generic linux-image-extra-3.13.0-96-generic

At the end of this process, the *image-3.13*s are gone, together with matching files and folders normally found in /boot and in /lib/modules, but the image-extras are still reported as half-installed (even though they appear to contain no files, as verified by dpkg -L...)

Furthermore, dependencies are now broken, as repeating the purge at this stage causes apt to complain about missing files/folders in /boot and in /lib/modules. I tried to place dummy files at the expected locations, as suggested here, but in the end I run into the original errors. The following, I believe, is the crucial excerpt:

[...]
Removing linux-image-extra-3.13.0-101-generic (3.13.0-101.148) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.13.0-101-generic /boot/vmlinuz-3.13.0-101-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.13.0-101-generic /boot/vmlinuz-3.13.0-101-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-101-generic
E: /usr/share/initramfs-tools/hooks/fixrtc failed with return 1.
update-initramfs: failed for /boot/initrd.img-3.13.0-101-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-extra-3.13.0-101-generic (--purge):
subprocess installed post-removal script returned error exit status 1
[...]

After trying, unsuccessfully, a supposedly nuclear option:

sudo dpkg --remove --force-remove-reinstreq package_name

I ran out of ideas.

Solution 1

Given that:

• the linux-image-3.13.0-XXX-generic were successfully purged
• the linux-image-extra-3.13.0-XXX-generic are still reported as half-installed
• no currently installed packages depend on these image-extras
• none of these images should be there in the first place (since the 2.6 kernel is provided by the host OpenVZ container)
• none of the traditional attempts succeed in cleaning the system

Then a possible approach is to forcefully purge those dangling entries from the dpkg database, as suggested here.

PLEASE NOTE: this is a hackish, low-level, potentially dangerous operation.

• look for any files belonging to the package you want to remove (try $ dpkg -L linux-image-extra-3.13.0-XXX-generic) and delete them
• open the file /var/lib/dpkg/status, locate and delete the block(s) of text describing the package(s) you want dpkg to forget about
• be extra careful about preserving blank lines between package descriptors, spaces at the beginning of lines, etc. They say the apt database is unforgiving of typos.
• after saving the status file, dpkg as well as all apt-related programs should be back to normal

Solution 2

I use the following in a bash script to nuke everything but the active kernel:

dpkg -l linux-* | awk '/^ii/{ print $2}' | grep -v -e "$(uname -r | cut -f1,2 -d"-")" | grep -e "[0-9]" | grep -E "(image|headers)" | xargs sudo apt-get -y purge

It is quite close to what you've invoked but perhaps dpkg is the necessary difference.

The full set of scripts are here if interested:
https://github.com/mtompkins/linux-kernel-utilities

Comments

[Admin]

I've been digging under the hood a bit, and I have a hunch that the error stems from dpgk running the scripts in /etc/kernel/postrm.d.

[Admin]

@Zanna fixed question.

[Admin]

cool, I suggest leaving one spare kernel too

[Admin]

@MarkYisri, the /boot folder shows NO entries at all. As I wrote, Ubuntu is running inside an OpenVZ container, and the kernel (see the Q) belongs to the host, I have no control over it. Also, failing to apt-get purge these irrelevant packages is the essence of the problem is described.

[Giuseppe]

as far as I can tell, this line simply invokes apt-get purge on all applicable packages. I have already attempted that numerous times, to no avail.

[Mark]

That is indeed all it does but I was unsure if you were properly passing the package names in some sense and was hopeful the dpkg invocation might handle it. No worries.