Description of problem: Unxzed images are too large, Workstation is over 14 GB and Minimal is over 4 GB (see https://docs.fedoraproject.org/en-US/releases/f39/blocking/). Although xzed images are below the size limit, I'd guess that the intent was that the images would fit on 4GB (Minimal) or 16GB (Workstation) flash drives / SD cards. Version-Release number of selected component (if applicable): Fedora-Workstation-39-1.5.aarch64.raw.xz Fedora-Minimal-39-1.5.aarch64.raw.xz Workstation: $ unxz Fedora-Workstation-39-1.5.aarch64.raw.xz $ ls -l Fedora-Workstation-39-1.5.aarch64.raw -rw-r--r-- 1 lbrabec staff 17179869184 Nov 2 11:44 Fedora-Workstation-39-1.5.aarch64.raw $ ls -l --si Fedora-Workstation-39-1.5.aarch64.raw -rw-r--r-- 1 lbrabec staff 18G Nov 2 11:44 Fedora-Workstation-39-1.5.aarch64.raw Minimal: $ unxz Fedora-Minimal-39-1.5.aarch64.raw.xz $ ls -l Fedora-Minimal-39-1.5.aarch64.raw -rw-r--r-- 1 lbrabec staff 6442450944 Nov 2 12:01 Fedora-Minimal-39-1.5.aarch64.raw $ ls -l --si Fedora-Minimal-39-1.5.aarch64.raw -rw-r--r-- 1 lbrabec staff 6.5G Nov 2 12:01 Fedora-Minimal-39-1.5.aarch64.raw
Proposed as a Blocker for 39-final by Fedora user lbrabec using the blocker tracking app because: Workstation and Minimal raw images are over the size limit: https://docs.fedoraproject.org/en-US/releases/f39/blocking/
Also note 17179869184 is exactly 16 power-of-two (not power-of-ten) gigabytes. https://unitconverter.io/gigabytes/bytes/16
Discussed at 2023-11-02 F39 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting/2023-11-02/f39-final-go_no_go-meeting.2023-11-02-17.04.log.txt . This was accepted as a violation of the image size criterion, but waived to Fedora 40 Beta for being both "hard to fix" (it's not really practical to somehow suddenly slice a big chunk out of Workstation at this point) and "last minute" (it was filed less than a day before the go/no-go). So, moving to accepted F40 Beta blocker.
I know that we still have about a month until branch, but (unpacked) image Fedora-Workstation-Rawhide-20240110.n.0.aarch64.raw remains unchanged in size (17179869184). As this bug has been accepted as a blocker for F40 Beta, I'm posting this comment as a reminder, so it can be addressed earlier in the Beta cycle rather than later.
We've been talking this over at https://pagure.io/fesco/issue/3122 , there are several images oversize so I haven't been updating every bug.
I have now made a recommendation to FESCo in https://pagure.io/fesco/issue/3122#comment-892727 and proposed it as a PR in https://pagure.io/fedora-pgm/pgm_docs/pull-request/64 .
ah, hmm, now I see this one's a bit different from the others. Sorry, I had missed that in the FESCo discussions. I dug up the history, and we *might* actually have a shot here. We bumped the WS disk image size from 14GiB to 16GiB within the space of a couple of days in June 2023, because of the https://fedoraproject.org/wiki/Changes/BiggerESP change, which at the time was bumping the size of the ESP on the image from 600MiB to 2GiB. That Change got mostly unpicked, so I think that shouldn't be happening any more. So...we can try putting it back down to 14. But I'm worried it might still be just slightly too big, now, with the firmware changes. Unfortunately, oz/imagefactory only does integer power-of-two GiB/TiB sizes for disk images, according to the quick look at the code I just did. So we're stuck with 14 or 15 (or 16) GiB as the size. 14 GiB is comfortably under 16 GB (15,032,385,536 bytes), 15 GiB is just over 16 GB (16,106,127,360 bytes). So we might wind up in a situation where we could fit all the bits in a 16 GB image, but the tool just won't do it for us. :( Once we're done dealing with the FAS emergency I'll ask nirik if he can run a test build at 14G and see if it works.
Minimal has been at 6GiB since 0a2a083ac9a1340732d765337aa506e797647024 in December 2020. Before that it was at 5GiB ever since it was introduced in 994e4a7b49b782b6ad06f74b54e112130c13138d in April 2017, AFAICS. So I think that size is just wrong, or was intended to refer to the compressed size. I'll clarify with ARM folks.
Paul, Peter, WDYT about this? Are the sizes intended to be for the compressed or uncompressed files? I kinda agree with Lukas that it makes most sense for them to be uncompressed. On the whole my inclination would be to bump the specified max size for Minimal to 8GB and try to get Workstation back under 16GB *somehow*, even if it means (sigh) patching oz...
I wrote https://github.com/clalancette/oz/pull/310 to try and help with the size specification, if we need it. That would allow us to actually specify an uncompressed image size of 16 GB (power-of-ten gigabytes).
(In reply to Adam Williamson from comment #9) > Paul, Peter, WDYT about this? Are the sizes intended to be for the > compressed or uncompressed files? I kinda agree with Lukas that it makes > most sense for them to be uncompressed. On the whole my inclination would be > to bump the specified max size for Minimal to 8GB and try to get Workstation > back under 16GB *somehow*, even if it means (sigh) patching oz... So there's been a lot of movement on the linux-firmware reduction, the main one with the latest update is around 50-60Mb, I think at one point at it's worst it was 250+ Has anyone actually done any analysis or do people just keep bumping it these days. I think there's probably some basic wins. I'm not sure what's pushed minimal image up because there it's usually firmware and we've actually been dropping there.
So nirik kindly ran a test build with the size bumped back to 14 power-of-two gibibytes, and it failed because it's 331 MB short: https://koji.fedoraproject.org/koji/taskinfo?taskID=112363682 that's exactly the scenario I thought we might be in, so I guess it's a good thing I wrote that oz patch. I'll try and fix whatever the test failure is there soon, then we can try another build with that oz and the image size set to 16 power-of-ten gigabytes, and I'll bet it will work.
OK, now nirik did a scratch build using oz with my patch (and a change to koji: https://pagure.io/koji/pull-request/3989# ) and the size set to "16GB" and it worked - https://koji.fedoraproject.org/koji/taskinfo?taskID=112376177 . I'm downloading it now to check the uncompressed image size actually came out as intended.
FESCo approved the proposed changes, so Minimal is no longer over size (its max is now 8 GB). For Workstation we still need the oz, ImageFactory and koji changes merged, then we can change pungi-fedora.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
status update: the oz and imagefactory changes were in https://bodhi.fedoraproject.org/updates/FEDORA-2024-b07eef6bc8 , which is stable. outstanding is the koji patch and the pungi-fedora change. the koji patch will be deployed during the koji outage that is coming up in an hour and a half, then once that koji deployment is done, we can change pungi-fedora and hopefully finally resolve this.
https://pagure.io/pungi-fedora/pull-request/1241 should be the last piece of this. well, when we check it works on rawhide then merge it to f40.
Tested out well on Rawhide, F40 PR is now posted. https://pagure.io/pungi-fedora/pull-request/1242
PR is merged, should be fixed in the next compose.
Fix confirmed. -rw-r--r--. 1 adamw adamw 16000000000 Mar 1 03:55 Fedora-Workstation-40-20240301.n.0.aarch64.raw