Bug 2247611 - Fedora 40 aarch64 Workstation disk image is oversize
Summary: Fedora 40 aarch64 Workstation disk image is oversize
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 40
Hardware: aarch64
OS: Unspecified
Target Milestone: ---
Assignee: Aoife Moloney
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker https://discussion.fe...
Depends On:
Blocks: FedoraOversizeTracker BetaBlocker, F40BetaBlocker
TreeView+ depends on / blocked
Reported: 2023-11-02 11:18 UTC by Lukas Brabec
Modified: 2024-03-01 21:15 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2024-03-01 21:15:30 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Fedora Pagure pungi-fedora pull-request 1242 0 None None None 2024-02-27 19:12:26 UTC

Description Lukas Brabec 2023-11-02 11:18:40 UTC
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):

$ 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

$ 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

Comment 1 Fedora Blocker Bugs Application 2023-11-02 11:21:02 UTC
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/

Comment 2 Adam Williamson 2023-11-02 17:00:52 UTC
Also note 17179869184 is exactly 16 power-of-two (not power-of-ten) gigabytes. https://unitconverter.io/gigabytes/bytes/16

Comment 3 Adam Williamson 2023-11-02 18:22:42 UTC
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.

Comment 4 Lukas Brabec 2024-01-10 14:24:05 UTC
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.

Comment 5 Adam Williamson 2024-01-10 16:32:21 UTC
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.

Comment 6 Adam Williamson 2024-01-22 18:08:31 UTC
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 .

Comment 7 Adam Williamson 2024-01-23 17:26:25 UTC
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.

Comment 8 Adam Williamson 2024-01-23 17:29:59 UTC
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.

Comment 9 Adam Williamson 2024-01-23 17:46:34 UTC
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...

Comment 10 Adam Williamson 2024-01-23 19:55:07 UTC
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).

Comment 11 Peter Robinson 2024-01-23 21:20:36 UTC
(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.

Comment 12 Adam Williamson 2024-01-25 22:34:57 UTC
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:


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.

Comment 13 Adam Williamson 2024-01-26 01:28:34 UTC
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.

Comment 14 Adam Williamson 2024-01-30 00:12:08 UTC
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.

Comment 15 Aoife Moloney 2024-02-15 23:03:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle.
Changing version to 40.

Comment 16 Adam Williamson 2024-02-21 19:28:11 UTC
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.

Comment 17 Adam Williamson 2024-02-23 01:29:30 UTC
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.

Comment 18 Adam Williamson 2024-02-27 19:12:26 UTC
Tested out well on Rawhide, F40 PR is now posted. https://pagure.io/pungi-fedora/pull-request/1242

Comment 19 Adam Williamson 2024-02-28 03:27:18 UTC
PR is merged, should be fixed in the next compose.

Comment 20 Adam Williamson 2024-03-01 21:15:30 UTC
Fix confirmed.

-rw-r--r--. 1 adamw adamw 16000000000 Mar  1 03:55 Fedora-Workstation-40-20240301.n.0.aarch64.raw

Note You need to log in before you can comment on or make changes to this bug.