zypper dup removes running kernel and ignores old ones

If I run “zypper dup” and get a kernel update it removes the latest versions of kernel-default and kernel-default-devel, even if that’s the running kernel. All old kernels are just left forever, and so are kernel packages other than those ones.

On 05/02/2017 02:26 AM, LinAGKar wrote:
>
> If I run “zypper dup” and get a kernel update it removes the latest
> versions of kernel-default and kernel-default-devel, even if that’s the
> running kernel. All old kernels are just left forever, and so are kernel
> packages other than those ones.
>
>

openSUSE tumbleweed

I can confirm this action as well which is not what is expected.


Ken
linux since 1994
S.u.S.E./openSUSE since 1996

Recommend submit a bug to https://bugzilla.opensuse.org

Be sure to provide details, including the directory contents of kernels.

TSU

On 05/02/2017 11:56 AM, tsu2 wrote:
>
> Recommend submit a bug to https://bugzilla.opensuse.org
>
> Be sure to provide details, including the directory contents of kernels.
>
> TSU
>
>

By “directory contents” I guess you mean the /boot directory.

Bug number: 1037250


Ken
linux since 1994
S.u.S.E./openSUSE since 1996

You are describing an apparent bug, which I am not seeing.

However, I do see some things that look similar but are not bugs. So let me describe those, and you can decide if it fits.

1: Remove running kernel

Looking at “/boot” for my Tumbleweed system, I currently see two kernels:
vmlinuz-4.10.10-1-default
vmlinuz-4.10.12-1-default

As far as I know, that’s what I should be seeing.

Let’s suppose that the next update provides “kernel-default-4.10.12-3”.

In my experience, the result will be to remove “kernel-default-4.10.12-1” and install “kernel-default-4.10.12-3”.

So here’s what is going on. That newest kernel would be just a re-compile of the previous kernel. Only the minor version number changed (the last number), which is what happens with a recompile.

A year ago, what would have happened was that the new kernel would be installed. And then, after reboot, the oldest kernel would be removed. And that would leave me with two kernels which were really the same kernel just recompiled. So I would really only have one kernel and no alternative. I think the current system is better, in that it leaves with with two different kernels.

2: Failure to delete older kernels

This is a different issue. The older kernels are supposed to be removed by the “purge-kernels” service. Apparently, on some systems, that service is not enabled. I suggest you use
Yast –> System –> Services Manager
and make sure that the service is enabled.

I haven’t run into this problem. But my understanding is that if you installed from live media (live KDE or live Gnome), you would run into this. It shouldn’t happen for recent installs, since live media now use the NET installer instead of the old Yast Live Installer.

If that’s your issue, then enable the service. And old kernels should be cleared out on the first boot after the next kernel update. You can force that manually, but it is easier to wait for the next update since those are frequent enough on Tumbleweed.

NOTE: Back in the bad old days, before there was support for multi-version kernels, an update would always delete the running kernel and then install the new. I once had it remove the running kernel, and then fail on a network error before installing the new kernel. Fortunately, I noticed the error message and was able to go into Yast to manually force the install of the newest kernel. Otherwise my system would have been unbootable.

No, this is wrong. Pure recompile is 4.10.12-1.1 to 4.10.12-1.3. Your example means new version.

And this is indeed what happens. Right now “zypper dup” wants to install 4.10.12-1.2 and remove 4.10.12-1.1. These two packages cannot be installed together at all - they overlap each other. In the past it would result in file conflicts during install. So the behavior is correct. Just to stress - it has **always **behaved this way, there is nothing new.

To allow for these two packages to coexist kernel version scheme must be changed to include “rebuild count”. Not sure how easy it is.

P.S. and “zypper up” would skip kernel package entirely. Now this is interesting topic for discussion. We already got option to prevent vendor change during “zypper dup”. May be we also need an option to preserve current kernel if new version is pure rebuild. Something to discuss on factory/kernel lists I figure.