Kernel mismatch in daily d-i image

[Roland Clobus]

Hello debian-boot, Cyril,

It happened again: the kernel got updated and the daily d-i images
(being based on sid) result in a kernel mismatch.
https://tracker.debian.org/pkg/linux-signed-amd64

You can see the red bars in openQA:
https://openqa.debian.net/

In openQA the kernel mismatch is diagnosed rather quickly after a kernel
update.

* Do you want future mails of this type, or are you monitoring
openQA/something else yourselves?
* Would a setting like 'LINUX_KERNEL_ABI ?= auto' be welcomed as a
patch? With that value, the kernel will be automagically be matched to
the current kernel version, whereas it would still be possible to
specify 'LINUX_KERNEL_ABI ?= 6.12.8' for explicit kernel versions.

Live-build already has this automagic in place, which explains why the
daily sid-based images still have a working d-i installer.

With kind regards,
Roland Clobus

[Philip Hands]

Hi Roland,

Post by Roland Clobus
Hello debian-boot, Cyril,
It happened again: the kernel got updated and the daily d-i images
(being based on sid) result in a kernel mismatch.
https://tracker.debian.org/pkg/linux-signed-amd64
https://openqa.debian.net/
In openQA the kernel mismatch is diagnosed rather quickly after a kernel
update.
* Do you want future mails of this type, or are you monitoring
openQA/something else yourselves?
* Would a setting like 'LINUX_KERNEL_ABI ?= auto' be welcomed as a
patch? With that value, the kernel will be automagically be matched to
the current kernel version, whereas it would still be possible to
specify 'LINUX_KERNEL_ABI ?= 6.12.8' for explicit kernel versions.

I may be mistaken, but I think that the problem is due to debian-cd
(AFAIK) using the version of d-i that's in the archive to build the CDs,
rather than building a new d-i version on the fly.

This is different from what I do for the mini-ISOs that get built for
testing on salsa, and I guess it's different from what's occurring with
your Live builds.

That being the case, the thing in the archive is always going to lag a
bit, because one cannot build it until the signed kernel lands, and that
takes a time after the unsigned one is built.

I was looking at this (briefly) this morning to see how we might notice
that we're in this state during the debian-cd run, and abort, as that
would at least prevent people being offered the known-broken image to
test, although I guess there'd still be the chance of producing an image
that was OK when you started, but was broken by the time you'd finished,
if you get the timing perfectly wrong.

The thing I failed to work out this morning was how to discover the
version of the kernel that's in the version of d-i that debian-cd is
going to use. Given that it should be pretty trivial to check that the
needed kernel version is still available.

If anyone happens to know the answer to that, that would be helpful :-)

BTW There was a thread about this on debian-cd last month in which
Cyril's mail provides helpful pointers:

https://lists.debian.org/debian-cd/2024/12/msg00044.html

Cheers, Phil.

[Cyril Brulebois]

Post by Philip Hands
I was looking at this (briefly) this morning to see how we might notice
that we're in this state during the debian-cd run, and abort, as that
would at least prevent people being offered the known-broken image to
test, although I guess there'd still be the chance of producing an image
that was OK when you started, but was broken by the time you'd finished,
if you get the timing perfectly wrong.
The thing I failed to work out this morning was how to discover the
version of the kernel that's in the version of d-i that debian-cd is
going to use. Given that it should be pretty trivial to check that the
needed kernel version is still available.

I think I mentioned MANIFEST.udebs


Post by Philip Hands
If anyone happens to know the answer to that, that would be helpful :-)
BTW There was a thread about this on debian-cd last month in which
https://lists.debian.org/debian-cd/2024/12/msg00044.html


 but if I did, that wasn't in that specific mail. This file is found
at the top-level of the generated build artifacts, and mentions
kernel-image (beware of multiple flavors).


Cheers,

[Cyril Brulebois]

Hi,

Post by Roland Clobus
It happened again: the kernel got updated and the daily d-i images
(being based on sid) result in a kernel mismatch.
https://tracker.debian.org/pkg/linux-signed-amd64
https://openqa.debian.net/
In openQA the kernel mismatch is diagnosed rather quickly after a
kernel update.
* Do you want future mails of this type, or are you monitoring
openQA/something else yourselves?

No, thanks. That's monitored on my side, and I usually adjust as soon as
linux-image-* get out of NEW. I happen to have spent a few hours away
from my computer (crazy, I know).

Also, even without a matching commit, it's not been an issue during the
past few months because udebs were being kept in the archive. A huge
cleanup happened a few days ago, and possibly they're getting pruned
immediately (again) now.

I plan to ask the ftp team what happened there, and whether we could
keep at least the previous ABI around.

Post by Roland Clobus
* Would a setting like 'LINUX_KERNEL_ABI ?= auto' be welcomed as a patch?
With that value, the kernel will be automagically be matched to the current
kernel version, whereas it would still be possible to specify
'LINUX_KERNEL_ABI ?= 6.12.8' for explicit kernel versions.

No, thanks.


Cheers,