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.
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.
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/
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-*.
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.
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?
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.
I was under the impression that this was fixed some time ago
No, my Fedora 41 with dnf5 of version 5.2.7 and rpm 4.20.0 is still doing this.
I have to periodically go in and delete these folders, they don’t take up space as it’s just an empty tree from “internal” folder downwards but I only want working folders under /lib/modules
These are my kernels
rpm -q kernel-core
kernel-core-6.11.9-300.fc41.x86_64
kernel-core-6.12.1-200.fc41.x86_64
kernel-core-6.11.10-300.fc41.x86_64
kernel-core-6.12.3-200.fc41.x86_64
The “6.12” related ones are from Koji, the 6.11 ones are official Fedora 41 kernels