/lib/modules directories left behind after purging kernels

[Matt Zimmerman]

I purged a bunch of old kernels yesterday, and noticed (via the warnings from dpkg) that their /lib/modules directories remained on the system:

perseus:[~] ls /lib/modules
2.6.28-10-generic 2.6.30-9-generic 2.6.31-7-generic 2.6.35-20-generic
2.6.28-8-generic 2.6.31-1-generic 2.6.32-23-generic 2.6.35-6-generic
2.6.28-9-generic 2.6.31-2-generic 2.6.32-9-generic 2.6.35-7-generic
2.6.30-10-generic 2.6.31-3-generic 2.6.35-10-generic 2.6.35-8-generic
2.6.30-6-generic 2.6.31-4-generic 2.6.35-11-generic
2.6.30-7-generic 2.6.31-5-generic 2.6.35-15-generic
2.6.30-8-generic 2.6.31-6-generic 2.6.35-19-generic

A purge operation should remove these traces.

The older (2.6.28) directories contain:
modules.alias.bin modules.dep.bin modules.symbols.bin

The newer (2.6.32 and .35) contain:
modules.devname modules.softdep

I also came across one which has:
/lib/modules/2.6.32-9-generic:
modules.builtin.bin

The presence of these files will prevent dpkg from cleaning up the otherwise-empty directory created by the package.

[Leann Ogasawara (leannogasawara)]

Hi Matt,

This looks to be a duplicate of bug 618591, which should have been resolved as of 2.6.35-16.22. I myself just tried purging the 2.6.35-19-generic kernel on a test system here and /lib/modules/2.6.35-19-generic was removed as expected:

$ cat /proc/version_signature
Ubuntu 2.6.35-21.30-generic 2.6.35.4

$ ls /lib/modules/2.6.35-19-generic/
initrd modules.builtin.bin modules.ieee1394map modules.pcimap modules.usbmap
kernel modules.ccwmap modules.inputmap modules.seriomap
modules.alias modules.dep modules.isapnpmap modules.softdep
modules.alias.bin modules.dep.bin modules.ofmap modules.symbols
modules.builtin modules.devname modules.order modules.symbols.bin

$ sudo apt-get purge linux-image-2.6.35-19-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  linux-image-2.6.35-19-generic*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 107MB disk space will be freed.
Do you want to continue [Y/n]? Y
(Reading database ... 620769 files and directories currently installed.)
Removing linux-image-2.6.35-19-generic ...
Examining /etc/kernel/prerm.d.
run-parts: executing /etc/kernel/prerm.d/dkms 2.6.35-19-generic /boot/vmlinuz-2.6.35-19-generic
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 2.6.35-19-generic /boot/vmlinuz-2.6.35-19-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 2.6.35-19-generic /boot/vmlinuz-2.6.35-19-generic
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.35-21-generic
Found initrd image: /boot/initrd.img-2.6.35-21-generic
Found linux image: /boot/vmlinuz-2.6.35-20-generic
Found initrd image: /boot/initrd.img-2.6.35-20-generic
...
Found memtest86+ image: /memtest86+.bin
Found memtest86+ multiboot image: /memtest86+_multiboot.bin
done
Purging configuration files for linux-image-2.6.35-19-generic ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 2.6.35-19-generic /boot/vmlinuz-2.6.35-19-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 2.6.35-19-generic /boot/vmlinuz-2.6.35-19-generic

$ ls /lib/modules/2.6.35-19-generic
ls: cannot access /lib/modules/2.6.35-19-generic: No such file or directory

[Matt Zimmerman (mdz)]

On Tue, Sep 14, 2010 at 12:02:42AM -0000, Leann Ogasawara wrote:
> *** This bug is a duplicate of bug 618591 ***
> https://bugs.launchpad.net/bugs/618591
>
> Hi Matt,
>
> This looks to be a duplicate of bug 618591, which should have been
> resolved as of 2.6.35-16.22. I myself just tried purging the
> 2.6.35-19-generic kernel on a test system here and
> /lib/modules/2.6.35-19-generic was removed as expected:

Thanks for checking it. That explanation matches my data.

--
 - mdz