Re: amd64 daily installer images not updated since 2026-07-05

--qewrfck7whuck7le
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

Roland Clobus <[email protected]> (2026-07-17):
> It's a good thing we have such safety mechanism. I've now reverted the
> change, so there will be no new images until the core problem (the
> size of the netinst-iso) is solved.

Thanks for doing so.

> I saw these files as well (I looked at 2sidamd64) and the 'No
> linux-image-*' line triggered me. I've seen some other changes in the
> git repos in the past that replaced 'linux-image' with 'linux-binary',
> so I (wrongly) concluded that it might be needed here as well. I
> missed the 'over-full, Rollback!' line.

Just for the avoidance of doubt, looking at all our repositories, I'm
only finding one occurrence for such a switch, and that one is indeed
correct:

  https://salsa.debian.org/installer-team/debian-installer/-/commit/105ceb2=
ca1b8abc874dad53e2be1dcf456e8c0dd

Backstory: we stayed with the kernel-image name on the udeb side because
the kernel-image =E2=86=92 linux-image rename only happened on the deb side=
 (a
long time ago), where the kernel-image udeb shipped the actual kernel
binary, plus some modules depending on the architecture (mostly arm* a
while ago but even amd64 got some more in trixie =E2=80=94 see
debian/installer/modules/*/kernel-image in the linux.git repository),
as opposed to the linux-image deb which used to ship the kernel binary
plus many modules (which is now getting shipped into different
packages).

In the =E2=80=9Cbuilding the installer=E2=80=9D context, pulling the linux-=
image udeb is
the right thing to do (provided the required modules are still shipped
alongside the actual kernel binary).

> Which turned out to be incorrect. I've reverted the local change in
> casulana (from
> https://salsa.debian.org/images-team/debian-cd/-/merge_requests/59)

Thanks. I'm wondering whether it would make sense to also unpublish the
few images built yesterday/today as well. People wondering about the
missing images might search other directories and find/download/test
broken images?

> So the answer to my own question is: 'No, it needs a different
> solution to make everything important fit again'.

In a nutshell: Yes, please. :-)

(I decided to send the previous mail as soon as I felt like it had
enough details to give you a clear picture, but I wasn't sure if and
when I would have more time to share more hints. Devil, details, =E2=80=A6
is the reason why I didn't write that particular answer. See the
alternative plan below.)

> It turns out that the current limit of 1GB (10^9 bytes in 488281
> blocks of 2048 bytes) is the reason for the missing amd64 netinst
> image, not anything related to the kernel.

I'm not going to hunt for numbers here, but it could be that one of the
recent version bump pushed us over the edge. It also happens that one or
a few other packages needed for debootstrap get built with debug info,
or =E2=80=9Cstuff=E2=80=9D happens that make them really bigger all of a su=
dden. It
could be that we end up pulling several gcc or llvm runtimes at the same
time, which makes the footprint larger (both on the installation images
and in the installed systems), and/or new/bigger firmware packages.

My preferred action, if I had time, would be to try and understand
whether there's an =E2=80=9Cobvious=E2=80=9D package/set of packages that's=
 responsible
for hitting the limit, or whether it's just some kind of slow/steady
growth that ended up triggering the overflow.

Here are a few examples from the past (debian-cd.git):
 - 18b865eca709bcc21880d7db4d3fae8693575f37
 - 213c680c07fee552a28b8fef5bdae166b2eb1ff2

Looking at one of the logs mentioned earlier, you can spot all .deb
files being considered but also some getting ignored. Seeing
firmware-qcom-soc ignored but firmware-qcom-dsp included kind of
triggers some itching sensation, and indeed, that's not a small package:

    106M	firmware-qcom-dsp_0~20260622-1_all.deb

This is a package only found in testing/unstable, introduced early 2026.
The following changelog entry reinforces my initial impression: if it's
OK to ignore firmware-qcom-soc (from src:firmware-nonfree), it might be
reasonable to also ignore firmware-qcom-dsp as well=E2=80=A6

   [ Robie Basak ]
   * Adjust versioned Breaks/Replaces from firmware-qcom-dsp to
     firmware-qcom-soc now that we know the exact version the files were dr=
opped
     from the src:firmware-nonfree side.
   * Upload to unstable since there's no longer any benefit to holding this
     package out of unstable.

Source: https://tracker.debian.org/news/1718101/accepted-hexagon-dsp-binari=
es-020251021-1-source-all-into-unstable/

Possible plan:

 - [x] Trick myself into actually looking instead of just giving a few
       examples.
 - [ ] Exclude this package as well and see if it builds again, putting
       the maintainers in the loop at some point for input/sanity check.
 - [ ] Actually do a survey of all firmware getting included now,
       comparing to what's available/included/excluded in trixie, and
       investigate new packages to see if (1) they actually take
       significant space and (2) they are or might be dispensable.

Alternative plan (which I meant to mention right after listing the two
commits above, before tricking myself):

 - [ ] Bump the size from 1G to 1.1G or even 1.2G, effectively punting
       the investigation to =E2=80=9Clater=E2=80=9D. This is likely easier =
and quicker
       than what I mentioned, but I can't help but worry this could be a
       one-way street, and I'd rather try and avoid bumping the limit if
       some reasonable amount of work lets us stay below the existing
       limit.


Cheers,
--=20
Cyril Brulebois ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmpaIlEACgkQ/5FK8MKz
VSDa4g/9Eyg/miQhzuzLHg3NeNJO2PeUcxHIEdr11B5P65HMLDlA/IYpMqKs6pHi
uSxcJh2nv1xBFbIxNnOt09MAUdgvjxX6wLRcJETqY4gmryklvSHJMfn4Di6DUq+5
sNVL6yBhmDFEAZrF0HyjRRJP6TFI4NFKdLGzedDVAc6oyNT6WDVGFKQP1ZecX0Lf
VNsOj4Qwi6JCHTmth6RtTNRF70k9b7Sq9gAS8g2/3xTn9W6xZKk1T/eiQoFRA283
bXVyhFr6S+9N24l/L2qPtlM2vhx//pbfzuARzD7p4qLXDY/+UmPPRcIF2z8B2T/A
f2HDVn3YeyaOhSg9ypuCrqvez2lOAWPlYNyVigCYhrDzbfwS9ZedTdB2Zr1Kcg3C
sh8bfNWVDBggvBb5ezoMnBIYB2OPGrRhXa5GHxU86wBhtZ1DXLm4czLG6YinGZqH
Z2AtX/7NL8swCJNiLwLPPETceSE4yfGx6YmaLp5ReYi/Jso3cqyjxjxQIPr3LeZL
4TyUOB5Pl8Mo6gH4Em8qHWcI7/khJndBNoqizPu0sCw9elgwV93aj97OZibqWvPk
w3yoLMkcWAX00NxYcUQQyVGgL4fAb7yHLnLKHhJZM8a+nLpxZnvU+oO/nKynCCui
1QGt6Ik0F1rNQHLwIvqj3n4q61QZAUQUCvDh62BGqZhAka4f1CA=
=lllP
-----END PGP SIGNATURE-----

--qewrfck7whuck7le--