[service] Old /lib/modules/xx.xx.x cleaner

Hi there,
For years, when kernels are update, dnf use to clean old kernels directrories, but not the /lib/modules ones. The main problem with this issues is that the module directories will end up consuming an huge amount of space on the hard disk.
I can tell if this issues comes from my Fedora flavour (mate-compiz) or if it is global.

To fix this, I recently wrote a little script to clean old /lib/modules automaticaly and push it to github gist.
This a script whitch auto install it self as a service, watch at boot time if the kernels present in /boot folder are the only in the /lib/modules and remove obsoletes if not.

I hope this going to be useful for you.

Ajout de Site Help & Feedback, problem

Is this now a solved problem? I do see old /lib/module folders for 5.* and 6.[23]* kernels.
But nothing orphaned after.

available_kernels=$(ls -1 /boot/config-* | sed -n "s/^.*-\(.*-.*\)\..*$/\1/p")

Isn’t it better to use the RPM database to find available kernels?
I think using the output of rpm -q kernel-core for example.

Very nice; thank you–very direct and uncomplicated solution to bit of housekeeping.

Not really.
Orphan /lib/modules dirs is supposed to not exist after dnf kernels updates and cleaning. So, rpm database not have them anymore.
The simple way is to just compare what’s in /boot and remove what’s is not. This orphan dirs are not link to the system anymore.

I’d also rather use available_kernels=$(rpm -q --queryformat "%{VERSION}-%{RELEASE}\n" kernel-core)

1 Like

FWIW, I just checked under /lib/modules on a long-running system and I have

  1. A directory for every f35 kernel, each containing only modules.builtin.alias.bin (size about 30k)
  2. Four directories for f37 kernels, each empty
  3. Three (populated) directories for current f39 kernels.

On a long-running Fedora box, I have pretty much the same as Matthew;
a small amount of space is consumed for older Fedora kernels but since 37 no space wasted.

[root@t3600 ~]# du -hs /lib/modules/*
32K	/lib/modules/5.14.10-200.fc34.x86_64
32K	/lib/modules/5.14.11-200.fc34.x86_64
32K	/lib/modules/5.14.12-200.fc34.x86_64
32K	/lib/modules/5.14.13-200.fc34.x86_64
32K	/lib/modules/5.14.14-200.fc34.x86_64
32K	/lib/modules/5.14.14-300.fc35.x86_64
32K	/lib/modules/5.14.15-300.fc35.x86_64
32K	/lib/modules/5.14.16-301.fc35.x86_64
32K	/lib/modules/5.14.17-301.fc35.x86_64
32K	/lib/modules/5.14.18-300.fc35.x86_64
32K	/lib/modules/5.14.9-200.fc34.x86_64
32K	/lib/modules/5.15.10-200.fc35.x86_64
32K	/lib/modules/5.15.11-200.fc35.x86_64
32K	/lib/modules/5.15.12-200.fc35.x86_64
32K	/lib/modules/5.15.13-200.fc35.x86_64
32K	/lib/modules/5.15.14-200.fc35.x86_64
32K	/lib/modules/5.15.16-200.fc35.x86_64
32K	/lib/modules/5.15.18-200.fc35.x86_64
32K	/lib/modules/5.15.6-200.fc35.x86_64
32K	/lib/modules/5.15.7-200.fc35.x86_64
32K	/lib/modules/5.15.8-200.fc35.x86_64
32K	/lib/modules/5.16.10-200.fc35.x86_64
32K	/lib/modules/5.16.11-200.fc35.x86_64
32K	/lib/modules/5.16.12-200.fc35.x86_64
32K	/lib/modules/5.16.13-200.fc35.x86_64
32K	/lib/modules/5.16.14-200.fc35.x86_64
32K	/lib/modules/5.16.15-201.fc35.x86_64
32K	/lib/modules/5.16.16-200.fc35.x86_64
32K	/lib/modules/5.16.17-200.fc35.x86_64
32K	/lib/modules/5.16.5-200.fc35.x86_64
32K	/lib/modules/5.16.8-200.fc35.x86_64
32K	/lib/modules/5.16.9-200.fc35.x86_64
0	/lib/modules/6.2.10-200.fc37.x86_64
0	/lib/modules/6.2.11-200.fc37.x86_64
0	/lib/modules/6.2.11-300.fc38.x86_64
0	/lib/modules/6.2.12-300.fc38.x86_64
0	/lib/modules/6.2.13-300.fc38.x86_64
0	/lib/modules/6.2.14-300.fc38.x86_64
0	/lib/modules/6.2.15-300.fc38.x86_64
0	/lib/modules/6.2.7-200.fc37.x86_64
0	/lib/modules/6.2.8-200.fc37.x86_64
0	/lib/modules/6.2.9-200.fc37.x86_64
0	/lib/modules/6.3.11-200.fc38.x86_64
0	/lib/modules/6.3.11-200.fc38.x86_64+debug
0	/lib/modules/6.3.12-200.fc38.x86_64
0	/lib/modules/6.3.12-200.fc38.x86_64+debug
0	/lib/modules/6.3.4-201.fc38.x86_64
0	/lib/modules/6.3.5-200.fc38.x86_64
0	/lib/modules/6.3.5-200.fc38.x86_64+debug
0	/lib/modules/6.3.6-200.fc38.x86_64
0	/lib/modules/6.3.6-200.fc38.x86_64+debug
0	/lib/modules/6.3.7-200.fc38.x86_64
0	/lib/modules/6.3.7-200.fc38.x86_64+debug
0	/lib/modules/6.3.8-200.fc38.x86_64
0	/lib/modules/6.3.8-200.fc38.x86_64+debug
127M	/lib/modules/6.6.12-200.fc39.x86_64
127M	/lib/modules/6.6.13-200.fc39.x86_64
127M	/lib/modules/6.6.14-200.fc39.x86_64
[root@t3600 ~]# rpm -q kernel-core
[root@t3600 ~]# 

Considering the following sizes;

[root@t3600 ~]# du -hs /lib/modules/
380M	/lib/modules/
[root@t3600 ~]# du -hs /lib/modules/*fc39*
127M	/lib/modules/6.6.12-200.fc39.x86_64
127M	/lib/modules/6.6.13-200.fc39.x86_64
127M	/lib/modules/6.6.14-200.fc39.x86_64
[root@t3600 ~]# 

I think the wasted space is negligible.

But if I do clean them out (as I have no longer a need for F38 and older directories now that I am on 39), then I personally prefer to ask rpm what kernels I have installed than to make assumptions based on the presence of /boot/config-*.

There is a bug open (just for the directory): 2185410 – Removing old kernels leaves artifacts in /lib/modules. Comment #3 there has the explanation. I think it’d be nice to fix this properly.

1 Like

I see that bug is NEW still after a long time so I guess it will not be fixed any time soon unless someone comes up with a PR to implement the proposed fix.

It’s probably a one line change (or at most a few lines), so I think somebody should try.

Yes, it could be used also this line as variable.

Orphans could be effectively an issue with dkms and third parties modules (nvidia in my case), but dkms cannot do many things about that and maybe kernel install/update script wont remove folders containing something it didn’t have the hands on ?
The advantage of the service is that user can enable/disable it.

I was under the impression that this was fixed some time ago, and from the responses I see here, the old directories are all over a year old. Is this still actually happening, or are we just rehashing more of the same old complaints?

It is not happening for a while on any of my systems. Maybe its time to close that ticket? 2185410 – Removing old kernels leaves artifacts in /lib/modules

The good question is : Why it’s happens on some system and not on other ?
The ticket you mention will probably auto close in a short time, fed 37 is no more maintained, but the issue still happens.
It will be effectively more simple if rpm handle it, but it is not certain that it could., all same for dkms.
If it’s an issue of third party drivers, rpm will be compelled to manage a third party drivers data base. in my point of vue, this would be a waste of resource (human, system). A simpe check/remove is the real simple way.

Because the issue is only specific to systems building modules not owned by RPM packages like DKMS or some third-party software such as VirtualBox installed from the Oracle repo.