On Tue, 25 Mar 2025 at 00:14, Peter Boy Uni via server < server@lists.fedoraproject.org> wrote:
Unfortunately, I was unable to attend the last Blocker meetings due to other commitments. Hence my opinion here.
Am 24.03.2025 um 18:18 schrieb Adam Williamson via server <
server@lists.fedoraproject.org>:
Hi folks! Sorry I missed the meeting last week. Just wanted to kick off a mailing list topic for this. As briefly discussed at the meeting, the aarch64 server netinst image is over its 'maximum size', and this is a release-blocking bug: https://bugzilla.redhat.com/show_bug.cgi?id=2352679
we can either try and figure out why it got bigger and squish it back down again, or just bump the policy maximum size. We're generally more relaxed about maximum sizes these days since they're not so tied to optical media any more and USB sticks are plentiful and cheap.
The main reason for our (i.e. Server WG) reluctance to increase the size is not the storage medium, but the consideration of the precarious internet connection in many parts of the world. And I still think that's important.
There's also other reasons to keep it as small as possible, on machines with smaller amount of RAM there's a limit to how much memory you can use for the initird, basically the bigger it gets the less memory constrained machines you can run the installer on. Often that's not so much an issue for things like small VMs as they're generally provisioned with a pre-canned image such as a qcow or raw image.
On the other hand, we naturally also want to provide a functioning server in regions with a weak Internet connection. Therefore
Often those sorts of usecases would actually be better off with the full blown server installer as it has the main packages on the iso image rather than pulling them down over a network multiple times if network bandwidth/stability is truly a problem so they likely wouldn't be using the netinst anyway. Be careful conflating the two problems :)
Am 24.03.2025 um 20:29 schrieb Peter Robinson via server <
server@lists.fedoraproject.org>:
...
Yes, that would have been my guess, there's been quite a few qcom
firmwares added recently, and sadly they're tending towards device/vendor specific signed versions rather than SoC specific variants like many other vendors do.
So, if the increase in size is due to technical reasons / technical evolution, then I think that's OK. In the past, these were often build artifacts. In that case, I would not consider it OK.
@Peter Robinson: What do you mean with „guess“? Is it “just” a rough guess, or does it mean a reasoned judgment based on facts? (I assume the latter, sorry my limited language skills for the finer points here)
By guess I mean an educated guess from my knowledge with both arm and as the linux-firmware maintainer but I have not actually looked.