Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #90711 > unrolled thread

Bug#1124667: linux-image-6.18.3-1 only available as unsigned

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1124667: linux-image-6.18.3-1 only available as unsigned Pascal Hambourg <pascal@plouf.fr.eu.org> - 2026-01-06 16:50 +0100
    Bug#1124667: linux-image-6.18.3-1 only available as unsigned Salvatore Bonaccorso <carnil@debian.org> - 2026-01-06 20:50 +0100
      Processed: Re: Bug#1124667: linux-image-6.18.3-1 only available  as unsigned "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-01-06 20:50 +0100
      Bug#1124667: linux-image-6.18.3-1 only available as unsigned Pascal Hambourg <pascal@plouf.fr.eu.org> - 2026-01-07 19:20 +0100

#90711 — Bug#1124667: linux-image-6.18.3-1 only available as unsigned

On Mon, 5 Jan 2026 13:05:59 +0100 Salvatore Bonaccorso wrote:
> On Mon, Jan 05, 2026 at 11:10:22AM +0100, Roland Clobus wrote:
>> 
>> The package linux-image-amd64 for 6.18.3-1 depends only on the signed kernel
>> package [1]. At this moment the signed version is (not yet?) available, so
>> the installation will fail.
>> 
>> For sid, the source package appears to have been changed from
>> 'linux-signed-amd64' to 'linux'. Could that be causing this issue?

I guess so. What is the reason of this change ?

>> Would it be possible to change the dependency to:
>> linux-image-6.18.3+deb14-amd64 | linux-image-6.18.3+deb14-amd64-unsigned
>> instead?

Not sure it is a good idea. It could lead to the installation of an 
unsigned kernel while a signed kernel was expected. This would make the 
system unbootable with secure boot.

> This is normal for short while. FTP master will need to trigger the
> codesigning service, at which point then we will get the signed images
> as well.

Is it really normal to update the kernel meta-package before the signed 
kernel package the new version depends on is available ?

[toc] | [next] | [standalone]

#90715

Control: reopen -1

Hi Pascal,

On Tue, Jan 06, 2026 at 04:43:19PM +0100, Pascal Hambourg wrote:
> On Mon, 5 Jan 2026 13:05:59 +0100 Salvatore Bonaccorso wrote:
> > On Mon, Jan 05, 2026 at 11:10:22AM +0100, Roland Clobus wrote:
> > > 
> > > The package linux-image-amd64 for 6.18.3-1 depends only on the signed kernel
> > > package [1]. At this moment the signed version is (not yet?) available, so
> > > the installation will fail.
> > > 
> > > For sid, the source package appears to have been changed from
> > > 'linux-signed-amd64' to 'linux'. Could that be causing this issue?
> 
> I guess so. What is the reason of this change ?
> 
> > > Would it be possible to change the dependency to:
> > > linux-image-6.18.3+deb14-amd64 | linux-image-6.18.3+deb14-amd64-unsigned
> > > instead?
> 
> Not sure it is a good idea. It could lead to the installation of an unsigned
> kernel while a signed kernel was expected. This would make the system
> unbootable with secure boot.
> 
> > This is normal for short while. FTP master will need to trigger the
> > codesigning service, at which point then we will get the signed images
> > as well.
> 
> Is it really normal to update the kernel meta-package before the signed
> kernel package the new version depends on is available ?

I was I think bit prematurely to close the issue, because I think we
should explain from where the change come (and if we actually want to
cause this situation).

If I'm correct, with the change af3f11740ed9 ("Introduce a base
package for version sync") we now generate again the linux-image-*
packages from src:linux.

 [1] https://salsa.debian.org/kernel-team/linux/-/commit/af3f11740ed9525b0c035f941c86ddc5e10125bb

The downside of this change is exactly as you described, we do not
have anymore the linux-image-* package build only at the time when the
signed packages exists and will cause temporary situations as
described, so in theory reopen #941042.

Bastian, Ben, is this something we should rethink about?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#90716 — Processed: Re: Bug#1124667: linux-image-6.18.3-1 only available as unsigned

Processing control commands:

> reopen -1
Bug #1124667 {Done: Salvatore Bonaccorso <carnil@debian.org>} [src:linux] linux-image-6.18.3-1 only available as unsigned
Bug reopened
Ignoring request to alter fixed versions of bug #1124667 to the same values previously set

-- 
1124667: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124667
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#90738

On 06/01/2026 at 20:45, Salvatore Bonaccorso wrote:
>>
>> Is it really normal to update the kernel meta-package before the signed
>> kernel package the new version depends on is available ?
> 
> I was I think bit prematurely to close the issue, because I think we
> should explain from where the change come (and if we actually want to
> cause this situation).
> 
> If I'm correct, with the change af3f11740ed9 ("Introduce a base
> package for version sync") we now generate again the linux-image-*
> packages from src:linux.
> 
>   [1] https://salsa.debian.org/kernel-team/linux/-/commit/af3f11740ed9525b0c035f941c86ddc5e10125bb

Thank you for the explanation. I understand the goal (keep installed 
linux-image and linux-headers versions in sync)) and subscribe to it, 
but do linux-image-{amd64,arm64} meta-packages have to be built from 
src:linux instead of src:linux-signed-{amd64,arm64} for this ?

("It makes things simpler and sid should stand this kind of transient 
situation" is an acceptable answer)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web