clr-boot-manager
clr-boot-manager copied to clipboard
clearlinux
Remove old kernel modules
Currently (at least on Solus), the old kernel modules are left in /lib/modules. After a year, the disk usage of this folder is 5.6Gb on my machine.
It would be nice to foresee a mechanism in clr-boot-manager to purge the old kernel modules.
Hrm I don't see replication of this issue either but we've seen cleanup issues before. Not sure what would be special here though. @kyrios123 Do you still see this issue?
@bryteise yes. This problem impacts all computers running Solus (which still uses clr-boot-manager version 1.5.5)
I am using Solus and this definitely isn't an issue for me, I only have the 4.18.5 kernel modules and no more which totals at around 198mb...
UPDATE: I have more info about this issue.
Actually on Solus there are 2 kernel branches the -current one (4.18.x at the moment) and the -lts one (4.9.x). Both are installed on my system. On the boot menu, there are 2 entries for each kernel branch as expected (latest version and previous version). In /lib/modules there are 2 modules directories for the -current branch on which my machine boots, but I have 30+ modules directories for the -lts kernel, so it seems that the cleanup of the kernel on which the machine does not usually boots is not done.
Seems like what you are saying is correct, I only have the current branch installed so there are no LTS kernel modules, and thus no unneeded modules. Here is the output of ls -ltr /lib/modules just in case:
total 4
drwxr-xr-x 3 root root 4096 1 sep 20.52 4.18.5-90.current
@kyrios123 Interesting, I'll double check if I can replicate this behavior in Clear.
Wanted to ask if there is any update regarding this? I have the same issue as kyrios123 on solus
@Girtablulu I haven't been able to replicate this behavior on Clear, I think @ikeydoherty would have more knowledge about the state on Solus though.
@bryteise Thanks for the quick reply, going to talk with the Solus maintainers
We now have a user reporting this on the dev tracker: https://dev.getsol.us/T7183
Pinging @ikeyd on this, if he knows anything regarding this?
I am very for not having posted this much earlier.
I had actually started noticing last year, however I had thought that this was only due to Solus being relatively new, and that tackling was on the pipeline (which to be fair, it may have been, however I had found next to nothing about this, only an old Solus forum post where someone had asked where are the old kernel modules located).
Pretty sure Solus is carrying the relevant libnica patch to make sure nc_rm_rf works? And this was only done a few months back in Solus land. So there are some stray dead kernel trees to be left around, but nowadays it should be cleanly wiping all of them. i.e. ask your guy on the dev tracker if they're fully up to date using latest clr-boot-manager
I'll get it sorted before the sync this week, cheers!
EDIT: Looks like we held up the update because the description of 3.0.0 on the releases page says it removes Grub support even though it actually only removes goofiboot and gummiboot support. Might want to update that before it confuses someone else!
That sounds terrific. It does sound funny to be referred to as "your guy", especially since I check for updates on an almost obssesive manner (sometimes twice a day, on the unstable branch, no less), however I guess theres a first time for everything.
@DataDrake I think its more "support" than "code support". The older bootloaders are deaded because we transitioned to systemd-boot. I'd avoid the jump to 3.0 until you've fully tested it, and note that systemd-shim is the default these days (secure bootness). Look to cherry-pick patches to 2.x until you have a test path in place, perhaps?
@moriel5 I was replying to @Jacalz in terms of the dev tracker, didn't make the connection :)
@ikeyd, are there plans to remove code support for Grub? We still need it for our BIOS-only users.
3.0.0 seems to be working for now and I'll happily contribute patches to keep BIOS-only systems working if that's what it takes.
@DataDrake right now its perhaps best to ping @bryteise on this. I think in terms of keeping CBM distro-agnostic we need to retain that path, and I'm happy to volunteer those hours in terms of testing. As you know yourself, we'd not turn down good patches. :)
@ikeyd, all is good, I was simply amused.
@DataDrake I'm still using the old BIOS method where I can (and I also have BIOS-only PCs, including my back up PC), due to me still not understanding enough about maintenance with UEFI.
If someone can point me somewhere that I can learn more about system maintenance when the firmware is UEFI, I'll be very grateful, especially since it will probably mean that at work we'll finally stop installing systems via legacy on our customer's PCs.