Cannot see update to recent linux kernel 5.10.19-1~bpo10+1 (from 5.10.13-1~bpo10+1)

l0f...@tuta.io

unread,

Mar 21, 2021, 6:30:03 PM3/21/21

to

Hi,

I'm running the following kernel:

$ uname -a
Linux 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux

Backports repository is configured:

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ buster main contrib non-free
deb-src http://deb.debian.org/debian/ buster main contrib non-free

deb http://security.debian.org/debian-security buster/updates main contrib non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib non-free

deb http://deb.debian.org/debian/ buster-updates main contrib non-free
deb-src http://deb.debian.org/debian/ buster-updates main contrib non-free

deb http://deb.debian.org/debian/ buster-backports main contrib non-free
deb-src http://deb.debian.org/debian/ buster-backports main contrib non-free

However, apt doesn't inform me about new version 5.10.19-1~bpo10+1 (according to https://tracker.debian.org/pkg/linux):

$ sudo apt update
[...]
Hit:3 http://deb.debian.org/debian buster-backports InRelease
[...]
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

apt policy doesn't see any newer version as well:

$ apt policy linux-image-5.10.0-0.bpo.3-amd64
linux-image-5.10.0-0.bpo.3-amd64:
Installed: 5.10.13-1~bpo10+1
Candidate: 5.10.13-1~bpo10+1
Version table:
*** 5.10.13-1~bpo10+1 100
        100 http://deb.debian.org/debian buster-backports/main amd64 Packages
        100 /var/lib/dpkg/status

Could you explain me why I can't update to 5.10.19-1~bpo10+1?
Is something misconfigured somewhere please?
Are mirrors simply not up to date yet (5 days old)?
Thanks in advance :)
Best regards,
l0f4r0

Geoff Reidy

unread,

Mar 21, 2021, 11:20:04 PM3/21/21

to

l0f...@tuta.io wrote:

>
> $ apt policy linux-image-5.10.0-0.bpo.3-amd64
> linux-image-5.10.0-0.bpo.3-amd64:
> Installed: 5.10.13-1~bpo10+1
> Candidate: 5.10.13-1~bpo10+1
> Version table:
> *** 5.10.13-1~bpo10+1 100
> 100 http://deb.debian.org/debian buster-backports/main amd64 Packages
> 100 /var/lib/dpkg/status
>

You're probably missing the metapackage, linux-image-amd64.

Regards.

didier gaumet

unread,

Mar 22, 2021, 3:40:05 AM3/22/21

to

Hello,

There is a linux-image-5.10.0-0.bpo.3-amd64 package but
linux-image-5.10.0-0.bpo.4-amd64 has yet to be uploaded
(linux-image-5.10.0-0.bpo.4-amd64-unsigned is there already)

Andrei POPESCU

unread,

Mar 22, 2021, 7:20:04 AM3/22/21

to

On Du, 21 mar 21, 23:28:04, l0f...@tuta.io wrote:
>
> apt policy doesn't see any newer version as well:
>
> $ apt policy linux-image-5.10.0-0.bpo.3-amd64
> linux-image-5.10.0-0.bpo.3-amd64:
> Installed: 5.10.13-1~bpo10+1
> Candidate: 5.10.13-1~bpo10+1
> Version table:
> *** 5.10.13-1~bpo10+1 100
> 100 http://deb.debian.org/debian buster-backports/main amd64 Packages
> 100 /var/lib/dpkg/status
>
> Could you explain me why I can't update to 5.10.19-1~bpo10+1?

When Linux has significant updates the package name changes as well to
signal that e.g. out-of-tree modules must be recompiled.

Try this instead:

apt list linux-image-5*

To have apt install the latest *signed* kernel from a given archive you
should install the corresponding 'linux-image-amd64' package.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

signature.asc

The Wanderer

unread,

Mar 22, 2021, 7:20:04 AM3/22/21

to

Are you sure that's it?

I thought the same thing at first, but when I looked at the 'testing'
link in the 'versions' sidebar from https://tracker.debian.org/pkg/linux
I saw the same '-amd64-unsigned present, -amd64 missing' pattern for
linux-image-5.10.0-4 listed, even though 'apt-cache policy' on my system
shows both that and the -amd64-unsigned package as being available in
current testing.

I was guessing maybe the signing process leads to that package not being
listed on those pages, but maybe you know something I don't, or maybe
the -amd64 version of the testing package *is* there and I'm just
managing to miss it?

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

signature.asc

The Wanderer

unread,

Mar 22, 2021, 7:30:04 AM3/22/21

to

On 2021-03-22 at 07:22, Andrei POPESCU wrote:

> On Lu, 22 mar 21, 07:11:46, The Wanderer wrote:
>
>> On 2021-03-22 at 03:31, didier gaumet wrote:
>>
>>> Hello,
>>>
>>> There is a linux-image-5.10.0-0.bpo.3-amd64 package but
>>> linux-image-5.10.0-0.bpo.4-amd64 has yet to be uploaded
>>> (linux-image-5.10.0-0.bpo.4-amd64-unsigned is there already)
>>
>> Are you sure that's it?
>>
>> I thought the same thing at first, but when I looked at the
>> 'testing' link in the 'versions' sidebar from
>> https://tracker.debian.org/pkg/linux I saw the same
>> '-amd64-unsigned present, -amd64 missing' pattern for
>> linux-image-5.10.0-4 listed, even though 'apt-cache policy' on my
>> system shows both that and the -amd64-unsigned package as being
>> available in current testing.
>>
>> I was guessing maybe the signing process leads to that package not
>> being listed on those pages, but maybe you know something I don't,
>> or maybe the -amd64 version of the testing package *is* there and
>> I'm just managing to miss it?
>

> In any case, backports is, by definition, lagging behind testing.

Yes, but that should only be reflected in the fact that the package
version is different, not in which packages are available (barring the
case where the newer version changed which packages get built, which
doesn't apply here).

Note that I checked the stable-backports listing for the version
specified in the OP, and the testing listing for the version shown on my
system as available in testing.

If that's not the root of your point, then I'm missing it, and would be
glad to see it explained.

signature.asc

Andrei POPESCU

unread,

Mar 22, 2021, 7:30:04 AM3/22/21

to

On Lu, 22 mar 21, 07:11:46, The Wanderer wrote:

> On 2021-03-22 at 03:31, didier gaumet wrote:
>
> > Hello,
> >
> > There is a linux-image-5.10.0-0.bpo.3-amd64 package but
> > linux-image-5.10.0-0.bpo.4-amd64 has yet to be uploaded
> > (linux-image-5.10.0-0.bpo.4-amd64-unsigned is there already)
>
> Are you sure that's it?
>
> I thought the same thing at first, but when I looked at the 'testing'
> link in the 'versions' sidebar from https://tracker.debian.org/pkg/linux
> I saw the same '-amd64-unsigned present, -amd64 missing' pattern for
> linux-image-5.10.0-4 listed, even though 'apt-cache policy' on my system
> shows both that and the -amd64-unsigned package as being available in
> current testing.
>
> I was guessing maybe the signing process leads to that package not being
> listed on those pages, but maybe you know something I don't, or maybe
> the -amd64 version of the testing package *is* there and I'm just
> managing to miss it?

In any case, backports is, by definition, lagging behind testing.

signature.asc

Andrei POPESCU

unread,

Mar 22, 2021, 7:50:04 AM3/22/21

to

On Lu, 22 mar 21, 07:26:27, The Wanderer wrote:
> On 2021-03-22 at 07:22, Andrei POPESCU wrote:
> >
> > In any case, backports is, by definition, lagging behind testing.
>
> Yes, but that should only be reflected in the fact that the package
> version is different, not in which packages are available (barring the
> case where the newer version changed which packages get built, which
> doesn't apply here).

Except that the package name in backports is different, i.e. the package
is rebuilt for backports (in a stable build environment) and it also has
its name changed.

> Note that I checked the stable-backports listing for the version
> specified in the OP, and the testing listing for the version shown on my
> system as available in testing.
>
> If that's not the root of your point, then I'm missing it, and would be
> glad to see it explained.

My point is that whatever is (already) in testing provides little clue
for what should be in backports, especially for linux-image packages
that have the signing step in addition to a rebuild with changing the
package name. Besides, only some linux-image versions in testing will
get a backports upload.

signature.asc

songbird

unread,

Mar 22, 2021, 9:30:04 AM3/22/21

to

The Wanderer wrote:
> On 2021-03-22 at 03:31, didier gaumet wrote:

...

>> There is a linux-image-5.10.0-0.bpo.3-amd64 package but
>> linux-image-5.10.0-0.bpo.4-amd64 has yet to be uploaded
>> (linux-image-5.10.0-0.bpo.4-amd64-unsigned is there already)
>
> Are you sure that's it?
>
> I thought the same thing at first, but when I looked at the 'testing'
> link in the 'versions' sidebar from https://tracker.debian.org/pkg/linux
> I saw the same '-amd64-unsigned present, -amd64 missing' pattern for
> linux-image-5.10.0-4 listed, even though 'apt-cache policy' on my system
> shows both that and the -amd64-unsigned package as being available in
> current testing.
>
> I was guessing maybe the signing process leads to that package not being
> listed on those pages, but maybe you know something I don't, or maybe
> the -amd64 version of the testing package *is* there and I'm just
> managing to miss it?

perhaps so because of the differences in the names?

one has the *bpo stuff in the names and the others don't?

not sure, but that does look possible...

songbird

The Wanderer

unread,

Mar 22, 2021, 7:00:06 PM3/22/21

to

(There's a suggestion of a possible answer for the OP to check out, down
at the bottom of this message.)

On 2021-03-22 at 07:49, Andrei POPESCU wrote:

> On Lu, 22 mar 21, 07:26:27, The Wanderer wrote:
>
>> On 2021-03-22 at 07:22, Andrei POPESCU wrote:
>>
>>> In any case, backports is, by definition, lagging behind
>>> testing.
>>
>> Yes, but that should only be reflected in the fact that the
>> package version is different, not in which packages are available
>> (barring the case where the newer version changed which packages
>> get built, which doesn't apply here).
>
> Except that the package name in backports is different, i.e. the
> package is rebuilt for backports (in a stable build environment) and
> it also has its name changed.

Yes, because the version is different, and (for kernels) some aspect of
the version is encoded in the package name. I consider that to fall
under the package version being different.

>> Note that I checked the stable-backports listing for the version
>> specified in the OP, and the testing listing for the version shown
>> on my system as available in testing.
>>
>> If that's not the root of your point, then I'm missing it, and
>> would be glad to see it explained.
>
> My point is that whatever is (already) in testing provides little
> clue for what should be in backports, especially for linux-image
> packages that have the signing step in addition to a rebuild with
> changing the package name. Besides, only some linux-image versions in
> testing will get a backports upload.

I still don't think I see your point - or else I entirely disagree with
it.

I was not, and am not, expecting the version in backports to be the same
as the version in testing - and indeed, it isn't. Versions are
irrelevant to what I'm looking at, and looking for.

I was, and am, expecting that the package *variants* in backports (in
terms of architectures, debug symbols, signing, ...) will be the same as
the variants in testing, barring changes in packaging which would affect
which packages get generated, and barring differences in which
architectures are considered supported enough to get package builds -
and indeed, at a glance the set of variants in testing and the set of
variants in backports seem to match exactly.

And when I looked, neither of the variant sets in question seemed to
include the plain '-amd64' package name, although they did include the
'-amd64-unsigned' package name, and both variants of the package are
present in testing (for the kernel version which is in testing, which is
obviously distinct from the one which is in backports).

Let me try going over it again. Here's what my system sees as being
available in testing:

$ apt-cache policy linux-image-5.10.0-4-amd64{,-unsigned}
linux-image-5.10.0-4-amd64:
Installed: 5.10.19-1
Candidate: 5.10.19-1
Version table:
*** 5.10.19-1 900
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
linux-image-5.10.0-4-amd64-unsigned:
Installed: (none)
Candidate: 5.10.19-1
Version table:
5.10.19-1 900
900 http://ftp.us.debian.org/debian testing/main amd64 Packages

If I search https://packages.debian.org/source/testing/linux for those
package names, I find linux-image-5.10.0-4-amd64-unsigned, but I do not
find linux-image-5.10.0-4-amd64 itself - even though apt reports that it
is, in fact, present.

This mismatch between what packages are listed on that page and what
packages are actually in the repository is clearly a discrepancy, and is
the core of what I am focusing on in my comments here to date.

Because of the existence of that discrepancy, I am inferring that the
fact that we do not see linux-image-5.10.0-0.bpo.3-amd64 (or, for that
matter, linux-image-5.10.0-0.bpo.4-amd64) on
https://packages.debian.org/source/stable-backports/linux may only
reflect a similar discrepancy, and thus may not be enough to let us
conclude that that package is not available in that repository.

Does that explain what I'm getting at a little bit better?

At the same time, investigating to provide that second attempt at the
explanation may have led me to discover a possible angle to the original
question.

@OP: Is linux-image-5.10.0-0.bpo.4-amd64 available in your configured
repositories? If so, what versions is it available with?

It's possible that the 5.10.19-1~bpo10+1 version may be available only
under the updated .4 package name, not under the .3 package name you're
checking.

signature.asc

Andrei POPESCU

unread,

Mar 23, 2021, 4:40:04 AM3/23/21

to

On Lu, 22 mar 21, 18:53:54, The Wanderer wrote:
>
> If I search https://packages.debian.org/source/testing/linux for those
> package names, I find linux-image-5.10.0-4-amd64-unsigned, but I do not
> find linux-image-5.10.0-4-amd64 itself - even though apt reports that it
> is, in fact, present.
>
> This mismatch between what packages are listed on that page and what
> packages are actually in the repository is clearly a discrepancy, and is
> the core of what I am focusing on in my comments here to date.

See e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886792

It seems to me packages.debian.org is unmaintained, in particular its
search function has been unreliable to me and I've been using
'apt search', 'apt list' and 'rmadison' instead.

signature.asc

didier gaumet

unread,

Mar 23, 2021, 5:10:04 AM3/23/21

to

Hello

from what I understand:

- in Bullseye, as indicated in its webpage on the Debian packages
website, the linux-image-5.10.0-4-amd64 binary package is built from the
linux-signed-amd64 source package

- the purpose of Debian Backports is to provide to Stable users binary
packages of sources from Testing (or rarely, Unstable) that are rebuilt
against stable libraries. That a binary package is present in Testing
deos not implie it is (or has to be) present in Backports

- Binary packages do not have necessarily the same name as the source
they are built from

:-)

David Wright

unread,

Mar 23, 2021, 12:50:04 PM3/23/21

to

In buster-backports/main/binary-amd64/Packages.xz, I see six packages
built against 5.10.19-1~bpo10+1, viz

Package: linux-image-5.10.0-0.bpo.4-amd64-dbg
Source: linux
Version: 5.10.19-1~bpo10+1
Installed-Size: 6961276
--
Package: linux-image-5.10.0-0.bpo.4-amd64-unsigned
Source: linux
Version: 5.10.19-1~bpo10+1
Installed-Size: 288300
--
Package: linux-image-5.10.0-0.bpo.4-cloud-amd64-dbg
Source: linux
Version: 5.10.19-1~bpo10+1
Installed-Size: 2142744
--
Package: linux-image-5.10.0-0.bpo.4-cloud-amd64-unsigned
Source: linux
Version: 5.10.19-1~bpo10+1
Installed-Size: 76726
--
Package: linux-image-5.10.0-0.bpo.4-rt-amd64-dbg
Source: linux
Version: 5.10.19-1~bpo10+1
Installed-Size: 6968406
--
Package: linux-image-5.10.0-0.bpo.4-rt-amd64-unsigned
Source: linux
Version: 5.10.19-1~bpo10+1
Installed-Size: 291183

On https://packages.debian.org/buster-backports/kernel/, I see
three matches for linux-image-5.10.0-0.bpo.4…amd64, viz

linux-image-5.10.0-0.bpo.4-amd64-unsigned (5.10.19-1~bpo10+1)
linux-image-5.10.0-0.bpo.4-cloud-amd64-unsigned (5.10.19-1~bpo10+1)
linux-image-5.10.0-0.bpo.4-rt-amd64-unsigned (5.10.19-1~bpo10+1)

The other three are, of course, on the page
https://packages.debian.org/buster-backports/debug/

If I search on https://packages.debian.org/index for
linux-image-5.10.0-0.bpo. in buster-backports/any,
then I see the same six matches for
linux-image-5.10.0-0.bpo.4…amd64, where, as before,
"…" stands for cloud, rt, and nothing.

So I don't observe any discrepancy between the Packages file and
the packages.debian.org page or its search function.

But the OP is, perhaps, relying on the upgrade mechanism provided by
the linux-image-amd64 metapackage. However, that's supporting only
the signed versions, and buster-backports doesn't (yet) have any
5.10.19 signed versions:

$ xzgrep 'Source: linux-signed-amd64' /home/debian/buster/Packages-backports.xz | sort -u
Source: linux-signed-amd64 (5.10.13+1~bpo10+1)
Source: linux-signed-amd64 (5.9.15+1~bpo10+1)
$ ls -Glg /home/debian/buster/Packages-backports.xz
-rw-r----- 1 458020 Mar 17 15:01 /home/debian/buster/Packages-backports.xz
$

(I haven't delved into what the new versions support as I'm currently
on 4.19, but that might change soon as I have a newish HP laptop to
play with.)

Cheers,
David.

Andrei POPESCU

unread,

Mar 24, 2021, 5:00:04 AM3/24/21

to

On Ma, 23 mar 21, 11:45:05, David Wright wrote:
>
> If I search on https://packages.debian.org/index for
> linux-image-5.10.0-0.bpo. in buster-backports/any,
> then I see the same six matches for
> linux-image-5.10.0-0.bpo.4…amd64, where, as before,
> "…" stands for cloud, rt, and nothing.
>
> So I don't observe any discrepancy between the Packages file and
> the packages.debian.org page or its search function.

Either it was a temporary glitch or I just missed the "Your keyword was
too generic, [...] some results might have been suppressed." message
(more likely).

Sorry for the noise.

signature.asc

l0f...@tuta.io

unread,

Mar 28, 2021, 1:50:04 PM3/28/21

to

Hi,

Sorry for the late reply.

Thanks everyone for providing answers to me.

22 mars 2021, 04:00 de geoff...@gmail.com:

> You're probably missing the metapackage, linux-image-amd64.
>

You are right!

Now I've installed linux-image-amd64 but my system still doesn't notify me regarding any kernel updates...

22 mars 2021, 08:31 de didier...@gmail.com:

> There is a linux-image-5.10.0-0.bpo.3-amd64 package but linux-image-5.10.0-0.bpo.4-amd64 has yet to be uploaded (linux-image-5.10.0-0.bpo.4-amd64-unsigned is there already)
>

Still true today. Signature seems to take time...

22 mars 2021, 12:17 de andreim...@gmail.com:

> When Linux has significant updates the package name changes as well to
> signal that e.g. out-of-tree modules must be recompiled.
>
> Try this instead:
>
> apt list linux-image-5*
>

$ apt list linux-image-5*
Listing... Done
linux-image-5.10.0-0.bpo.3-686-dbg/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-686-pae-dbg/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-686-pae-unsigned/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-686-pae/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-686-unsigned/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-686/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-amd64-dbg/buster-backports 5.10.13-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.3-amd64-unsigned/buster-backports 5.10.13-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.3-amd64/buster-backports,now 5.10.13-1~bpo10+1 amd64 [installed]
linux-image-5.10.0-0.bpo.3-cloud-amd64-dbg/buster-backports 5.10.13-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.3-cloud-amd64-unsigned/buster-backports 5.10.13-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.3-cloud-amd64/buster-backports 5.10.13-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.3-rt-686-pae-dbg/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-rt-686-pae-unsigned/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-rt-686-pae/buster-backports 5.10.13-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.3-rt-amd64-dbg/buster-backports 5.10.13-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.3-rt-amd64-unsigned/buster-backports 5.10.13-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.3-rt-amd64/buster-backports 5.10.13-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.4-686-dbg/buster-backports 5.10.19-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.4-686-pae-dbg/buster-backports 5.10.19-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.4-686-pae-unsigned/buster-backports 5.10.19-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.4-686-unsigned/buster-backports 5.10.19-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.4-amd64-dbg/buster-backports 5.10.19-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.4-amd64-unsigned/buster-backports 5.10.19-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.4-cloud-amd64-dbg/buster-backports 5.10.19-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.4-cloud-amd64-unsigned/buster-backports 5.10.19-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.4-rt-686-pae-dbg/buster-backports 5.10.19-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.4-rt-686-pae-unsigned/buster-backports 5.10.19-1~bpo10+1 i386
linux-image-5.10.0-0.bpo.4-rt-amd64-dbg/buster-backports 5.10.19-1~bpo10+1 amd64
linux-image-5.10.0-0.bpo.4-rt-amd64-unsigned/buster-backports 5.10.19-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-686-dbg/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-686-pae-dbg/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-686-pae-unsigned/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-686-pae/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-686-unsigned/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-686/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-amd64-dbg/buster-backports 5.9.15-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-amd64-unsigned/buster-backports 5.9.15-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-amd64/buster-backports 5.9.15-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-cloud-amd64-dbg/buster-backports 5.9.15-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-cloud-amd64-unsigned/buster-backports 5.9.15-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-cloud-amd64/buster-backports 5.9.15-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-rt-686-pae-dbg/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-rt-686-pae-unsigned/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-rt-686-pae/buster-backports 5.9.15-1~bpo10+1 i386
linux-image-5.9.0-0.bpo.5-rt-amd64-dbg/buster-backports 5.9.15-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-rt-amd64-unsigned/buster-backports 5.9.15-1~bpo10+1 amd64
linux-image-5.9.0-0.bpo.5-rt-amd64/buster-backports 5.9.15-1~bpo10+1 amd64

We can see that there is nothing more recent than what I already have installed:
linux-image-5.10.0-0.bpo.3-amd64/buster-backports,now 5.10.13-1~bpo10+1 amd64 [installed]

> To have apt install the latest *signed* kernel from a given archive you
> should install the corresponding 'linux-image-amd64' package.
>

Done now (see my first comment above)

22 mars 2021, 23:53 de wand...@fastmail.fm:

> @OP: Is linux-image-5.10.0-0.bpo.4-amd64 available in your configured
> repositories? If so, what versions is it available with?
>
> It's possible that the 5.10.19-1~bpo10+1 version may be available only
> under the updated .4 package name, not under the .3 package name you're
> checking.
>

See above, linux-image-5.10.0-0.bpo.4-amd64 is not available for me, on the contrary, linux-image-5.10.0-0.bpo.4-amd64-unsigned is (but I'm not interested as I'm running Secure Boot and need the signed version)...

By the way, what is image-5.10.0-0.bpo.4* serie for?Is it only related to "Change ABI number to 0.bpo.4"? Do I need that?

23 mars 2021, 17:45 de deb...@lionunicorn.co.uk:

> But the OP is, perhaps, relying on the upgrade mechanism provided by
> the linux-image-amd64 metapackage. However, that's supporting only
> the signed versions, and buster-backports doesn't (yet) have any
> 5.10.19 signed versions:
>

So you think that's the correct answer (no update because the package is not ready yet)?

If so, I'll simply wait for it. I just wanted to make sure my conf is OK (and obviously it wasn't configured in such a way to get the latest kernel versions from backports)...

Thanks in advance.

Best regards,
l0f4r0

l0f...@tuta.io

unread,

Mar 28, 2021, 7:10:04 PM3/28/21

to

Hi Harry,

22 mars 2021, 01:12 de wea...@riseup.net:

> You may be looking at the unsigned version and may have to wait 24 hours
> for the signed one to come through the repositories, if that's what you
> are running.
>
Thanks for your message but 24 hours don't seem to be enough here...

Maybe there are some issues experienced by the maintainer?
Is there an easy way to see that?

With what everyone says so far, I have the feeling that 5.10.19-1~bpo10+1 is indicated as available via backports but not for every flavours. Everybody is not in the same boat ;)

I have no problem with that but maybe this subtlety could be stated more explicitely somewhere? Just a suggestion so one doesn't have to dig too much to understand that...

Best regards,
l0f4r0

Andrei POPESCU

unread,

Mar 29, 2021, 3:50:05 PM3/29/21

to

On Du, 28 mar 21, 19:46:07, l0f...@tuta.io wrote:
>
> 22 mars 2021, 12:17 de andreim...@gmail.com:
>
> > When Linux has significant updates the package name changes as well to
> > signal that e.g. out-of-tree modules must be recompiled.
> >
> > Try this instead:
> >
> > apt list linux-image-5*
> >
> $ apt list linux-image-5*
> Listing... Done

[...]

> linux-image-5.10.0-0.bpo.3-amd64/buster-backports,now 5.10.13-1~bpo10+1 amd64 [installed]

[...]

> linux-image-5.9.0-0.bpo.5-amd64/buster-backports 5.9.15-1~bpo10+1 amd64

[...]

> We can see that there is nothing more recent than what I already have installed:
> linux-image-5.10.0-0.bpo.3-amd64/buster-backports,now 5.10.13-1~bpo10+1 amd64 [installed]

Are you really sure about that? ;)

signature.asc

Andrei POPESCU

unread,

Mar 29, 2021, 4:10:05 PM3/29/21

to

Sorry, quoted wrong line, I meant this:

> linux-image-5.10.0-0.bpo.4-amd64-unsigned/buster-backports 5.10.19-1~bpo10+1 amd64

signature.asc

l0f...@tuta.io

unread,

Mar 29, 2021, 6:10:04 PM3/29/21

to

Hi Andrei,

29 mars 2021, 22:09 de andreim...@gmail.com:

> Sorry, quoted wrong line, I meant this:
>
>> linux-image-5.10.0-0.bpo.4-amd64-unsigned/buster-backports 5.10.19-1~bpo10+1 amd64
>>

Haha, I was wondering why you were comparing 5.10 with 5.9^^

Actually, I maintain my position. The package you are quoting (lastly) is maybe more recent but *unsigned*.
However, I need the signed one because I use Secure Boot... ;)

Best regards,
l0f4r0

Andrei POPESCU

unread,

Mar 30, 2021, 2:20:05 AM3/30/21

to

signature.asc

David Wright

unread,

Mar 30, 2021, 10:20:06 AM3/30/21

to

On Sun 28 Mar 2021 at 19:46:07 (+0200), l0f...@tuta.io wrote:
>
> By the way, what is image-5.10.0-0.bpo.4* serie for?Is it only related to "Change ABI number to 0.bpo.4"? Do I need that?

I guess you have to read the changes file to find that out.
https://lists.debian.org/debian-backports-changes/2021/03/msg00053.html
might be of use here.

> 23 mars 2021, 17:45 de deb...@lionunicorn.co.uk:
>
> > But the OP is, perhaps, relying on the upgrade mechanism provided by
> > the linux-image-amd64 metapackage. However, that's supporting only
> > the signed versions, and buster-backports doesn't (yet) have any
> > 5.10.19 signed versions:
> >
> So you think that's the correct answer (no update because the package is not ready yet)?
>
> If so, I'll simply wait for it. I just wanted to make sure my conf is OK (and obviously it wasn't configured in such a way to get the latest kernel versions from backports)...

That would depend on there being one.

Perhaps it's worth subscribing to debian-backports-changes and
debian-backports. You can post to the latter.

Cheers,
David.

l0f...@tuta.io

unread,

Mar 31, 2021, 5:00:04 PM3/31/21

to

Hi,

30 mars 2021, 08:16 de andreim...@gmail.com:

Is linux-signed-amd64 the source of linux-image-amd64? I suppose there are some constraints here but it would be (apparently) easier if the names were matching ^^

If I follow you, we have more information by inquiring about the source package than the binary one?

> The packages appears to be stuck in the backports-policy. If I recall
> correctly (see recent -backports archives) this is related to the
> freeze.
>

Very interesting. You have certainly something here...

But if true, why https://lists.debian.org/debian-backports-changes/2021/03/msg00053.html mentions "Accepted linux 5.10.19-1~bpo10+1 (source) into buster-backports->backports-policy, buster-backports" if it's just in backports-policy?

Indeed, as soon as I see "buster-backports" mentioned, I expect the package to be available through...(drum roll)... buster-backports.

30 mars 2021, 16:14 de deb...@lionunicorn.co.uk:

> On Sun 28 Mar 2021 at 19:46:07 (+0200), > l0f...@tuta.io> wrote:
>
>>

>> By the way, what is image-5.10.0-0.bpo.4* serie for?Is it only related to "Change ABI number to 0.bpo.4"? Do I need that?
>>

> I guess you have to read the changes file to find that out.
> https://lists.debian.org/debian-backports-changes/2021/03/msg00053.html
> might be of use here.
>

Actually, what I need is just linux-image-5.10.0-0.bpo.4-amd64 but it hasn't been made available yet. This one will be related to kernel 5.10.19-1~bpo10+1.

> Perhaps it's worth subscribing to debian-backports-changes and
> debian-backports. You can post to the latter.
>

That's a good suggestion, thanks :)

Best regards,
l0f4r0

Andrei POPESCU

unread,

Apr 1, 2021, 4:10:04 AM4/1/21

to

apt show linux-image-amd64

> I suppose there are some constraints here but it would be (apparently)
> easier if the names were matching ^^

Using different source packages very likely involves more work for the
maintainers, so it was probably necessary.

The process to create signed kernel images is "documented" somewhere
(possibly just mailing list post), so a web search should find it.

> If I follow you, we have more information by inquiring about the
> source package than the binary one?

It's easier to track source packages if the binary package name changes
often.

> > The packages appears to be stuck in the backports-policy. If I recall
> > correctly (see recent -backports archives) this is related to the
> > freeze.
> >
> Very interesting. You have certainly something here...
>
> But if true, why
> https://lists.debian.org/debian-backports-changes/2021/03/msg00053.html mentions
> "Accepted linux 5.10.19-1~bpo10+1 (source) into
> buster-backports->backports-policy, buster-backports" if it's just in
> backports-policy?

It says 'linux', which is the source package for the -unsigned images,
as discussed above.

signature.asc

didier gaumet

unread,

Apr 1, 2021, 4:50:05 AM4/1/21

to

Le 01/04/2021 à 10:02, Andrei POPESCU a écrit :
> On Mi, 31 mar 21, 22:54:59, l0f...@tuta.io wrote:

[...]

>> Is linux-signed-amd64 the source of linux-image-amd64?

[...]

>> I suppose there are some constraints here but it would be (apparently)
>> easier if the names were matching ^^
>
> Using different source packages very likely involves more work for the
> maintainers, so it was probably necessary.

I've counted 108 binary packages built from the one linux-signed-amd64
source package: why would one create 108 identical source packages with
different names when one is sufficient? ;-)

> The process to create signed kernel images is "documented" somewhere
> (possibly just mailing list post), so a web search should find it.

[...]

https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key

l0f...@tuta.io

unread,

Apr 4, 2021, 5:20:04 AM4/4/21

to

Hi Andrei, Didier,

Thanks for your new feedbacks.

As agreed, I posted to debian-backports [*] and, the following day, there was my package linux-image-5.10.0-0.bpo.4-amd64 available in my repository.
Maybe it's juste a coincidence or a swift reaction, cannot tell as I didn't receive an official response.
Everything is good now :)

1 avr. 2021, 10:02 de andreim...@gmail.com:

> It's easier to track source packages if the binary package name changes
> often.
>

Nice tip, thanks

1 avr. 2021, 10:41 de didier...@gmail.com:

> I've counted 108 binary packages built from the one linux-signed-amd64 source package:
>

Can you tell me please how one can know that?

> why would one create 108 identical source packages with different names when one is sufficient? ;-)
>

;)

[*] : https://lists.debian.org/debian-backports/2021/03/msg00013.html

Best regards,
l0f4r0