Oversize F42 aarch64 netinst image

[Adam Williamson]

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
current policy max is 1GB, and I don't remember the last time I saw a
1GB USB stick, so bumping to say 2GB probably wouldn't cause any
*practical* issues.

Still, it's nice to have these maximums so we catch any cases where
images are unnecessarily getting bigger. I do have a process for
figuring out what's taking up space on an image and I'll try to run
through that and post results on the bug later. These days, it
*usually* turns out to be linux-firmware getting bigger; various OEMs
are constantly dumping large blobs into linux-firmware these days,
something we can do little about :/

[Peter Robinson]

On Mon, 24 Mar 2025 at 18:33, Adam Williamson via server <
[e-mail]> wrote:
> 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
> current policy max is 1GB, and I don't remember the last time I saw a
> 1GB USB stick, so bumping to say 2GB probably wouldn't cause any
> *practical* issues.
>
> Still, it's nice to have these maximums so we catch any cases where
> images are unnecessarily getting bigger. I do have a process for
> figuring out what's taking up space on an image and I'll try to run
> through that and post results on the bug later. These days, it
> *usually* turns out to be linux-firmware getting bigger; various OEMs
> are constantly dumping large blobs into linux-firmware these days,
> something we can do little about :/

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.

P

[Paul Maconi, Jr.]

Hi Friends!

I read through the final blocker notes today and the meeting notes from
last week. I think that the historical constraint to 1GB might be too tight
for the general user population. Yes, you can still buy drives that small
(512 MB, too!), but they're often more expensive than buying an 8GB or 16
GB flash drive. Is keeping the image that small 'worth the squeeze', as
they say?

Thanks,

Paul

On Mon, Mar 24, 2025 at 2:30 PM Peter Robinson via server <
[e-mail]> wrote:
> On Mon, 24 Mar 2025 at 18:33, Adam Williamson via server <
> [e-mail]> wrote:
> > 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
> > current policy max is 1GB, and I don't remember the last time I saw a
> > 1GB USB stick, so bumping to say 2GB probably wouldn't cause any
> > *practical* issues.
> >
> > Still, it's nice to have these maximums so we catch any cases where
> > images are unnecessarily getting bigger. I do have a process for
> > figuring out what's taking up space on an image and I'll try to run
> > through that and post results on the bug later. These days, it
> > *usually* turns out to be linux-firmware getting bigger; various OEMs
> > are constantly dumping large blobs into linux-firmware these days,
> > something we can do little about :/
>
> 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.
> P
>
> server mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Peter Boy Uni]

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 :
>
> 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.

On the other hand, we naturally also want to provide a functioning server in regions with a weak Internet connection. Therefore
> > Am 24.03.2025 um 20:29 schrieb Peter Robinson via server :
>
> ...
> > 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)

I will put this on our agenda for Wednesday so we get a decision.

—
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
[e-mail]

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast

[Adam Williamson]

On Tue, 2025-03-25 at 01:14 +0100, Peter Boy Uni via server 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 :
> >
> > 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.
>
> On the other hand, we naturally also want to provide a functioning server in regions with a weak Internet connection. Therefore
> > > Am 24.03.2025 um 20:29 schrieb Peter Robinson via server :
> >
> > ...
> > > 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)

I've posted my findings here:

https://bugzilla.redhat.com/show_bug.cgi?id=2352679#c6

if anyone else wants to poke at this, it's not terribly hard. Just grab
an ISO and loopback mount it:

mkdir -p /mnt/isoloop
mount -o loop somefile.iso /mnt/isoloop

you can look in /mnt/isoloop and you will rapidly find that most of the
space is taken by a single large file, /mnt/isoloop/images/install.img
. So, you can mount *that*:

mkdir -p /mnt/f42
mount -o loop /mnt/isoloop/images/install.img /mnt/f42

...and then you can see and look at the space used by the files within
that image. Do this for an F41 and F42 image simultaneously, and you
can easily compare the two.

[Peter Robinson]

On Tue, 25 Mar 2025 at 00:14, Peter Boy Uni via server <
[e-mail]> 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 <
>
> [e-mail]>:
> > 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 <
>
> [e-mail]>:
> > ...
> > > 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.