Bug#1040901: Upcoming changes to Debian Linux kernel packages
OK,
it seems my original email got lost somewhere in tech hickups,
it's possible the kernel crashed before sending the email, AMD
just crashes once or twice a day.
So I'm writing this email a bit in a hurry, so it's not quite
as thought out as the last one weeks ago, but yesterday's email
was pretty concerning.
We should not rush this. we need to be realistic that this will
take a couple of months to sort out a new scheme, don't expect
this to be done before the end of the year, and that seems to
be very optimistic.
On Sat, Oct 07, 2023 at 04:53:33PM +0200, Bastian Blank wrote:
> 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.
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
- 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)
- 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.
It is fine to say "you must reboot", but it is not fine to just
break the running system until you do.
>
> 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.
Needless to say I do not believe that uname -s is necessarily a
single word.
> - 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(?).
I don't really care about the ordering, I want to order by package
version.
I need to identify:
* Which kernel image package is currently booted. Hence I need to
go from the uname -r to exactly one installed kernel image package
that acts as the key package to determine if a kernel version is
installed.
* What are other installed kernel image packages
* Given a uname / kernel image package, which other kernel packages
belong to it
This allows me to keep the currently installed kernels around.
The flip side of the coin is the code in APT that actually autoremoves
kernels: It needs to identify, given a list of kernel images to keep
which other kernel packages can be removed. Optimally it can still
remove headers for 6.6 if you don't even have 6.6 images installed
anymore and _somehow_ pulled them in.
Essentially I want to order kernel image packages by version,
and keep the currently booted and the latest one, and the 2nd
latest if currently booted == latest one, and then remove any
other versioned kernel package not related to them.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: