Hi. After an embarrassing situation where I ran out of root disk space (/) during a zypper dup, I cleaned up my disk following the advice here .
I ran sudo zypper purge-kernels to keep the “latest,latest-1,running” versions as per the standard /etc/zypp/zypp.conf settings - multiversion.kernels = latest,latest-1,running.
What I saw however in /usr/lib/modules was a little surprising as per this listing -
Those very old kernel folders were not wiped. Should I just remove the older folders with rm or is there a more proper way when dealing with kernels? Obviously I’d leave the 3 latest kernels untouched.
FYI - those older kernels were from when this PC was running Leap before I did an online upgrade to tumbleweed.
Directories in /usr/lib/modules/ not associated with installed kernels can be safely removed by whatever means you prefer.
IIRC, once upon a time, purge-kernels.service was not enabled by default, leading to what you now have. I looks like it’s still not enabled for you. Most times I’ve encountered orphan module directories, most of their content had been removed, just not all.
Never heard of that service and yes it is disabled on my system - but not for much longer
Thanks.
EDIT. Um it is enabled by default but failed for some reason. Will read on.
chris@asus-roc:/usr/lib/modules>$systemctl status purge-kernels.service
○ purge-kernels.service - Purge old kernels
Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled; preset: enabled)
Active: inactive (dead)
Condition: start condition failed at Sat 2023-04-01 14:18:06 AWST; 2h 59min ago
└─ ConditionPathExists=/boot/do_purge_kernels was not met
Apr 01 14:18:06 asus-roc systemd[1]: Purge old kernels was skipped because of an unmet condition check (ConditionPathExists=/boot/do_purge_kernels).
Seems kind of odd that you have to manually add /boot/do_purge_kernels yet the service then does an rm on it when run Process: 12982 ExecStartPost=/bin/rm -f /boot/do_purge_kernels (code=exited, status=0/SUCCESS).
I wonder if /boot/do_purge_kernels gets created when a new kernel is added by zypper?
erlangen:~ # journalctl -q -u purge-kernels.service -gconsumed
Mar 07 18:24:17 erlangen systemd[1]: purge-kernels.service: Consumed 1.894s CPU time.
Mar 12 01:05:44 erlangen systemd[1]: purge-kernels.service: Consumed 1.975s CPU time.
Mar 14 20:50:08 erlangen systemd[1]: purge-kernels.service: Consumed 1.980s CPU time.
Mar 18 10:01:41 erlangen systemd[1]: purge-kernels.service: Consumed 2.092s CPU time.
Mar 26 06:20:10 erlangen systemd[1]: purge-kernels.service: Consumed 2.343s CPU time.
erlangen:~ #
An installation of a new kernel creates the file. On booting the machine purge-kernels.service checks for the file, successfully removes the obsolete kernel packages if any and eventually removes the file.
erlangen:~ # journalctl -b -u purge-kernels.service
Mar 31 13:09:40 erlangen systemd[1]: Purge old kernels was skipped because of an unmet condition check (ConditionPathExists=/boot/do_purge_kernels).
Apr 01 11:45:15 erlangen systemd[1]: Purge old kernels was skipped because of an unmet condition check (ConditionPathExists=/boot/do_purge_kernels).
Apr 01 11:45:56 erlangen systemd[1]: Starting Purge old kernels...
Apr 01 11:45:56 erlangen systemd[1]: Started Purge old kernels.
Apr 01 11:45:56 erlangen zypper[12981]: Reading installed packages...
Apr 01 11:45:56 erlangen zypper[12981]: Preparing to purge obsolete kernels...
Apr 01 11:45:56 erlangen zypper[12981]: Configuration: oldest,latest,latest-1,running
Apr 01 11:45:56 erlangen zypper[12981]: Running kernel release: 6.2.8-1-default
Apr 01 11:45:56 erlangen zypper[12981]: Running kernel arch: x86_64
Apr 01 11:45:56 erlangen zypper[12981]: Resolving package dependencies...
Apr 01 11:45:56 erlangen zypper[12981]: Nothing to do.
Apr 01 11:45:56 erlangen systemd[1]: purge-kernels.service: Deactivated successfully.
erlangen:~ #
The service checks for installed packages only, stale entries in /usr/lib/modules are skipped.
