I can’t figure out how to limit the number of kernels retained by Slowroll.
In Tumbleweed, I edit the multiversion.kernels line in /etc/zypp/zypp.conf. I prefer a minimal installation, and have this set to:
multiversion.kernels = latest,running
In Slowroll, however, I have zypp**er.**conf, which doesn’t include a multiversion.kernels line, and zypp.conf.README, which suggests that the user can put a modified file in /etc/zypp/zypp.conf.d .
I tried a one line /etc/zypp/zypp.conf.d/zypp.conf file with the above multiversion.kernels configuration, but it had no effect. Selecting ‘advanced options’ on reboot showed that the unwanted two additional kernels had been retained.
zypper.conf is the configuration file for the zypper command. It is not a different name for zypp.conf.
Try to move the file /etc/zypp/zypp.conf.d/zypp.conf to /etc/zypp/zypp.conf. AFAIK you can only do a configuration override if the new file has the corresponding path (and name).
That is incorrect. Please read the documentation (which the TO did):
from zypp.conf.README
The traditional /etc/zypp/zypp.conf configuration data will no longer be read
solely from this single file, but merged according to the rules defined by the
UAPI.6 Configuration Files Specification from:
system configuration: /etc/zypp/zypp.conf[.d/.conf]
vendor configuration: /usr/etc/zypp/zypp.conf[.d/.conf]
After this update an unmodified /etc/zypp/zypp.conf will have been be removed
and the system will continue to use the distributed vendor defaults.
A modified /etc/zypp/zypp.conf will stay in place, so the modified settings
still apply. You may nevertheless want to consider to store your changed settings
in a drop-in file in /etc/zypp/zypp.conf.d/*.conf and afterwards remove your
/etc/zypp/zypp.conf.
See the FILES section in ZYPP.CONF(5) to learn more about the two methods of
overriding the vendor provided configuration.
Well, I did that … and also the UAPI.6 Configuration Files Specification. But perhaps my interpretation is wrong.
I came to the result, that creating a file /etc/zypp/zypp.conf.d/zypp.conf will lead to both /usr/etc/zypp/zypp.conf and /etc/zypp/zypp.conf.d/zypp.conf being interpreted. But having /etc/zypp/zypp.conf instead of /etc/zypp/zypp.conf.d/zypp.conf will prohibit reading /usr/etc/zypp/zypp.conf first. If this removes the problem, then we should look for problems combining the files.
# systemctl status purge-kernels
○ purge-kernels.service - Purge old kernels
Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled; preset: enabled)
Active: inactive (dead)
Condition: start condition unmet at Thu 2026-06-04 13:48:43 CEST; 9min ago
└─ ConditionPathExists=/boot/do_purge_kernels was not met
Jun 04 13:48:43 localhost systemd[1]: Purge old kernels skipped, unmet condition check ConditionPathExists=/boot/do_purge_kernels
The file format supports multiple sections, each of which can contain multiple key-value assignments. A section is introduced by a line containing the section name enclosed in square brackets, like
[name]
and decided to try karlmistelberger’s counsel re using touch to create the necessary file:
# touch /boot/do_purge_kernels
I then followed his steps to initiate the purge-kernels.service.
systemctl start purge-kernels.service
systemctl status purge-kernels.service
I’m on another box now, can’t cut and paste output. But: the results were promising. As in his quoted example in the 2023 thread, the system read the configuration and did the purge.
However, the file /boot/do_purge_kernels was no longer to be found after reboot.
Only a small sidenote. Keeping only one kernel is not the definition of “keeping the system slim and minimal”. It is the definition of shooting yourself in the knee.
Staying with the sane system default of keeping two kernels, leaves you with a fallback when something goes wrong with your system. You have the possibility to choose the last working kernel from the Grub2 menu without need to use an old snapper snapshot.
/etc/zypp/zypp.conf overrides the whole /usr/etc/zypp/zypp.conf which is not read at all;
/etc/zypp/zypp.conf.d/zypp.conf adds or changes only those settings that explicitly set there, but other vendor settings in /usr/etc/zypp/zypp.conf still apply.
So should my fix be to put chattr +i on the /boot/do_purge_kernels file, and keep an eye on it if more than the desired number of kernels appear? That will leave me better off than I was, but it feels pretty kludge-y. Should I file a bug report?
??? Leave do_purge_kernels alone, it is not meant to be touched by users but is created whenever a new kernel is installed.
Clean up your zypp.conf according to your needs and let the system do its job.
I’ll wait and see, then. Now that you’ve helped me correctly format Slowroll’s zypp.conf in /etc/zypp/zypp.conf.d, I’ll keep fingers crossed and hope that kernel deletion proceeds as smoothly as it does in Tumbleweed.