List of versioned kernels is not right for Ubuntu

[Jarno Suni]

The following command outputs the list:
$ apt-config dump --no-empty --format '%v%n' 'APT::VersionedKernelPackages'
linux-image
linux-headers
linux-image-extra
linux-signed-image
kfreebsd-image
kfreebsd-headers
gnumach-image
.*-modules
.*-kernel
linux-backports-modules-.*
linux-tools

but the list does not 'contain linux-.*-tools' and 'linux-goldfish-headers', which are versioned kernel packages as well, if I have understood correctly.

On the other hand are these values appropriate for Ubuntu?
kfreebsd-image
kfreebsd-headers
gnumach-image
.*-modules
.*-kernel

Same thing for Ubuntu 14.04.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apt 1.2.12~ubuntu16.04.1
ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
Uname: Linux 4.4.0-31-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: XFCE
Date: Fri Jul 29 18:55:50 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-11-21 (250 days ago)
InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: apt
UpgradeStatus: Upgraded to xenial on 2016-06-24 (35 days ago)

[Julian Andres Klode (juliank)]

There are no 'linux-goldfish-headers' packages. In fact, there is no package with goldfish in its name in yakkety.

Regarding 'linux-.*-tools', there is "linux-cloud-tools" which is missing.

Concerning the second part: They are mostly irrelevant, but they don't hurt. Better than keeping a packaging diff just to have a few lines less in an automatically generated config file... I think the modules part might be useful if you build stuff with module-assistant, but not sure.

So, unless I missed something, I'm going to fix the linux-cloud-tools (or linux-.*-tools, but that might be too broad?) part and thats it.

In any case, if that's an issue for you, you can easily work around it by adding your own stuff to "APT::VersionedKernelPackages".

[Jarno Suni (jarnos)]

This lists packages containing "goldfish": http://packages.ubuntu.com/search?keywords=goldfish&searchon=names&suite=all&section=all
According to it there is linux-goldfish-headers-3.4.0-4 for yakkety
Please note that I am talking about versioned kernel packages.
In Trusty,
apt-cache search --names-only '.*' | awk '/^linux-.+-[0-9]+\.[0-9]+.+/{print $1}' | grep linux-.*-tools
gives currently 473 matches of which 165 does not match "linux-cloud-tools" such as linux-goldfish-tools-3.4.0-3 and linux-lts-xenial-tools-4.4.0-31.

I have been creating a script that keeps linux kernel packages that have certain version and purge other linux kernel packages, so I was just wondering, if I have to care about the other operating systems. I am neither familiar with the kernels of other operation systems than linux nor their versioning. Do linux, kfreebsd and gnumach possibly share a version? It is hard to use the configuration variable to purge linux kernels exclusively for what it is worth.

[David Kalnischkies (donkult)]

btw: "apt-cache pkgnames" should have better/quicker result than searching.

Don't know what that goldfish is nor am I particular interested in cloud, but I guess they could be added if there is need/interest. Its not like there is any real cost attached to it and false positives are pretty unlikely with the kernel versions attached… in the case of goldfish it seems to be unneeded through as they have "normally" named images/headers packages, too, which depend on the strange ones, so the autoremover wouldn't kick in anyhow for those.

kfreebsd, gnumach (= hurd) do not share the same version, they do share the kernel postinst scripts which apt is using here through, so even through they use entirely different version schemes, its still a version we can work with. Excluding specific items depending on the architecture we built apt for would be possible, but not really worth the implementation effort I presume.

And yes, -modules/-kernel is for out-of-tree modules as created by module-assistant (from -source packages), but I think dkms can built packages, too, and its the naming scheme which tends to be used for packages for modules which happen to be distributable as binary builds… (not that there would be many).

[Jarno Suni (jarnos)]

If I purge other versioned kernel packages than the ones given, probably all kfreebsd and gnumach kernels will be purged.

Thus, I suppose I could use an (extended) regular expression to match versioned Linux kernel packages:
^linux-.+-[0-9]+\.

[Jarno Suni (jarnos)]

Nowadays "linux-cloud-tools" has been listed in VersionedKernelPackages in /etc/apt/apt.conf.d/01autoremove in Xenial. However, there might be other versioned cloud packages that
apt-cache search --names-only 'linux-.*-tools'
lists such as the ones that start with linux-hwe.

[Balint Reczey (rbalint)]

In the proposed fix for LP: #1821640 there is an autopkgtest to catch missing patterns.
It is scheduled to be fixed in Disco +1.

It is not an exact duplicate, because this bug covers very old packages to match (for autoremoval this makes sense IMO), while the other one covers the patterns for current packages.

[Jarno Suni (jarnos)]

Balint, I do not understand what you mean by that this bug covers very old packages vs. the other covers current ones.

Patterns

linux-modules
linux-modules-extra
linux-modules-.*
linux-cloud-tools

have been added to APT::VersionedKernelPackages after reporting this bug. linux-modules is not excessive as '.*-modules' already covers that.

[Jarno Suni (jarnos)]

I meant linux-modules is excessive.

[Jarno Suni (jarnos)]

In my linux-purge script (https://launchpad.net/linux-purge) I use extended regular expression '^linux-.+-[0-9]+\.[0-9]+\.' to match versioned kernel package names and it has worked so far.

[Manfred Hampl (m-hampl)]

What about packages like

linux-modules-extra-3.13.0-168-generic

Two versions ago (starting with 3.13.0-166) the former linux-image-extra-* packages have been renamed to linux-modules-extra-*

I do not see any provision for these in /etc/apt/apt.conf.d/01autoremove and 01autoremove-kernels on my trusty system (apt 1.0.1ubuntu2.23), and indeed "apt autoremove" deleted the linux-image-extra package belonging to the "running kernel minus one" kernel version.

[Julian Andres Klode (juliank)]

Added this to my list of things so I don't forget about it; might look into it next week.

[Julian Andres Klode (juliank)]

I think we can go with a simple catch all of linux-.* as in

https://salsa.debian.org/apt-team/apt/merge_requests/59

For explanation as to why this works: apt takes the listed patterns, then appends the kernel versions to it, and then anchors it. So, with linux-.* you end up with patterns:

   "^linux-.*-5\.0\.0-11-generic$";
   "^linux-.*-5\.0\.0-8-generic$";

This should catch all versioned linux packages, and should also catch all future ones, as long as they start with linux-

[Balint Reczey (rbalint)]

Adding unattended-upgrades because it may remove kernel packages accidentally and also it has autopkgtest to look for missed kernel packages which is now failing.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apt - 1.9.9

---------------
apt (1.9.9) experimental; urgency=medium

  * Widen regular expressions for versioned kernel packages (LP: #1607845)
  * Implement short patterns (patterns starting with ~)

 -- Julian Andres Klode <email address hidden> Tue, 04 Feb 2020 17:42:21 +0100

[Balint Reczey (rbalint)]

Marking invalid for u-u since apt is fixed and now u-u autopkgtest passes.