4

TL;DR: Why are there Kernel image packages of the same version but with a different dash number? Currently offered on the main and securiry updates feed are, for the "regular" amd64 variety,

  • linux-image-4.19.0-6-amd64
  • linux-image-4.19.0-8-amd64

and on the backports feed

  • linux-image-5.4.0-0.bpo.2-amd64
  • linux-image-5.4.0-0.bpo.3-amd64
  • linux-image-5.4.0-0.bpo.4-amd64
  • linux-image-5.5.0-0.bpo.2-amd64-unsigned (signed not yet there)

What should I make of the number after dash (6 and 8) for 4.19, and the number after -bpo. (2, 3, 4) for the backport kernels? They seem to restart at 2 at every major (why 2? We the geeks count for 0 up, and the rest of the population from 1 up, which is quite an inconvenience already. But 2???)


Longer version with apt-cache data. I installed Buster on an x64 VM, and updated kernel to the version 5.3 from the backports archive some time ago to work around an issue with HyperV. It all works to this day. I'm experienced running both development and production systems, hold on to the maxim "if it's not broken, don't fix it," and read release notes if I am going for something like this.

I cannot find the documentation on the Debian kernel image package numbering practice, however. Not what these numbers mean (this is in Debian package builder's guide), but why the kernel team uses this numbering, and what benefit do I, as the user, get from it.

Recently I noticed the version 5.3 is no longer offered, as it likely expired in the mainline. I thought maybe I should go with 5.4, especially given it's a relatively Longterm kernel, so I can run it on this dev VM for a while and then stick to it and think of possible benefits of it in production. This was when I realized that there is more than one package available for the same image package. And then, the Buster's original kernel package, 4.19, comes in two package versions. The original was -6, now only in security maintenance, and -8, on both the main and security feeds. This I at the least can make sense^H^H^H a just so story of (4.19 is also "short" Longterm, supported till 2020-12, the -6 must receive security patches updates from upstream while it lasts).

But what about the 3 different bpo.N versions? I cannot find the documentation on the Debian kernel image package numbering practice, however. Not what these numbers mean (this is in the Debian package author guide), but why the kernel team uses this numbering, and how do I, as the user, get the most benefit out of it.

Also, if you scan the deb versions, only the linux-image-4.19.0-6-amd64, deb version 4.19.67-2+deb10u2, and my current 5.3.9-2~bpo10+1 have a telltale dash-bump of an update. Every other deb seems to be at the patch level -1. So... I'm kinda lost my way entirely. What should I make out of it? Are these bpo.2, 3, etc packages kinda "frozen" minor Kernel versions, and are projected to be receiving only security maintenance patches?

What I currently see from apt-cache policy for all "unqualified" amd64 packages, except 5.5 which is not coming in a signed version yet, and removing Candidate: and Installed: (none) for easier readability:

linux-image-4.19.0-6-amd64:
  Version table:
     4.19.67-2+deb10u2 500
        500 https://deb.debian.org/debian-security buster/updates/main amd64 Packages
linux-image-4.19.0-8-amd64:
  Version table:
     4.19.98-1+deb10u1 500
        500 https://deb.debian.org/debian-security buster/updates/main amd64 Packages
     4.19.98-1 500
        500 https://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status
linux-image-5.3.0-0.bpo.2-amd64:
  Installed: 5.3.9-2~bpo10+1
  Version table:
 *** 5.3.9-2~bpo10+1 100
        100 /var/lib/dpkg/status
linux-image-5.4.0-0.bpo.2-amd64:
  Version table:
     5.4.8-1~bpo10+1 100
        100 https://deb.debian.org/debian buster-backports/main amd64 Packages
linux-image-5.4.0-0.bpo.2-amd64:
  Version table:
     5.4.8-1~bpo10+1 100
        100 https://deb.debian.org/debian buster-backports/main amd64 Packages
linux-image-5.4.0-0.bpo.3-amd64:
  Version table:
     5.4.13-1~bpo10+1 100
        100 https://deb.debian.org/debian buster-backports/main amd64 Packages
linux-image-5.4.0-0.bpo.4-amd64:
  Version table:
     5.4.19-1~bpo10+1 100
        100 https://deb.debian.org/debian buster-backports/main amd64 Packages
linux-image-5.5.0-0.bpo.2-amd64-unsigned:
  Version table:
     5.5.17-1~bpo10+1 100
        100 https://deb.debian.org/debian buster-backports/main amd64 Packages
0

1 Answer 1

6

The last number between dashes is the ABI number. In packages you’ll see in unstable, testing, or stable, it starts at 1, with the first upload of new kernel series (the first upload of a 4.19 kernel, a 5.4 kernel, etc.), and is incremented whenever the ABI changes. (See Debian Linux kernel versioning for details.)

The backported kernels have their ABI set to “0.bpo.N”, where N is the ABI number of the kernel used for the backport. Backports are only allowed once a package reaches testing, which is why you won’t necessarily see sequential values of N.

Backports are not maintained separately, they generally only receive updates from testing. Every time a kernel package is updated from testing, it follows the pattern given above.

3
  • Thanks, super! I think I'm starting to grok it now. If you do not mind, what is exactly meant by ABI here: the interface between the kernel and OOT modules in binary form? In other words, is my understanding correct: all OOT modules must be recompiled if, and only if the last dash portion, debian_revision, changes; otherwise (in theory, at the least) the image may be replaced in-place without effects like corruption of a call frame? I'm wondering as my feeling was that DKMS kicked in on lesser upgrades (I'm using 3rd-party computing GPU drivers, non-.deb). I would not swear it did, tho. May 5, 2020 at 3:25
  • That’s exactly it; quoting the answer to the linked question, “a number which is bumped every time the kernel ABI changes in an incompatible way — in terms which matter to users, whenever out-of-tree modules need to be recompiled” ;-). DKMS shouldn’t kick in unless the ABI changes... May 5, 2020 at 5:39
  • Thank you very much! I'm not really sure that I'm correct about DKMS. That was on Ubuntu, which is quite fast-paced on updates, so it seemed that I was seeing DKMS doing its thing too often, compared to Debian. : ) May 5, 2020 at 18:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .