Trixie

[Hans Eisenrieder]

Dear team,

The firmware:
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
repeatedly asks whether the operating system should be installed without a
kernel.

With kind regards
Hans Eisenrieder
--
Im Auge des Betrachters
www.foto-in.de / Bisherigen Ausstellungen
<http://meisenrieder.myqnapcloud.com/foto-in/sonstiges_sonstiges_sonstiges/VsXx_Ausstellungen/VsXx_xxxx_Ausstellungen.html>
/ In Vorbereitung
<http://meisenrieder.myqnapcloud.com/foto-in/sonstiges_sonstiges_sonstiges/VsXx_Ausstellungen/VsXx_xxxx_Ausstellungen_Aktuelles.html>
Meine neue aufgesetzte Homepage im Aufbau
Was jemand als Kunst ansieht,
muss der naechste dies nicht als solche sehen.

Ergo: Kunst ist fast etwas Abstraktes.

[Philip Hands]

Post by Hans Eisenrieder
Dear team,
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
repeatedly asks whether the operating system should be installed without a
kernel.

Are you talking about this screen?

https://openqa.debian.net/tests/337708#step/kernel_mismatch/2

If so, you are seeing something that has become a traditional aspect of
the test images when there is a kernel upgrade.

If you download a new version, it should work again (at least until the
version of the kernel that's in the archive gets updated, at which point
that image will have the same problem -- the kernel version in the image
needs to match the kernel version, and hence the modules, in the archive).

Cheers, Phil.

P.S. BTW I'm curious. Is there a reason we do things this way?

(If I ever knew the reason, I'm afraid I've since forgotten it).

I know that it is possible to detect that we have kernel version skew at
image build time, because I have code in branch2repo that detects this
and then proceeds to build a working mini-ISO image regardless.

Could we not do something like that for the dailies too? (I'm happy to
insert the code I've got if it'll do the job, or come up with something
similar).

If not, could we not at least desist from publishing known-broken images?

It seems to me that the goodwill of people like Hans, who are willing to
test things for us and are well enough motivated to report problems, is
a scarce resource which we squander at our peril.

[Philip Hands]

Post by Philip Hands
I know that it is possible to detect that we have kernel version skew at
image build time, because I have code in branch2repo that detects this
and then proceeds to build a working mini-ISO image regardless.

I actually got the details wrong there.

It is correct that the detection happens in pipelines launched by repos
that make use of branch2repo, but the bit that does the work is actually
in debian-installer's debian/salsa-ci.yml:

https://salsa.debian.org/installer-team/debian-installer/-/blob/master/debian/salsa-ci.yml?ref_type=heads#L61

We could just make a similar check in debian-cd, and bail-out when the
configured ABI does not match the available one. That would at least
reduce the chances that people get to download images that are bound to
fail.

The code refered to above does better than that, by fixing the problem
for the build so that people still get to test the mini-ISO that's being
built for them by the pipeline.

I beleive Roland has something that similarly works around the problem
in his live-image building setup.

If we wanted to keep building working images during periods of
kernel-skew, I'd imagine that one of these approaches might well provide
inspiration.

Cheers, Phil.

[Cyril Brulebois]

Post by Philip Hands
We could just make a similar check in debian-cd, and bail-out when the
configured ABI does not match the available one.
That would at least reduce the chances that people get to download
images that are bound to fail.

I mentioned having a check on this earlier this month when proposing a
solution to a different problem (udebs for various kernel ABIs being all
shipped):

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

That would make sense to me.

Post by Philip Hands
If we wanted to keep building working images during periods of
kernel-skew, I'd imagine that one of these approaches might well
provide inspiration.

The branch2repo thing solves the following problem: something referenced
in the source code went away, and it replaces it with something else.

Building d-i from scratch is what is done on the live side (see the
discussion earlier this week). On the single arch it supports (at the
moment).

The problem on the debian-cd side is different. It uses a d-i daily
build that it has no control over, which might need matching udebs that
bad luck went away between the d-i build and the debian-cd one. You
can't get those back (unless you consider leveraging snapshot.d.o), and
I'm pretty sure you don't want debian-cd@ to try and rebuild d-i.

Finally, d-i builds with an unsigned kernel doesn't make sense to me in
this day and age. Netinst builds even less so.


Cheers,

[Cyril Brulebois]

Post by Cyril Brulebois
The problem on the debian-cd side is different. It uses a d-i daily
build that it has no control over, which might need matching udebs
that bad luck went away between the d-i build and the debian-cd one.

Seeing how (at least these past few days, weeks, months, or so) udebs
have piled up in the archive, it's probably more a matter of making sure
to include the right set of udebs onto the image, instead of picking
whatever is the latest.

From a cursory look at the context of the recent bugfix (which is
deeff0673833ae6ae97e3f7f96419254763f1d0f in debian-cd), debian-cd picks
whatever is the highest version, regardless of what's actually used by
d-i. In other words that traded a constant problem (not having enough
space to include linux-image debs) with a transient one (the wrong set
of udebs might get picked).

Provided there's no immediate decruft in the archive (the current number
of udebs for past kernels suggests that's not happening), it should just
be a matter of:
1. picking the right set (beware of archs with several flavours) based
on info collected from the d-i build;
2. bailing out if that version can't be found.

(1) would fix the issue, and only fail to work if and when the decruft
becomes super aggressive; (2) would avoid building an image that cannot
work if and when that happens.


Cheers,

[Philip Hands]

Post by Cyril Brulebois

Post by Cyril Brulebois
The problem on the debian-cd side is different. It uses a d-i daily
build that it has no control over, which might need matching udebs
that bad luck went away between the d-i build and the debian-cd one.

Seeing how (at least these past few days, weeks, months, or so) udebs
have piled up in the archive, it's probably more a matter of making sure
to include the right set of udebs onto the image, instead of picking
whatever is the latest.
From a cursory look at the context of the recent bugfix (which is
deeff0673833ae6ae97e3f7f96419254763f1d0f in debian-cd), debian-cd picks
whatever is the highest version, regardless of what's actually used by
d-i. In other words that traded a constant problem (not having enough
space to include linux-image debs) with a transient one (the wrong set
of udebs might get picked).
Provided there's no immediate decruft in the archive (the current number
of udebs for past kernels suggests that's not happening), it should just
1. picking the right set (beware of archs with several flavours) based
on info collected from the d-i build;
2. bailing out if that version can't be found.
(1) would fix the issue, and only fail to work if and when the decruft
becomes super aggressive; (2) would avoid building an image that cannot
work if and when that happens.

Oh, that seems like a good route forward. I'll try to fit some
experimentation with that in-between family/holiday commitments.

Thanks for the ideas :-)

Cheers, Phil.

[Cyril Brulebois]

Post by Cyril Brulebois
Seeing how (at least these past few days, weeks, months, or so) udebs
have piled up in the archive, it's probably more a matter of making sure
to include the right set of udebs onto the image, instead of picking
whatever is the latest.
From a cursory look at the context of the recent bugfix (which is
deeff0673833ae6ae97e3f7f96419254763f1d0f in debian-cd), debian-cd picks
whatever is the highest version, regardless of what's actually used by
d-i. In other words that traded a constant problem (not having enough
space to include linux-image debs) with a transient one (the wrong set
of udebs might get picked).
Provided there's no immediate decruft in the archive (the current number
of udebs for past kernels suggests that's not happening), it should just
1. picking the right set (beware of archs with several flavours) based
on info collected from the d-i build;
2. bailing out if that version can't be found.
(1) would fix the issue, and only fail to work if and when the decruft
becomes super aggressive; (2) would avoid building an image that cannot
work if and when that happens.

Some heavy decrufting happened earlier, see [1] for the full list.
That's why the dose report for i386[2] got much worse all of a sudden
(it was surprisingly good, similar to say amd64 until today).

=========================================================================
[Date: Sat, 28 Dec 2024 13:10:09 -0000] [ftpmaster: Ansgar]
Removed the following packages from unstable:
[
]
------------------- Reason -------------------
[auto-cruft] NBS (no longer built by linux)
----------------------------------------------
=========================================================================

1. https://ftp-master.debian.org/removals.txt
2. Loading Image...

I'm not sure whether that was a one-off clean-up or whether some cruft
detection got changed to make those show up (which in turn would
probably determine whether udebs for older kernels are going to stick
around for a while in the future, or just go away immediately).

And I'm not going to try and learn more about this right now, got some
mdadm fun (and maybe other things) to figure out still.


Cheers,