Keeping an old kernel using zypp.conf


This is a follow on to the thread in Virtualisation and the upgrade to kernel 5.8 meaning that VirtualBox didn’t work (although it’s fixed now)

I posted that it was possible to edit


and put an entry like

# multiversion.kernels = latest,latest-1,running
multiversion.kernels = latest,latest-1,latest-2,5.7.11-1,running

And although I had kernel 5.7.11-1 at the time I made that entry, it has now gone

but I do have several 5.8 kernels, so it has kept latest, latest-1,latest-3 but the one I specifically wanted to keep (5.7.11-1) was removed

And it’s not just the files in /boot that I’d carefully made a tgz of


but obviously when zypper dup removed 5.7.11-1 it also removed all the relevant files from /usr/src/ too

(which I very stupidly did not think to make a copy of - oops)

I was following the instructions on
section 6.1.4

So theoretically it should have worked unless it really, really should say that I need to specify


In which case the documentation should probably be changed?

Any thoughts?



I am using:

multiversion.kernels = oldest,latest,latest-1,running

and I still have 5.7.11.

% ls /boot/vmlinuz*
/boot/vmlinuz                   /boot/vmlinuz-5.8.2-1-default
/boot/vmlinuz-5.7.11-1-default  /boot/vmlinuz-5.8.4-1-default

So kernel 5.8.0 has disappeared, but 5.7.11 is still there.

Eventually, I will manually remove that kernel, and another one will become the oldest.

There was a time when I used “oldest,oldest+1,latest,latest-1,running”, so that I could keep both a 5.4 kernel and a 5.5 kernel after we went to a 5.6 kernel. But the problem I was dealing with has been fixed. I’m use “oldest” for the most recent of the previous series. When we go to a 5.9 kernel, I will remove 5.7.11 and allow the oldest to refer to a 5.8 kernel. It just seems good practice with Tumbleweed.

Ah, thanks for that, using “oldest” would have worked as per your example

But why didn’t specifying, as I did

multiversion.kernels = latest,latest-1,latest-2,5.7.11-1,running

keep my 5.7.11-1 kernel

Is the documentation wrong? Or does that only apply to Leap, not Tumbleweed?

I don’t know why that happened. I can only guess.

I’m guessing that if you had used “5.7.11” instead of “5.7.11-1”, it would have worked.

If you check the example at /etc/zypp/zypp.conf I think that the correct number should be 5.7.11-1.2 and the trailing “.2” (or whatever build it was) was apparently missing in your entry.
Sorry I cannot check myself in a system ATM.
And yes, apparently the documentation you referenced is wrong if /etc/zypp/zypp.conf is correct.

It turns out that I was testing that as you were posting.

Using “5.7.11-1.2” works.

How I tested:

I first made a copy of my existing “zypp.conf” so that I could restore it.

Then I made the change to using “5.7.11” and that did not work. To test, I used

zypper purge-kernels

and it told me what it would do. I responded to the prompt with “n” (no, don’t do that), so it would keep the kernel.

Next, I tried “5.7.11-1.2” which worked. Then “5.7.11-1” which did not work. And finally, I restored my original “zypp.conf”

Version-release without rebuild counter is supposed to match any rebuild (i.e. 5.7.11-1 should match 5.7.11-1.1, 5.7.11-1.2, …).

This is a bug, you should open bug report with zypper logs.

… it seems to be introduced by commit

commit 9c842b20aba435bbcbbf329686fca33f845d2cd0
Author: Benjamin Zeller <>
Date:   Wed Aug 19 16:43:15 2020 +0200

    Support buildnr with commit hash in purge-kernels (fixes bsc#1175342)
    This adds special behaviour for when a kernel version has the rebuild
    counter before the kernel commit hash:

Before this commit libzypp stripped trailing rebuild counter. After this commit it only strips rebuild counter if release number contains GIT hash (i.e. comes from kernel repository).

Ok, thanks, quite a lot of useful comments here

Looks as though I should have read the /etc/zypp/zypp.conf a bit more carefully, as it also says

## Note: This entry is not evaluated by libzypp, but by the
##       purge-kernels service (via /sbin/purge-kernels).

So that would have told me how to test it…

At least it does appear that it is a bug, too, as per arvidjaar’s post above

That comment (in “zypp.conf”) is another bug. They invented a new zypper command – “zypper purge-kernels” and the purge-kernels service now uses that. So now it is evaluated by libzypp.

Thanks for submitting the bug.

So, my problem now is:

How can I re-install kernel 5.7.11-1 as it appears to have disappeared because of a bug when I had followed the documentation that should have held it?

This is because there are still some issues with Virtualization with kernel 5.8 (and I do appreciate the fixes that Larry Finger has done to make VirtualBox load with 5.8, but at this point I have no audio in my VMs)
(and there may be other problems I haven’t found yet)

(and I appreciate, yes, I am using Tumbleweed, so I can should things to break, but in this case I followed what should have been the OpenSUSE way to keep a 5.7 kernel, and there is a bug)

So what is the OpenSUSE way to go back to a older kernel?

also, while we’re at it, there should be a way to use /etc/default/grub to always boot into a SAVEDEFAULT kernel

The bug report from a couple of year ago says there was a patch submitted, but the bug is still here in Tumbleweed



also, while we’re at it, there should be a way to use /etc/default/grub to always boot into a SAVEDEFAULT kernel

One thread - one question.

Thanks for that

(and yes, I was being cheeky, sorry)

Should I add to the thread from 2017 (about grub SAVEDEFAULT) , or should I start a new one, as the issue still seems to exist?

(and yes, I’ve broken that rule again… sorry)

Better start a new one. Nobody (a bit exegarated) will look at such an old thread to see if somebody wants to comment on it.
A new thread comes to the top when people browse the forums.

These “rules” (in fact good meaning suggestions) are for your own benefit. You need to advertise your problem to the people that matter as good as possible. Don’t you think?