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

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

Bug#1040901: Upcoming changes to Debian Linux kernel packages

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#1040901: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-09-24 15:10 +0200
    Re: Upcoming changes to Debian Linux kernel packages Andreas Beckmann <anbe@debian.org> - 2023-09-24 23:20 +0200
      Re: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-09-25 01:10 +0200
        Re: Upcoming changes to Debian Linux kernel packages Andreas Beckmann <anbe@debian.org> - 2023-09-25 04:40 +0200
          Re: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-01 12:10 +0200
            Re: Upcoming changes to Debian Linux kernel packages Sam Hartman <hartmans@debian.org> - 2023-10-03 16:40 +0200
              Re: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-03 19:50 +0200
                Re: Upcoming changes to Debian Linux kernel packages Adrian Bunk <bunk@debian.org> - 2023-10-03 22:00 +0200
                  Re: Upcoming changes to Debian Linux kernel packages Robert Nelson <robertcnelson@gmail.com> - 2023-10-03 22:10 +0200
                    Re: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-05 08:30 +0200
                      Re: Upcoming changes to Debian Linux kernel packages Sam Hartman <hartmans@debian.org> - 2023-10-05 16:10 +0200
                        Re: Upcoming changes to Debian Linux kernel packages Russ Allbery <rra@debian.org> - 2023-10-05 17:30 +0200
                        Re: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-26 14:00 +0200
                Re: Upcoming changes to Debian Linux kernel packages Andreas Beckmann <anbe@debian.org> - 2023-10-04 00:00 +0200
                  Re: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-05 08:10 +0200
    Bug#1040901: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-05 21:30 +0200
    Bug#1040901: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-07 17:00 +0200
      Bug#1040901: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-26 13:40 +0200
        Bug#1040901: Upcoming changes to Debian Linux kernel packages Julian Andres Klode <jak@debian.org> - 2023-10-27 08:30 +0200
      Bug#1040901: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-27 11:00 +0200
        Bug#1040901: Upcoming changes to Debian Linux kernel packages Bastian Blank <waldi@debian.org> - 2023-10-27 20:20 +0200

Page 1 of 2  [1] 2  Next page →

#80505 — Bug#1040901: Upcoming changes to Debian Linux kernel packages

Hi folks

Debian currently does Secure Boot signing using a shim chained to the
Microsoft key.  This use requires that we follow certain rules.  And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore.  Some
information are in #1040901.

We could just do the minimal change, sign the modules a different way
and let users walk into authenticated failures and other scary error
messages.  Or we could change the existing ABI setting on every upload,
creating a new set of binary packages.

But maybe we can enhance the user experience a bit, by reducing the
chance of scarry errors, but with the chance of simple errors like "you
need to reboot".  So let's do some more changes and hopefully don't
break the user experience too much.  The planned changes are discussed
in more detail.

## Kernel modules will be signed with an ephemeral key

The modules will not longer be signed using the Secure Boot CA like the
EFI kernel image itself.  Instead a key will be created during the build
and thrown away after.

Yes, this will make the build unreproducible, but no better solution
currently exists.  There are some plans, but no-one is working on them.
If a suitable replacement shows up, we can always switch to that
solution.

## Kernel release value includes complete Debian version

The kernel release is what "uname -r" shows, and how modules are
organized in /lib/modules.  This value will include the complete version
of the binary package, so even binNMU will somehow work.  This will make
sure the value changes with every upload and modules will not be
compatible already from that check.

Example: 6.5.3-2+b2-cloud-arm64

## Image packages contains more version info

By renaming the kernel packages we try to make several kernels
installable at the same time.  In contrast to rpm, where you can have
the same package installed multiple times in different versions, dpkg
only supports a single one at the same time.  So the co-installable
versions needs to have different package names.

The packages will include the full upstream version.  There exists the
exception of devel builds and uploads to experimental, wich will contain
even less of the version, to avoid new names in that cases.

Example: linux-image-6.5.3-cloud-arm64

There are some drawbacks.

The same upstream version in testing and backports will have the same
package name.  Multiple uploads of the same upstream version will have
the same package name, but those rarely happens.  Those packages will
not be compatible and a reboot is necessary to be able to load modules
again.

It will not longer be possible to reliably derive the package name from
kernel release (see above), as both values are not really related
anymore.

## Header and tool packages will not longer contain version

The headers packages will not longer include the version.  It won't be
reliably possible to derive the package name anyway from the running
kernel.

This means that only headers of one single version can be available on
the system at one time.  This might be a bit inconvinient for dkms, as
it can't longer build modules for multiple versions.

But we too often have the problem that image and headers go out of sync
and then you can't find the correct ones anyway.

Example: linux-headers-cloud-arm64

## Installer packages will not longer contain too much version

The installer can only ever handle one version of kernel.  Also it got
an internal mechanism to detect which packages belong together
(the Kernel-Version control entry).  So we have no need to rename them
and force a matching change in d-i itself just because a new kernel
exists.  So it will not longer contain the full version in the package
names if not needed.

## Further work

The changes outlined here try to avoid changes to the initramfs
protocol, aka /etc/kernel/.  There are larger change is cooking somehow,
see
https://lists.debian.org/msgid-search/Y2GBkyERB10kYk25@shell.thinkmo.de

Regards,
Bastian

-- 
You!  What PLANET is this!
		-- McCoy, "The City on the Edge of Forever", stardate 3134.0

[toc] | [next] | [standalone]

#80510 — Re: Upcoming changes to Debian Linux kernel packages

On 24/09/2023 15.01, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key
> 
> The modules will not longer be signed using the Secure Boot CA like the
> EFI kernel image itself.  Instead a key will be created during the build
> and thrown away after.

Do I correctly assume that change only affects the modules shipped by 
the linux-image packages and not third-party modules built with dkms?

> ## Header and tool packages will not longer contain version

> This means that only headers of one single version can be available on
> the system at one time.  This might be a bit inconvinient for dkms, as
> it can't longer build modules for multiple versions.

That sounds problematic in case of third party modules. If it is 
possible to have multiple linux-image-* packages installed, but only 
headers for one of them, the third-party modules will only be available 
for one of the kernel versions for sure (maybe there are still old 
module builds available, but no guarantee especially after the 
third-party module got updated). This will make switching between 
different kernel versions difficult to impossible, e.g. it may be hard 
to go back to a working older kernel version in case the new one does 
not work properly (or the third-party module cannot be built or does not 
work for the new version).


Regarding getting the correct linux-header-* packages installed for the 
installed linux-image-* packages:
Maybe linux-image-* could have
   Recommends: linux-headers-* | no-linux-headers
s.t. the correct linux-headers-* are installed by default (installation 
of recommends is enabled by default) for all installed linux-image-* 
packages. no-linux-headers would be an opt-out package that can be 
installed manually if someone does not want to get linux-headers-* 
installed at all. It should never be installed automatically.

For dkms it is hard recommend the correct linux-header-* package, right 
now we have
   Recommends: linux-headers-generic | linux-headers-686-pae | 
linux-headers-amd64 | linux-headers
which does not really work for the non-default kernel flavor, e.g. the 
-cloud or -i386 kernel. So some improvement on the kernel side would be 
nice here.


Andreas

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

#80511 — Re: Upcoming changes to Debian Linux kernel packages

Hi Andreas

On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> > 
> > The modules will not longer be signed using the Secure Boot CA like the
> > EFI kernel image itself.  Instead a key will be created during the build
> > and thrown away after.
> 
> Do I correctly assume that change only affects the modules shipped by the
> linux-image packages and not third-party modules built with dkms?

Yes.  Nothing calls for changes to MOK keys, which are used by dkms.

> > ## Header and tool packages will not longer contain version
> 
> > This means that only headers of one single version can be available on
> > the system at one time.  This might be a bit inconvinient for dkms, as
> > it can't longer build modules for multiple versions.
> 
> That sounds problematic in case of third party modules. If it is possible to
> have multiple linux-image-* packages installed, but only headers for one of
> them, the third-party modules will only be available for one of the kernel
> versions for sure (maybe there are still old module builds available, but no
> guarantee especially after the third-party module got updated). This will
> make switching between different kernel versions difficult to impossible,
> e.g. it may be hard to go back to a working older kernel version in case the
> new one does not work properly (or the third-party module cannot be built or
> does not work for the new version).

Already built modules remain until someone deletes it.  So you can also
switch back to the still installed older kernel version and it will have
the still working module available.

Yes, you would not be able to build new modules for the older kernel
until you also install the matching headers.

> Regarding getting the correct linux-header-* packages installed for the
> installed linux-image-* packages:
> Maybe linux-image-* could have
>   Recommends: linux-headers-* | no-linux-headers
> s.t. the correct linux-headers-* are installed by default (installation of
> recommends is enabled by default) for all installed linux-image-* packages.
> no-linux-headers would be an opt-out package that can be installed manually
> if someone does not want to get linux-headers-* installed at all. It should
> never be installed automatically.

Nack.  I actually thought about that.  But third-party modules are too
much a special configuration to do that and pay the 50MiB or so penalty
for each system.  Also this still have the version skew problem between
linux and linux-signed-*, so will be unreliable.

> For dkms it is hard recommend the correct linux-header-* package, right now
> we have
>   Recommends: linux-headers-generic | linux-headers-686-pae |
> linux-headers-amd64 | linux-headers
> which does not really work for the non-default kernel flavor, e.g. the
> -cloud or -i386 kernel. So some improvement on the kernel side would be nice
> here.

I thought about adding a versioned provides with the complete kernel
release string as version, so something like
| Provides: linux-headers (= $(uname -r))

This can then be installed via apt-get and the correct version as long
as the package is available.  This however can't be done via
dependencies, because it is dynamic.  So dkms would need to actively
make sure it got the correct package, if they are still reachable at
all.

Bastian

-- 
We have found all life forms in the galaxy are capable of superior
development.
		-- Kirk, "The Gamesters of Triskelion", stardate 3211.7

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

#80512 — Re: Upcoming changes to Debian Linux kernel packages

On 25/09/2023 00.50, Bastian Blank wrote:
> Already built modules remain until someone deletes it.  So you can also
> switch back to the still installed older kernel version and it will have
> the still working module available.

This is what I expect not to work.

Assume I have Linux 6.6 and a third-party gpu driver module installed 
(so there are dkms and the Linux 6.6 headers as well) and everything is 
working fine.
Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6 
which is kept installed) and a new version of the gpu driver (which adds 
support for 6.7). So the old gpu module for 6.6 gets removed and a new 
one is built for 6.7 only (since there are only 6.7 headers now).
Unfortunately 6.7 breaks some exotic in-tree driver (which I desperately 
need), so I need to go back to 6.6. Oops, there is no gpu driver module 
any more. Recovery now needs manual intervention.

I'm not sure which class of bugs you are trying to solve with this 
proposed unversioned linux-headers change. IMO the current scheme of 
linux-headers-$version-$abi-$flavor matching 
linux-image-$version-$abi-$flavor works well. But perhaps something 
could be improved on the metapackage side. Ideally a user should install 
either meta-linux-image-without-headers-$flavor OR 
meta-linux-image-with-headers-$flavor (and ideally installing dkms 
should "automatically switch" to the with-headers variant, not sure how 
this could be done). The current scheme of having to install 
linux-image-$flavor AND linux-headers-$flavor is a bit tricky.
I'm open to implement improvements on the dkms side.

Andreas

PS: the proposed "more versioning in the linux-image packages" will 
solve some rare dkms issues where modules didn't get rebuilt after 
linux-headers-* was upgraded but $(uname -r) didn't change

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

#80572 — Re: Upcoming changes to Debian Linux kernel packages

On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it.  So you can also
> > switch back to the still installed older kernel version and it will have
> > the still working module available.
> Assume I have Linux 6.6 and a third-party gpu driver module installed (so
> there are dkms and the Linux 6.6 headers as well) and everything is working
> fine.
> Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
> which is kept installed) and a new version of the gpu driver (which adds
> support for 6.7). So the old gpu module for 6.6 gets removed and a new one
> is built for 6.7 only (since there are only 6.7 headers now).

Ah, here lays the missconception.  No, the 6.6 ones are not removed.  Why
should they be?  The system knows it can't rebuild them.

If the current implementation would remove them, it is a problem there,
not in the concept.

Bastian

-- 
Superior ability breeds superior ambition.
		-- Spock, "Space Seed", stardate 3141.9

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

#80591 — Re: Upcoming changes to Debian Linux kernel packages

>>>>> "Bastian" == Bastian Blank <waldi@debian.org> writes:

    Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
    >> On 25/09/2023 00.50, Bastian Blank wrote:
    >> > Already built modules remain until someone deletes it.  So you
    >> can also > switch back to the still installed older kernel
    >> version and it will have > the still working module available.
    >> Assume I have Linux 6.6 and a third-party gpu driver module
    >> installed (so there are dkms and the Linux 6.6 headers as well)
    >> and everything is working fine.  Then I upgrade the system, which
    >> brings Linux 6.7 (along linux-image-6.6 which is kept installed)
    >> and a new version of the gpu driver (which adds support for
    >> 6.7). So the old gpu module for 6.6 gets removed and a new one is
    >> built for 6.7 only (since there are only 6.7 headers now).

    Bastian> Ah, here lays the missconception.  No, the 6.6 ones are not
    Bastian> removed.  Why should they be?  The system knows it can't
    Bastian> rebuild them.

    Bastian> If the current implementation would remove them, it is a
    Bastian> problem there, not in the concept.

I still think it would help if you would work more on articulating what
problem you are trying to solve with the linux-headers versioning
change.  I have read multiple versions of this proposal, and your
follow-ups, and I still do not understand what is prompting the
linux-headers change.

My intuition mirrors others in the conversation that it is problematic
to support multiple kernel versions without also supporting multiple
header versions.

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

#80592 — Re: Upcoming changes to Debian Linux kernel packages

Hi Sam

On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change.  I have read multiple versions of this proposal, and your
> follow-ups, and I still do not understand what is prompting the
> linux-headers change.

The core problem is that people assume they can get headers matching the
currently running kernel, without upgrading first, see also the parallel
thread.  Or freak out because meta packages remain uninstallable in
backports for days.

With this plan you can only get the correct ones by using something
I think like:

| apt satisfy 'linux-headers (= $(uname -r))'

There is somewhere again a maybe possible plan to get meta packages in
place that actually support the case of always providing the headers to
the installed (not running!) kernel.

Then we need to use the same versioning anyway again.  In the end I
don't really care, but we need then a way to fix the version skew
between the different source package for the kernel.  Aka either redo
larger parts of the linux package (which can never fix it completely),
plus gcc or we change how backports works.

> My intuition mirrors others in the conversation that it is problematic
> to support multiple kernel versions without also supporting multiple
> header versions.

Usually you try to guard against one error.  Noone claimed that we can't
work with one error.  All the other conversations already have to argue
with two errors at the same time.  When should we stop then?

Regards,
Bastian

-- 
Deflector shields just came on, Captain.

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

#80593 — Re: Upcoming changes to Debian Linux kernel packages

On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
>...
> The core problem is that people assume they can get headers matching the
> currently running kernel, without upgrading first, see also the parallel
> thread.
>...

If the new kernel has a regression that affects the user, the user 
usually has no good choice other than downgrading to the previously-used 
kernel and continue using it until a fixed kernel is available.

How will the user get the headers matching this previously-used kernel
that are required until we provide a kernel with the regression fixed?

> Regards,
> Bastian

cu
Adrian

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

#80594 — Re: Upcoming changes to Debian Linux kernel packages

On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk <bunk@debian.org> wrote:
>
> On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
> >...
> > The core problem is that people assume they can get headers matching the
> > currently running kernel, without upgrading first, see also the parallel
> > thread.
> >...
>
> If the new kernel has a regression that affects the user, the user
> usually has no good choice other than downgrading to the previously-used
> kernel and continue using it until a fixed kernel is available.
>
> How will the user get the headers matching this previously-used kernel
> that are required until we provide a kernel with the regression fixed?
>

I know there is a lot of history behind the linux-headers package in
debian.  However since 5.2 there is a kernel config option, which
allows you to build the kernel headers as a module (built-in or
external)..

https://cateee.net/lkddb/web-lkddb/IKHEADERS.html

As long as this was enabled (ignore bugs/regressions), users can go
back and forth on kernel versions as they wish.

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

#80602 — Re: Upcoming changes to Debian Linux kernel packages

On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk <bunk@debian.org> wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?

The same as now: nowhere, because those packages have been removed from
the archive already.

And sadly you did not answer the question why a second degree error must
not be worse then a worked around first degree error?

> I know there is a lot of history behind the linux-headers package in
> debian.  However since 5.2 there is a kernel config option, which
> allows you to build the kernel headers as a module (built-in or
> external)..
> https://cateee.net/lkddb/web-lkddb/IKHEADERS.html
> As long as this was enabled (ignore bugs/regressions), users can go
> back and forth on kernel versions as they wish.

If it would be so easy.  This would include all the generated things of
the build.  But it still needs all the static headers, all the support
binaries and scripts (shipped as linux-kbuild-*), which also change with
every version.

Regards,
Bastian

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6

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

#80603 — Re: Upcoming changes to Debian Linux kernel packages

>>>>> "Bastian" == Bastian Blank <waldi@debian.org> writes:

    Bastian> The same as now: nowhere, because those packages have been
    Bastian> removed from the archive already.

    Bastian> And sadly you did not answer the question why a second
    Bastian> degree error must not be worse then a worked around first
    Bastian> degree error?

I'll admit that I find that phrasing difficult enough that I had to read
it a couple of times and I'm still not sure I've got it.

Let me see if I understand what you are saying.

1)  kernel headers will be removed from the archive.  So people complain
if they have an old kernel and wish to get kernel headers for it, but
those headers have been removed.

2) If the kernel header version changes but the kernel header package
name does not change  (version changed but not uname -r in the new
scheme?), you can have what you think is the right kernel headers but
they do not work with the binaries you have installed.

3) you can run into trouble between testing and backports.

I think that's what you mean by the first-level error.
If not, I'm still confused.

In the second level error case you are talking about is:

1) there is a regression in the kernel

2) someone needs kernel headers for an old kernel they want to downgrade
to.

I don't actually see how this is a second level error.
It appears to be a different first-level error (a regression), and  the
downgrade appears to follow naturally from that.

You point out that someone may not be able to get kernel headers for the
downgraded kernel.

a) They might.  In the window between a new kernel being introduced into
unstable and the same kernel being introduced into testing  there is an
old kernel available with kernel headers.
Similarly if someone needs to downgrade as far as stable, there is a
kernel with headers available in stable.

B) They might already have headers installed.  Imagine someone who
installs headers at the same time they install the kernel.
Unless they managed to upgrade the same version of their kernel without
also upgrading their headers, they will still have headers.
They can still build modules against that kernel, either because they
installed a new dkms package, or because one of their dkms packages
upgraded.

I think what you are saying is that

1) the current system is fragile: sometimes you want a kernel headers
that is not available and sometimes you have version skew between the
kernel headers and kernel even though you have both installed.

2) In your system, fewer things are possible, but the combination that
is possible is more likely to work.

And I think people's response is that
they care enough about some of the things you are breaking that they are
willing to accept the fragility.


    Bastian> -- Each kiss is as the first.  -- Miramanee, Kirk's wife,
    Bastian> "The Paradise Syndrome", stardate 4842.6

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

#80604 — Re: Upcoming changes to Debian Linux kernel packages

Sam Hartman <hartmans@debian.org> writes:

> B) They might already have headers installed.  Imagine someone who
> installs headers at the same time they install the kernel.  Unless they
> managed to upgrade the same version of their kernel without also
> upgrading their headers, they will still have headers.  They can still
> build modules against that kernel, either because they installed a new
> dkms package, or because one of their dkms packages upgraded.

I am also really confused by this discussion and don't entirely understand
the motivation for the proposed change to kernel headers, but isn't the
situation Sam describes above the normal way Linux kernel headers work and
have worked for years?  Kernels come with headers matching the same
version, if you want headers for external modules you install both
packages at the same time via one mechanism or another, and you only
remove the kernel and headers when you're pretty sure you will never use
that kernel again.

When I was using external modules heavily, I routinely kept three or four
old kernels and their corresponding headers installed at the same time so
that I could easily downgrade if I ran into regressions without having to
track down old packages that may have been removed from the archive.  This
feels like a normal and somewhat obvious Debian systems administration
thing to do to me.

I realize in the new signing regime every new kernel would have a separate
headers package (as opposed to today where the kernel and headers are
updated in place with the same package name if there is no ABI change),
but to me this doesn't feel like a significant difference for users.  I
haven't been paying close attention, so maybe I'm wrong, but I feel like
most kernel package updates have been ABI updates anyway, particularly in
stable.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

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

#80744 — Re: Upcoming changes to Debian Linux kernel packages

On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:

No, the first level is always: but the new kernel does not work.
The second is: I need to upgrade external modules.

> I think what you are saying is that
> 
> 1) the current system is fragile: sometimes you want a kernel headers
> that is not available and sometimes you have version skew between the
> kernel headers and kernel even though you have both installed.
> 
> 2) In your system, fewer things are possible, but the combination that
> is possible is more likely to work.

Yes.

> And I think people's response is that
> they care enough about some of the things you are breaking that they are
> willing to accept the fragility.

For now it looks like a better solution is to just create more meta
packages and accept that they become uninstallable from time to time.

In the future we might want to split off the modules into it's own
package anyway.  That will then allow
- a different image package containing prebuilt UKI,
- a different modules package to replace the special cloud flavours.

Regards,
Bastian

-- 
Without facts, the decision cannot be made logically.  You must rely on
your human intuition.
		-- Spock, "Assignment: Earth", stardate unknown

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

#80595 — Re: Upcoming changes to Debian Linux kernel packages

On 03/10/2023 19.30, Bastian Blank wrote:
> thread.  Or freak out because meta packages remain uninstallable in
> backports for days.
...
> plus gcc or we change how backports works.

If uninstallable packages in backports are a problem, perhaps backports 
needs something like britney to migrate packages from an uploading area 
to the publishing area (once a package set is installable, no need for 
delays). That should solve the problem where several source packages 
need to be updated together. (It would also solve problems with 
unsatisfiable dependencies where the backporter-uploaded binaries were 
built by accident in sid instead of stable, requiring a binNMU before 
migration.)

(but this should be discussed elsewhere)


Andreas

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

#80601 — Re: Upcoming changes to Debian Linux kernel packages

Hi Andreas

On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote:
> That should solve the problem where several source packages need to be
> updated together.

The problem does not come from multiple source packages that need to be
updated together.  Instead it comes from the way Debian does signing of
secure boot components.  After the linux packages got built and accepted,
an automatic process takes the output and produces a new source package
that is uploaded, built and accepted.  So the signed stuff will always
come later (between hours or days in normal cases, but esp for backports
even more then a week later).

Regards,
Bastian

-- 
Insults are effective only where emotion is present.
		-- Spock, "Who Mourns for Adonais?"  stardate 3468.1

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

#80613

Hi

On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.

We could encode that in the upstream version.  Aka to have
co-installable packages for security updates we do:

- 6.6.1-1
- 6.6.1+1-1
- 6.6.1+2-1

This allows for easy semantic, aka we only care for package names about
the upstream part of the version, which then needs to follow a certain
syntax.

Regards,
Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
		-- Kirk, "The Menagerie", stardate 3012.4

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

#80621

Moin

On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key

This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.

> ## Image packages contains more version info
> 
> Example: linux-image-6.5.3-cloud-arm64

> It will not longer be possible to reliably derive the package name from
> kernel release (see above), as both values are not really related
> anymore.

I missed that apt does something similar (maintainers cced).  It wants
to see if a particular package matches the current kernel to make the
autoremove prevention work.  That lookup is quite a hard problem.

What should work:  We define a new control field.  It contains both the
kernel name and a version prefix. 

Example:
- Linux 6.6 (would match 6.6-1, 6.6.1-1)
- Linux 6.6.3 (would match 6.6.3-1, but not 6.6.3+2-1)
- Linux 6.6.3+2

The algorithm would be something like this:
- Check $(uname -s) against the first word.  Otherwise completely
  ignore.
- Check if $(uname -r) matches the version prefix in this field.  Mark
  as keep if it matches.
- Aggregate packages by version prefix.
- Sort as version, keep newest two(?).

This means:
- Images and headers are always kept with the same versions.
- Different images (-arm64, -rt-arm64) are always kept together.

Counter proposal: Use see the kernel release as debian version and match
on the upstream version.  But then we need to re-define what we put into
the kernel release field.  In 6.6.1-1-cloud-arm64, the upstream version
is 6.6.1-1-cloud, not 6.6.1 as we would need.  We could of course change
that to: 6.6.1-1~cloud+arm64.  That should always sort correctly in
regard of the package version.

> ## Header and tool packages will not longer contain version

This is obsolete with the counter proposal of a meta package that always
pulls in image and headers of the same version.

Regards,
Bastian

-- 
Without followers, evil cannot spread.
		-- Spock, "And The Children Shall Lead", stardate 5029.5

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

#80743

On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> Or would it be easier to re-use normal dependency resolving, like:
> Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> This would allow full flexibility and re-uses existing code to check
> such definitions.

Okay, noone complained, so it looks like this should work.

Regards,
Bastian

-- 
Too much of anything, even love, isn't necessarily a good thing.
		-- Kirk, "The Trouble with Tribbles", stardate 4525.6

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

#80745

On Thu, Oct 26, 2023 at 01:36:50PM +0200, Bastian Blank wrote:
> On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> > Or would it be easier to re-use normal dependency resolving, like:
> > Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> > This would allow full flexibility and re-uses existing code to check
> > such definitions.
> 
> Okay, noone complained, so it looks like this should work.
> 

No no it doesn't. Did nobody read my email? Did I even send my
email? I don't know what the hell is going on here, but I spend
an hour writing an email discussing the options outlined before
this ridiculousness and the requirements, but I can't find it
in my notmuch.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

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

#80746

On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > ## Image packages contains more version info
> > > 
> > > Example: linux-image-6.5.3-cloud-arm64
> > 
> > > It will not longer be possible to reliably derive the package name from
> > > kernel release (see above), as both values are not really related
> > > anymore.
> 
> This package name seems to be missing the Debian release, which is
> mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in
> parallel, which again is mandatory. That's not something we can
> compromise on; it's absolutely vital that

Sadly in Debian there is no way to make that happen.  Think for example
about bin-nmu.

In the end we can approximate it in testing (usually not multiple
releases are migrated, but bin-nmu might show up), stable (where usualy
new upstream releases go in) and security (by uploading as 6.6.1,
6.6.1+1, 6.6.1+2, yes this is a hack, but it reduces the complexity of
the whole system).

Right now I simply don't see a way to not have multiple releases within
the same package, which override each other.

> - you can revert to the kernel you last booted succesfully, i.e. 6.5.3-1
>   if 6.5.3-2 is broken (think toolchain broke or something on buildds)

You can revert to 6.5.2, which is a separate package.  Or 6.4.

> - the currently booted kernel is not impacted. This means it must be
>   able to load additional modules. Some platforms even require
>   additional modules to be loaded to reboot, I've seen this on
>   laptops.

Could you provide an example?

Then we have to find another way to make sure modules survive unrelated
to what dpkg does.  Even right now there is no guarante you can load
modules from a different version at all.

> Needless to say I do not believe that uname -s is necessarily a
> single word.

Please provide an example.

[ Snipped the rest for now, will come back later ]

Bastian

-- 
Where there's no emotion, there's no motive for violence.
		-- Spock, "Dagger of the Mind", stardate 2715.1

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web