why does purge-kernels leave the associated /lib/modules/<kernel-ver> behind?

I’ve noticed for a very long time over several openSuse versions that whenever purge-kernels runs it never removes the /lib/modules/<kernel-ver> of the removed kernel.
I typically find several old /lib/modules/<kernel-ver> directories after a few kernel updates.
Since these modules are no longer useful, why aren’t they deleted along with the kernel?
Can (or how to) purge-kernels be modified to include the associated modules when removing a kernel?

With Leap 15.1, I am seeing:

% ls /lib/modules
4.12.14-lp151.28.10-default  4.12.14-lp151.28.13-default

No old directories there.

However: I did see this on a previous system with nVidia graphics. The old directory was left there because it was not empty (it contain the nvidia module). And I remember it with an even older computer where I was using a WiFi driver that did not come with the kernel.

You probably get that whenever you install something that adds modules are do not come as part of the kernel.

When the old kernel is removed, all files that came with that kernel are removed. But a directory is not removed unless it is empty.

At least, that’s how I understand it.

I’m not sure, but I think sometimes a newer kernel uses symlinks to the added modules in an older kernel. So you don’t really know for sure that they are not in use.

15.1 recent new install
Have NVIDIA have had 2 kernel updates have 3 directories the oldest (4.12.14-lp151.27-default) is empty but for an empty directory called updates. This appears where the NVIDIA stuff resides. All other files and directories have been cleared. So the cleanup routine seems to be missing this directory and thus leaves the parent.

Suppose there should be a bug report filed :\

That’s also my experience and my understanding.

I am using NVidia driver so maybe thats why, But even then the driver has to be rebuilt for each kernel or it wont load so why its kept around is beyond me.

I’ve never seen a kernel sym linked to another kernel’s modules and if was i doubt the system would boot

Presumably because the kernel update process can’t deal with modules that aren’t an integrated part of the kernel. I just remove old unneeded folders periodically.

Pete, shouldn’t that be the job of purge-kernels? The modules directory of a deleted kernel is useless, it cant be used for anything

For your reading pleasure: https://github.com/openSUSE/mkinitrd/blob/master/sbin/purge-kernels

Actually, it looks like the version installed in tumbleweed is different. I’m noticing comments that don’t exist in that other version.

less /sbin/purge-kernels

zypper tells me it’s provided by dracut, but I can’t find it in that repository.


Clicking “show latest” results in “file not found”. @_@

Here on 15.1 the oldest is purged but it seems that it leaves behind the update directory though that is also cleared thus it is probably because update is not removed that the kernel directory is not removed. It apparently only happens when the NVIDIA is used.

Just recalling from memory, since I don’t have any Nvidia installed at present, so forgive me if I’m not 100% correct.
My understanding is that any new Nvidia module installed “the hard way” via the Nvidia .run installer is built only for the running kernel (usually the last one installed) and placed in an “update” folder;
then symlinks are created in a “weak-update” folder for other installed kernels, and those symlinks are only used if no other (older) Nvidia module is found in a corresponding “update” folder for those older kernels.
Those “update” or “weak-update” folders are unknown to purge-kernels or may still contain remnants of Nvidia installs, so they are not removed by purge-kernels.
I think that those folders are removed by the .run installer when invoked with the “-uninstall” option, but I am not 100% sure.
I don’t know what happens when the Nvidia driver is installed directly from the Nvidia repo though.

I Install via the repos and see only the leftover update directory.Maybe the hardway has other issues.

Regardless of whether there is anything in updates or not the fact remains they are useless for any other kernel, e.g you can not load any of them in a new kernel, so why would the software want to leave updates behind?

Because purge-kernels removes the package, and the non-empty folders contain files that belong to some other package, or are created by some other package. You can easily force behaviour like this for any other package. Add an empty file or folder to a folder belonging to package X, then remove package X, and you will see that the path to that empty file or folder will remain. Consider it a safety measure that removing package X cannot remove files or folders that ( might ) belong to other packages. To avoid this purge-kernels issue would have to go through all the packages and their spec files to find out where those files/folders come from, and have some routine to determine whether those can be deleted or not. Not even speaking about what it would mean for uninstalling package Y that owns those files/folders.

I was reviewing purge-kernels and it seems that it just calls rpm -e to remove the package, so i have filed a bug suggesting that purge-kernels be updated to go back at the end after rpm is completely done, and find any modules dir that only has updates left in it and remove it.

Like said: if that folder belongs to some other package …

  1. that package would have to be deleted too
  2. and hence will not be updated.

To cover everything purge-kernels might have some serious performance impact. Sorry, but I can see the posts appearing here: “zypper very sloooooow when kernel-updates involved”.