6

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.

  • 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. – yeedle Dec 4 '16 at 20:41
2

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
0

Doing ls /boot should show some vmlinuz-X.XX.XX files. Do apt-get purge linux-image-X.XX.XX-generic for each one, but DO NOT REMOVE the kernel you are running. You can check which one with uname -r.

  • @Zanna fixed question. – user595510 Dec 1 '16 at 14:24
  • cool, I suggest leaving one spare kernel too – Zanna Dec 1 '16 at 14:26
  • 2
    @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 Dec 1 '16 at 16:34
0

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

  • 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. – Giuseppe Dec 5 '16 at 17:13
  • 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. – Mark Dec 6 '16 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.