Kernel packages: retaining more than expected

English Install/Boot/Login
1

I edited my /etc/zypp/zypp.conf file to retain the ‘latest’ and ‘running’ kernels, with this line:

multiversion.kernels = latest,running

But when I run

**#** zypper se -si 'kernel*'

I get:

S  | Name                        | Type    | Version      | Arch   | Repository
---+-----------------------------+---------+--------------+--------+----------------------
i+ | kernel-default              | package | 5.6.8-1.1    | x86_64 | Main Repository (OSS)
i  | kernel-default-devel        | package | 5.6.8-1.1    | x86_64 | Main Repository (OSS)
i  | kernel-devel                | package | 5.6.6-1.1    | noarch | (System Packages)
i  | kernel-devel                | package | 5.6.4-1.1    | noarch | (System Packages)
i  | kernel-devel                | package | 5.6.2-1.2    | noarch | (System Packages)
i  | kernel-devel                | package | 5.6.2-1.1    | noarch | (System Packages)
i  | kernel-devel                | package | 5.6.8-1.1    | noarch | Main Repository (OSS)
i  | kernel-firmware-all         | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-amdgpu      | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-ath10k      | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-atheros     | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-bluetooth   | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-bnx2        | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-brcm        | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-chelsio     | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-dpaa2       | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-i915        | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-intel       | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-iwlwifi     | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-liquidio    | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-marvell     | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-media       | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-mediatek    | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-mellanox    | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-mwifiex     | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-network     | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-nfp         | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-nvidia      | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-platform    | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-qlogic      | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-radeon      | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-realtek     | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-serial      | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-sound       | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-ti          | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-ueagle      | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-firmware-usb-network | package | 20200424-1.1 | noarch | Main Repository (OSS)
i  | kernel-macros               | package | 5.6.8-1.1    | noarch | Main Repository (OSS)
i  | kernel-source               | package | 5.6.4-1.1    | noarch | (System Packages)
i  | kernel-source               | package | 5.6.2-1.2    | noarch | (System Packages)
i  | kernel-source               | package | 5.6.2-1.1    | noarch | (System Packages)
i  | kernel-source               | package | 5.6.8-1.1    | noarch | Main Repository (OSS)
i  | kernel-syms                 | package | 5.6.8-1.1    | x86_64 | Main Repository (OSS)

… and wonder why the 5.6.2-1. packages haven’t been purged. Am I doing something wrong? Is there another setting I can tinker with to get rid of the 5.6.2 kernels?

FWIW: zypper purge-kernels reports nothing to do. I’m on snapshot 20200503.

2

Hi
Does the file /boot/do_purge_kernels exist? If not touch it and re-run;


ls /boot/do_purge_kernels

touch /boot/do_purge_kernels

/usr/bin/zypper --non-interactive purge-kernels
3

I confirm. It seems zypper has problems removing generic (not kernel flavor specific) packages. If you look in logs, you will see something like

Skipping source package kernel-devel-x.x.x no corresponding kernel with the same version was installed

Open bug report and post number here.

/boot/do_purge_kernels only needed to trigger service run on boot. zypper itself does not care for this file.

4

My experience is that it only removes the “-devel" packages for a kernel when it also removes the kernel. If I manually remove a kernel, then the next “purge-kernels” will not remove the "-devel” package that I failed to manually remove.

The logic for purge-kernels seems to be:

  • Find any installed kernels that should be removed;
  • also remove associated “*-devel” packages.

Manually removing a kernel but not manually removing the corresponding "-devel" will leave that "-devel* behind.

I’m not sure whether this counts as a bug or a feature. I’m thinking that there might sometimes be reasons to retain the *-devel" but not the kernel.

5

You won’t know until you open bug report.

I’m thinking that there might sometimes be reasons to retain the *-devel" but not the kernel.

There are two kinds of *-devel packages. One is specific to binary kernel (kernel-flavor-devel). These are removed by zypper. Another one is generic, not tied to particular binary kernel - kernel-devel. zypper removes the former and leaves the latter.

I think it is a bug because it was not the case before with separate purge-kernels utility, before switch to zypper. I certainly do not have kernel-devel versions since the very first TW installation. I checked purge-kernels on Leap 15 and it explicitly removes kernel-devel and kernel-source for which no binary kernels are present. We may argue whether it should do it, but for now it is regression.

I suspect somehow condition got reversed in zypper implementation - now it skips kernel-devel for which no corresponding binary kernel is installed.

6

Hmm, you are right:


# zypper se -si kernel
Loading repository data...
Warning: Repository 'Main Update Repository' appears to be outdated. Consider using a different mirror or server.
Warning: Repository 'Update Repository (Non-Oss)' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...

S  | Name                  | Type    | Version            | Arch   | Repository
---+-----------------------+---------+--------------------+--------+------------------
i+ | kernel-default        | package | 5.3.18-lp152.10.4  | x86_64 | (System Packages)
i+ | kernel-default        | package | 5.3.18-lp152.11.3  | x86_64 | Main Repository
i  | kernel-default-devel  | package | 5.3.18-lp152.10.4  | x86_64 | (System Packages)
i  | kernel-default-devel  | package | 5.3.18-lp152.11.3  | x86_64 | Main Repository
i+ | kernel-devel          | package | 5.3.18-lp152.10.4  | noarch | (System Packages)
i+ | kernel-devel          | package | 5.3.18-lp152.10.3  | noarch | (System Packages)
i+ | kernel-devel          | package | 5.3.18-lp152.10.1  | noarch | (System Packages)
i+ | kernel-devel          | package | 5.3.18-lp152.4.4   | noarch | (System Packages)
i+ | kernel-devel          | package | 5.3.18-lp152.4.3   | noarch | (System Packages)
i+ | kernel-devel          | package | 5.3.18-lp152.11.3  | noarch | Main Repository
i  | kernel-firmware       | package | 20200107-lp152.1.1 | noarch | Main Repository
i  | kernel-macros         | package | 5.3.18-lp152.11.3  | noarch | Main Repository
i+ | nfs-kernel-server     | package | 2.1.1-lp152.8.2    | x86_64 | Main Repository
i  | purge-kernels-service | package | 0-lp152.3.1        | x86_64 | Main Repository

Yes, there are “kernel-devel” for which the corresponding “kernel-default-devel” has been removed.

I’m not sure how that happened. When removing kernels manually, I always removed both. Then I started using “zypper purge-kernels”, and I probably didn’t pay close attention then. Now I am relying on the service, and paying even less attention.

I’ll clean it up for now, then monitor what happens in future.

7

I cleaned that up. Now, looking more closely, I see a different issue. It shows (for kernel-devel), both versions 5.3.18-lp152.10.4 and 5.3.18-lp152.10.3 are present.

  • Why wasn’t there a file collision between those?
  • For the kernel itself, version 5.3.18-lp152.10.3 was not removed by purge-kernels. Rather, it was removed by “zypper dup” during an update. Why didn’t that also happen to kernel-devel?

Yes, that does look like a bug.

8

Yes, that’s different. Start new thread? :slight_smile:

Why wasn’t there a file collision between those?

RPM allows file to be owned by several packages as long as file attributes are identical in each package. kernel-devel contains only (part of) kernel source tree which is not changed by rebuilding package.

For the kernel itself, version 5.3.18-lp152.10.3 was not removed by purge-kernels. Rather, it was removed by “zypper dup” during an update. Why didn’t that also happen to kernel-devel?

I think that rebuild of binary kernel RPM changes something (at least compile stamp or similar) which leads to conflict so older version is removed.

9

I’m not so sure that it is different.

Well, sure, it’s for Leap 15.2 instead of Tumbleweed.

I looked at a Tumbleweed system, and saw the same thing. There were additional “kernel-devel” that had not been removed. And they all appeared to be cases where a newer recompile had been installed without removing the original. I’m not sure, but perhaps that’s also the case for the OP.

In any case, this is surely a bug somewhere. I’ll open a bug report later (unless I find an existing one).

I only see the problem with relatively recent kernels, from after the purge-kernels service was revamped.

10

I filed a bug report:
Bug 1171224 Older kernel-devel packages are not properly purged.

11

Thanks very much for the replies, malcolmlewis, arvidjaar and nrickert! I’ll bookmark the bug report filed by nrickert and wait for a resolution. Looks like I wasn’t alone … <g>

12

https://bugzilla.suse.com/show_bug.cgi?id=1172073