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/105ceb2ca1b8abc874dad53e2be1dcf456e8c0dd Backstory: we stayed with the kernel-image name on the udeb side because the kernel-image → 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 — 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 “building the installer” 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, … 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 “stuff” happens that make them really bigger all of a sudden. 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 “obvious” 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… [ Robie Basak ] * Adjust versioned Breaks/Replaces from firmware-qcom-dsp to firmware-qcom-soc now that we know the exact version the files were dropped 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-binaries-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 “later”. 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, -- Cyril Brulebois ([email protected]) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
