Hans Eisenrieder <[email protected]> writes:

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.

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 -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmdpwFMACgkQ0EujoAEl 1cA0CxAApAw1kf/UXssCWb4LAaiMuFCunDnqOwjT9gBapwpBL6rugt+D6XVYtE8B kGTv5uaxZQ7lj5ABmUjZ3rP4Y9a2XwHIxRNnOc72x9eIlH/SN0W++gBqxBgQevyI LVYUtL+LpbwK0PbtYR/6Bww0oc6Jv/MDyeyIcps5iESQNlzFCUZolTew3m+XOY02 IodveWz8s1mY7CE0uJhFDnG1Vx06gVzoaW8BGgoEfMkTINYT+k/Yj9S9Exh5Abqk AawuIyQsJd2UVZTxoC6ZfeQ99BS1MEK7Qh9B7KcSSswAe62HzkuNDIKhSxGH8NTV 2RN3pdJvoWW+v8h9xIctGRDvqmhel0352ekrF0BiTu9pBQcXAuJWyOIhBY1SI+fT KZQGLnTwY0GRUoWyPF3oJF61ndlSBc/sRUfrZwLN4m/i90khF2IJUPqjGkpy7Hvy tQ+/3fUzKcqUvIzskWUd8wq81Eytr6s0NwI9GLdvxpxLxACI+FWJYuCxc5wPljcF BKCAEMANKlybBerEZbeeOxkGlnU2do+n7WQGNitFSc3RnlerRbCNAEfpaObD2dbn RcjeA2EYlCzT4b7KqKgyLR5e87nIsdVDOV0CQMdD3pQgYKfapqIbi2ws0noY0BJq 29GBu7NMSmtc/5Fe6ZGt0JWZj7mjFh7HsTwDMn0hKMQzG1n/cLE=0+tf
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa

Philip Hands <[email protected]> writes:

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.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmdsaU8ACgkQ0EujoAEl 1cB0MhAAwq+4vBqSXUHSdie3VMV1dJPfvFDsdGfZnWNFl7ldXTtvsiXC8xO+ZKL1 o99MnCX4V9DD+oc/c1uJVdwoJ/0jKOG8/cyXI7K1CtoH2nc83jo5VQiN5MzdkiEd t3hnO8qhF+gjqF7jsbdCkq2HTSEF3BKcdwygSLOWQ2JD2rGOy1THQDoOq5fWmMdh QQBZ1YSSH2zKLZjBdPjLCbOQkF0pRbTCAAXJFdv1WdbA4WiVSUFPjHQ2/B8e14vf 85yDcnAa+kg7U3yrmm8qkswasScR+5zWm4q2P7PMcPchszII96uqbW+uh+jyKQl3 mp+L5OyA963tNrPYGypWWDihmdGrC+xSK4icXGt56FWXxHilBqgpWr0VJNSAXoo+ VemJ2NP6XtJI6W27DLpqi68AU96n5vqE5g9j6HAWnPJvlnYCR4Crx4Z/SAixdV2w FL09HT2cOyvbZGnEDwIyRb5X8sI4buLqC2aW/8putZMKWM9nP8+/wLYt0JO1M4wU YgionlXMhEt4m0u96YiEFTjPj0chs/6BUOoAuEVDg7B3xI7aSVFSlweziqnBh5H/ RaIPfyJXlK9v2NDizUOzaLzpPMYmeORg2x0PqqVFs2+BS/sELgoRYNhkyOek2UTw TMrxT0/ybYIk/9W+ZHUfq+gObOu0NAzx/g7Aavgn16yDBugFepQ=cWgg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa

Philip Hands <[email protected]> (2024-12-25):

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.

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 ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmdsr2EACgkQ/5FK8MKz VSCWQQ//W5w/qQY46//e9yEG4d8Wix8il93mvcisTX5+RBSU5xsCUo7gO0zTMkaf eGBQ0f+Bflcfi1NAz0KrLnZHsZ4UORlCojmxyQcFS4pyHgCEvrsBFMgJuv7JXwhf fFaecNfOApE25RZda4ZlAkFWzgJZEGt2Q3f4D0o0xyoJrkNGu4SKrTssIGQGEHmo vSpy8dkVhslV55iE5O3gALHFkxV10NAO/gh54/QD0y8Ab7LTFEEPprGfS/+GT/uJ QsvjvnP5PUdTqf2iY35ADeLwTnxGglDLUZn1bRDi9FqrLz1nTCWX+30kA3FaitpO ZbsxwDmTWB7Sb4FxFLEyL2lkeiqDfHHORoAVKD1eIR8JuJfW7NEfhs6sWqf6PDwq BTOvHOXuyCtznNVfPdUKGK6Zo9G80TEJ6LB4yBQbocTEiDf6a82bJjZXM3ncYua1 WPkWhM/6CVZIb2WZqZnhzqsBs6tSHamAdg+pGTPyI5WgElDgtmJy1B0UrNJL7Veo 3wKlkZVAaAZ+pTm0a5swTfvlUknWJvY9R5RpOEVlLQhHznKWnpUZpaiI4CHGr0Vw TrOEFVjfXhXICteOs7RmhwwbYj2JOxKpXjyg6+dTc5qDem3KE9a1CrLVESsHOYMa H4eOtftN+2lcwSwsAOuKzq0cStXsATeShcQ7zSqD/ltzdZTJcWM=
=cLBV
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Cyril Brulebois <[email protected]> (2024-12-26):

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,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmdsuC4ACgkQ/5FK8MKz VSByrRAAm4Tv9DSuSoMI8vAD4NqvIaAmVqmO9PshckgeNk4KnlES7q0JSqk7otDZ b+5CD1mnsvCKhx78ZsJhsIBaMgj0yyr4ebHIRKuKQhImlAZWvQBqFjf7IppjGj76 968AzhaVvVq0lV6NsjgPB3ZW48ORnLqn4NmLLeVOMXq+fgebqy7Xeu+GQFvAWKSf c1pJglIh49tSJScoG1wuXANudFtkdjZMTQzXzWi7b/NGO5flF70doz6lC/WMfDdg p02KKmglwTryOoc8hb6WB7GFICWmVRiDcvhrC9GYX2gRD7GeuoXvwSmYzUPkpBmU ehPFfobK6Chk8L+XqIE4MJtbNln/HKeDPca/3keRtU/cBilSD+9hp17CZW49LuQ9 W5/FRRXwBAM0vQ9ZRIxNnYWmGdG6s0aa1o8rtRxsxBR44kTmpyjCyzmBG53tFjHV DwlLEqexjo7w/epMyy3mPoFf29dzZPzboTjR2YCpSsC6kIi5whYveyKC5P+QbMUu Wxx5kj6vwZc1McH2FdeNoKfpNVrA2rV66cgSY/YNsmzKUsVzdrfQTF03kaEgZKq+ Ea3GYt09t+RehKAG+ElL0LvrDuCIWkFYtM8GULiO1gSlgiJLE+4rLx0I+R1ybvzU 5zD+WyhLi2coIQHgTcNyAIA/3Fd3HRy1kGyRDMgN5BhvNDgid7E=
=Ghk3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

Cyril Brulebois <[email protected]> writes:

Cyril Brulebois <[email protected]> (2024-12-26):

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.

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.
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmdtvTgACgkQ0EujoAEl 1cBdvhAAl8xHKqmf+uDUtYQc+cJvLdYb0IzZrmVHwMrulQA2fRojaoP7XrOHcY9R 2i9g4XgtArQw5aHJ9r5+hCvz2blVYD7+70s39AwbJw1l+Ha/whNQp0sKyh2gDWPh A40r0w1bkXP6zK7B47WCF6wFAivqP6LlmdzHlUSkbnaNgWf/OYdE1/2NtBHwJaIY 4lza+483Ous8ylnp7H4cBkHf03tGmOC+q+MhihsDRBMsbt+ogegjw/suzm/SGmlt +M48oL0BZu4wm9AeQ0jx6j21qUdo6UkRrwA2Zg0m2mc18xdxW58lfkZ/JcGKQnrW eTxvoIQSC9WuL3K8HnoKcu7VM7EdTa46TAbNPDtr4bQpUja0mULovZn1CV2c8TO/ /TKlW/UEBQwzTXe44eggElhcwu7eC073lLphyQqrpliSh7AoilAxRic/IexUrKJA +NNttGrhF5jtP1A4E/wbu3MrWFhM0DAdftJU6UYP3t9syPbkPACFFhW1w3o7KlDs 90NwEKgoQCk/HXDXSJwzO7WLAen2Pm240d9MaZzvB7y6UN+Zw28A7eG0UGLTeVIW 6zfpxLhDTd0scr7nNIBDSqUjWpbhtnclESULyZNasJnfyB4QI+musOWPJZaZD49K K6rL77qBWpa4ElRvVrS3RHO8SbzkPfzXdUvO5OjZP8UWCrI8Ia8=ZE5N
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa

Cyril Brulebois <[email protected]> (2024-12-26):

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.

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. https://d-i.debian.org/dose/graph-unstable-i386.png

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,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmdwX+QACgkQ/5FK8MKz VSCeTQ/+OWZ7wvrY4N2e4YMw1te6gIWKZZgbk3LSmBNSp5EBWwtb9uCubBwN+vIV lnHun8ERkpgnNYFnJTwB9YwnbWz70KsbwasL+RpT2WR9F5olAuAH5kWdRm7MDzSW t+tSI2UDdCISFzYkUomrA4lWBoO3e+IrmqFwupd3IoPJ7VJ8Nba5ZDeowZmhVust wNzrOA6zSojObtApkOO32tQmUgmIJZH0YuVJnnA9EoHBLhn8Z3OtO15K+onXfg2O HFAxOJ9MTUJHARkWlPj7IFCZMM8TVOxPmJRaAcEkYwJrws3dY4HX/l7DSjfXyKO+ K9QCdaOrBVA8u/xWlpEXbzbEBMWP6Hzyx/RMRmXggvHBnbXNxGSg+etF1yMw+5cF 9Jff8h8wdZ6ka6p/2GmcnQStQ9LZDqYoky3jwJJaDCmxD8okFf6QKvzCvKclYnBv S1Yb2Jfvlfqypn5EnrL6vSC92fqvDAJrSImStU1Y3L8WyX/jeraYusqBNLMqwUZ2 ztysEDtOgClF0bYNhWTvs7SKt50I3af2NmPvhNYtx4asJLulDCwMZz7FjF6a0DKi UeP6YlQ5ThrSaMI1cc6q5hGN+GHAZUIkrA1/+WMgvxo1EaUgqIrhGekaAz8pfzq7 /pFHZVMSsRl5wSJMmSMmHD946oq9iZbjuP9XyTTXOx8a87/Qpho=
=YS5z
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*