Bug 2243034 (F39Serverbootaarch64Oversize) - Fedora 39: Server boot aarch64 image exceeds maximum size
Summary: Fedora 39: Server boot aarch64 image exceeds maximum size
Keywords:
Status: CLOSED WORKSFORME
Alias: F39Serverbootaarch64Oversize
Product: Fedora
Classification: Fedora
Component: distribution
Version: 39
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Aoife Moloney
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: FedoraOversizeTracker F39BetaBlocker F39FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2023-10-10 10:59 UTC by Fedora QA Tools SIG
Modified: 2023-10-19 18:25 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-10-19 18:25:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Fedora QA Tools SIG 2023-10-10 10:59:46 UTC
Server boot aarch64 image https://kojipkgs.fedoraproject.org/compose/branched/Fedora-39-20231010.n.0/compose/Server/aarch64/iso/Fedora-Server-netinst-aarch64-39-20231010.n.0.iso from compose Fedora-39-20231010.n.0 is 740087808 bytes, exceeding the maximum size 734003200. Canonical maximum sizes can be found at https://docs.fedoraproject.org/en-US/releases/f39/spins/ and https://docs.fedoraproject.org/en-US/releases/f39/blocking/ . This check is run by the 'relval' tool, which has its own list of maximum sizes derived from those pages. If the maximum size used for this comparison is wrong, please add a comment and file a bug against relval at https://pagure.io/fedora-qa/relval/issues and it will be corrected. If you believe the canonical maximum size for an image should be changed, please follow the appropriate process before filing a relval bug.

Comment 1 Kamil Páral 2023-10-10 11:10:08 UTC
Marking as a blocker per https://pagure.io/fedora-qa/blocker-review/issue/1396

Comment 2 Adam Williamson 2023-10-12 18:07:33 UTC
Sigh. I hate these bugs. We could argue that we should just bump the aarch64 max size to 1G. The justification for 700M is that it's the size of a CD; I seriously, seriously doubt anyone is writing the aarch64 ISO to a CD...

anyhow, the obvious difference here is that /usr/lib/firmware/qcom is 20M bigger on current nightlies than it was on Beta: it was 36M on Beta, it's 55M on a current nightly. (The Beta image is 690M, the 20231010 image is 706M , so that's pretty much the entire difference, I think). This seems to be partly because there are a couple of new firmwares:

qcom/qcm2290 - 8.5M
qcom/qrb4210 - 7.8M

(total 16.3M)

and partly because some existing ones got bigger:

qcom/sdm845 - went from 8.1M to 9.5M
qcom/sm8250 - went from 6.1M to 7.2M

(total 2.5M added size)

that's most of the increase there.

Per https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE , the new firmwares are all related to "Driver: qcom_q6v5_pas - Qualcomm remoteproc firmware". Peter, I don't suppose we can drop any of this stuff?

Comment 3 Peter Robinson 2023-10-12 18:13:04 UTC
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> tree/WHENCE , the new firmwares are all related to "Driver: qcom_q6v5_pas -
> Qualcomm remoteproc firmware". Peter, I don't suppose we can drop any of
> this stuff?

No, some of the remoteproc pieces are WiFi/WWAN etc. We are not going to the process of splitting out categories of firmware in to micro categories, it's not sustainable.

Comment 4 Kevin Fenzi 2023-10-12 18:21:56 UTC
I'd support moving this limit to 1G...

Comment 5 Peter Robinson 2023-10-12 21:54:36 UTC
Maybe we can also look at why we need to ship compilers (llvm and clang) in the installer that take up large chunks of space (and also why they don't own most of the directories they create).

Comment 6 Adam Williamson 2023-10-12 22:36:47 UTC
We don't ship llvm or clang in the installer environment. We ship LLVM *libraries* in the installer environment because mesa requires them. AFAICS we don't ship any part of clang in the installer environment.

[root@xps13a temp2]# find -name *clang*
[root@xps13a temp2]# find -name *llvm*
./etc/ld.so.conf.d/llvm16-aarch64.conf
./usr/lib64/llvm16
./usr/share/licenses/llvm16-libs
[root@xps13a temp2]# find -name *LLVM*
./usr/lib64/llvm16/lib/LLVMgold.so
./usr/lib64/llvm16/lib/libLLVM-16.0.6.so
./usr/lib64/llvm16/lib/libLLVM-16.so

[root@xps13a temp2]# rpm -q --requires mesa-dri-drivers | grep -i llvm
libLLVM-16.so()(64bit)
libLLVM-16.so(LLVM_16)(64bit)

Comment 7 Fedora QA Tools SIG 2023-10-14 11:35:29 UTC
Server boot aarch64 image https://kojipkgs.fedoraproject.org/compose/branched/Fedora-39-20231014.n.0/compose/Server/aarch64/iso/Fedora-Server-netinst-aarch64-39-20231014.n.0.iso from compose Fedora-39-20231014.n.0 is 740108288 bytes, exceeding the maximum size 734003200.

Comment 8 Fedora QA Tools SIG 2023-10-19 11:02:03 UTC
Server boot aarch64 image https://kojipkgs.fedoraproject.org/compose/branched/Fedora-39-20231019.n.0/compose/Server/aarch64/iso/Fedora-Server-netinst-aarch64-39-20231019.n.0.iso from compose Fedora-39-20231019.n.0 is 740116480 bytes, exceeding the maximum size 734003200.

Comment 9 Adam Williamson 2023-10-19 18:25:40 UTC
not any more, it ain't! (we bumped the max to 1G).


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