We have an F39 blocker bug for the Server aarch64 netinst image being over its size limit of 700M. This doesn't seem easily resolvable - we've already trimmed the netinsts a lot over the last few years, and the latest size increase was driven by an increase in the size of qualcomm firmware which pbrobinson says we cannot ditch. I'll try and squeak out some savings if I can, but I also want to propose this.
The 700M size limit is based on the size of a CD. (For the young folks in the audience, those are little shiny round discs you can hang up to scare away birds and which us old folks used to store music and data on). I frankly doubt anybody is writing any of our installer images to CDs any more, but I especially doubt anybody is writing aarch64 images to CDs. I doubt there's any aarch64 system in existence with a built-in optical drive, and I certainly don't think there's one which can't read a DVD.
So, this size limit seems pretty silly. We've stuck to it for a long time as a way to avoid bloat in the installer environment, but I think we're at the point where it's becoming unrealistically difficult to keep the size under 700M even without anything obviously identifiable as "bloat", due to the ever-ongoing increase in the size of linux-firmware.
So I'm proposing we bump the limit to 1GB (not GiB) for at least the release-blocking Fedora-Server-netinst-aarch64-RELEASE_MILESTONE.iso image (see https://docs.fedoraproject.org/en-US/releases/f39/blocking/ ). (If FESCo decides to also bump the size for x86_64 netinsts...I wouldn't be opposed, frankly). We don't actually have a clear process for bumping the max sizes of images that aren't Spins, so "file a FESCo ticket" is my best effort (I'll alert devel@ to this too).
Fedora-Server-netinst-aarch64-RELEASE_MILESTONE.iso
Ideally we'd do this kind of thing a release in advance, but practically speaking, I think it makes sense to do it for F39 if we cannot somehow find a way to get the image under 700M on Monday.
@pbrobinson as the ARM guy.
+1
Metadata Update from @ngompa: - Issue tagged with: fast track
Should this be a server working group decision?
But I'm +1 in any case...
oh, yes, that's a good point. sorry, I thought about it from lots of angles but not that one somehow. CCing @pboy , at least. I'll mail the server list.
For sure +1
The ticket says:
The 700M size limit is based on the size of a CD. … I frankly doubt anybody is writing any of our installer images to CDs any more, … We've stuck to it for a long time as a way to avoid bloat in the installer environment, but I think we're at the point where it's becoming unrealistically difficult to keep the size under 700M even without anything obviously identifiable as "bloat", due to the ever-ongoing increase in the size of linux-firmware.
The 700M size limit is based on the size of a CD. … I frankly doubt anybody is writing any of our installer images to CDs any more, …
We've stuck to it for a long time as a way to avoid bloat in the installer environment, but I think we're at the point where it's becoming unrealistically difficult to keep the size under 700M even without anything obviously identifiable as "bloat", due to the ever-ongoing increase in the size of linux-firmware.
The first argument is - or was - about those old times ..
Our current issue is not so much about avoiding bloat in the installer environment, but to keep the installer image(s) as small as possible, specifically to enable people in regions with a weak internet connection to use our software as smoothly as possible. And if we don't limit our horizons to the U.S., Europe, and some highly developed regions in Asia, that's a serious issue.
Nevertheless, this should not block release 39. So I would propose to make an exception for aarch64 architecture.
And that doesn't contradict our reasons for the size restriction now. Suitable aarch64 hardware is currently so expensive that it won't be used in those circumstances anyway.
In practice there is nothing we can really do to stop it growing, because stuff is going to keep getting added to linux-firmware and we just can't stop that. We've already trimmed just about everything else we can think of from the installer env to compensate for the last year or two of linux-firmware growth, and there's just nothing else to cut. I've looked, it's really pretty tight now.
Maybe @salimma and @dcavalca can be convinced to revive their Change to minimize linux-firmware...
linux-firmware
Yes. Oh my gosh, I started with Fedora version 0.5, and it has been a steady rise since then.
Golly, I remember 800meg CDs being too small, and then we allowed 1024meg CDs and then 2gig CD and then ... USBs. Hip Horrah for USBs.
YES, allow the increase to at least 2gig (the smallest purchasable USD drive available today.
+1 for expanding the aarch64 size. Given that this is likely to only be used on server-class hardware, I don't think the restricted-network argument is particularly valid here.
peter and I already work on minimizing it to the extent possible. the biggest idea in that Change - setting up firmware subpackages to supplement kernel modules so you only need the firmware for your system's hardware installed - wouldn't actually help here, because we'd still need to include almost all the firmware in the installer images, since they're...generic installer images. they could run on any hardware.
Do I understand correctly that trying to reduce the image size at this point in the release process will be too invasive or even impossible?
I was writing a long reply about how there really isn't much to cut at all (never mind the point in the release process), but in researching that, I might have found something: a backport of this adwaita-icon-theme MR might save us a bit of space. Testing that now. This is the kind of scrabbling-around-for-a-few-MB we have had to do frequently over the last year or two to offset the linux-firmware increases, though.
@adamwill If we did backport this, it would require a freeze exception?
Not since the size bug is a blocker, no. We'd just mark the update as fixing the size bug (if it turns out we can fix it this way).
unfortunately it looks like those cursors compress well. the patch does make the package smaller, but only from 658K down to 564K. The uncompressed space saving will be larger, but there is compression when we build the images of course, so I'd expect the saving on the image file size to be small as well. :/ I'll run a test to check, though.
edit: yeah, with the way netinst images align to certain size boundaries, it seems like this doesn't reliably make the x86_64 image smaller at all. I can't easily test on aarch64 (we don't run updates tests on aarch64 in openQA, which is what I'm using to test this), but no reason to believe things would be different. So, that's a dead end.
so yeah, to resurrect my long comment: there really isn't a lot of slack space in the netinsts at this point.
The skopeo and rpm-ostree binaries are large, but those are necessary for https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#ostreecontainer and https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#ostreesetup - without them you can't use those kickstart directives from a netinst to do ostree installs.
There's a dep chain gdb -> gdb-headless -> source-highlight -> ctags which we could maybe strip some bits from (the ctags binary is 2M), but I don't think we'd get much out of that. (gdb is included for debugging, since at least 2009).
/usr/share/locale is 122M uncompressed (probably a lot less compressed, though). that contains translated messages from all the different packages included in the installer environment. we could possibly look at not including translations to languages we don't offer the installer in, but not sure how practical that is. /usr/lib/locale/locale-archive is 224M, that's the contents of glibc-all-langpacks; I dunno if we can attack that at all, but I don't think it'd be easy.
we have 9.6M of licenses on the image, but again that's uncompressed and license text compresses well, and anyway, we probably need them to be there for compliance.
we could possibly shave an MB or two by wiping some kernel drivers for crazy enterprise network adapters whose firmware we already strip (hi, Mellanox), but that's not gonna be enough.
we have amdgpu firmware on the aarch64 images, but I kinda feel like when I asked about this, pbrobinson said it is possible to run AMD GPUs on aarch64, so we can't just drop that. ditto several Intel firmwares.
that's, like, just about everything I can see after going through just about every file of significant size in the installer environment. There's just not a lot to cut.
I doubt there's any aarch64 system in existence with a built-in optical drive, and I certainly don't think there's one which can't read a DVD.
In 2014 I had APM Mustang with optical drive under my desk and used it to fix FTFBS on Fedora/RHEL packages. But it was DVD drive and system was unable to boot from it.
+1 to change
I think it's worth it to continue the minimization efforts, for the reasons already mentioned, including general efficiency and support for people with weak connectivity. Those efforts are already happenning and we should continue, but growth is inevitable, and we don't gain anything but being very strict about this when the current limit is clearly outdated. We should increase the allowed image size every once in a while, as reasonable.
Yes, it is possible. Heck, I believe someone got AMD GPUs running on the Raspberry Pi 5 recently.
There are Solidrun Honeycomb users with AMD graphics cards.
Maybe one solution would be split of install media to Fedora image + "less obvious" firmware image. And then "insert firmware media into any usb port" message during boot (like Debian does) if there is hardware requiring not-present-in-image firmware files.
Are you sure? We are talking about server here, no graphical interface at all. Sometimes not even a monitor.
I appreciate all your efforts to keep the media slim. And I agree, we will never get back to the times we could install from floppy disk. And as I alfready said, aarch64 is a special case, currently. So again, no objection to rise the size of aarch64 net installation but keep everything else untouched for the time being.
Keep in mind we default to a graphical install. So with that in mind, we need the graphical environment to be working.
And thanks to all of those who continue working on minimization efforts across Fedora! 👏
Per the Fast Track policy:
Any FESCo member may request a proposal be considered "Fast Track", and it automatically gets approved immediately if it receives +7 without any -1 votes. Any -1 vote removes the Fast Track request.
The vote count is (7, 0,0) as of this morning and it is APPROVED.
Metadata Update from @mhayden: - Issue tagged with: pending announcement
Announced on the Fedora devel list
Metadata Update from @mhayden: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @mhayden: - Issue untagged with: pending announcement
https://pagure.io/fedora-pgm/pgm_docs/pull-request/52
Log in to comment on this ticket.