Server boot x86_64 image https://kojipkgs.fedoraproject.org/compose/branched/Fedora-35-20211001.n.0/compose/Server/x86_64/iso/Fedora-Server-netinst-x86_64-35-20211001.n.0.iso from compose Fedora-35-20211001.n.0 is 735051776 bytes, exceeding the maximum size 734003200. Canonical maximum sizes can be found at https://fedoraproject.org/wiki/Releases/35/Spins and https://fedoraproject.org/wiki/Releases/35/ReleaseBlocking . 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.
Server boot x86_64 image https://kojipkgs.fedoraproject.org/compose/branched/Fedora-35-20211004.n.0/compose/Server/x86_64/iso/Fedora-Server-netinst-x86_64-35-20211004.n.0.iso from compose Fedora-35-20211004.n.0 is 735051776 bytes, exceeding the maximum size 734003200.
Marking as an F35 blocker, which I should have done earlier. (And also someone should figure out why it's not happening automatically)
As of Stephen Smoogens (Server WG) Analyses: As of 2020-10-03 17:50 UTC 658M ./Fedora-Server-netinst-aarch64-35-20211003.n.0.iso 730M ./Fedora-Server-netinst-armhfp-35-20211003.n.0.iso 702M ./Fedora-Server-netinst-x86_64-35-20211003.n.0.iso Once mounted the self reported sizes changed slightly 657M ./fedora_35_aarch64 728M ./fedora_35_armhfp 795M ./fedora The install images (aka ./fedora_35_x86_64/images/install.img) are about the same size du -sch ./fedora_35_image_* 1.6G ./fedora_35_image_aarch64 1.4G ./fedora_35_image_armhfp 1.5G ./fedora_35_image_x86_64 Looking inside the images, I am not sure why the arm and x86_64 are not compressing as well as the aarch64. The x86_64 and aarch64 have equal amounts of already compressed files in .xz format taking up a couple hundred megabytes. At this point, I am guessing the compression amount in the overall images are different OR some vagurie of file layouts is allowing one to be 'more compressible' than the other. Looking in there the biggest user of space is either linux-firmware or the locale archive. I do not see an easy solution to this. If no one else has any ideas, I would say go with upping the limits for the time being.
Oh, I was doing the analysis over in the Everything bug: https://bugzilla.redhat.com/show_bug.cgi?id=2009730 I posted the diff between the two composes where it tipped over the size limit there. I would expect this is the same between Server and Everything.
OK, poked about and found ~30M of firmware files we can cut safely, I think. See https://github.com/weldr/lorax/pull/1175 .
FEDORA-2021-cdb998bce7 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-cdb998bce7
FEDORA-2021-cdb998bce7 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cdb998bce7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cdb998bce7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-cdb998bce7 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
[adamw@xps13k ~]$ curl -I https://kojipkgs.fedoraproject.org/compose/branched/Fedora-35-20211010.n.0/compose/Server/x86_64/iso/Fedora-Server-netinst-x86_64-35-20211010.n.0.iso | grep length % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 646M 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 content-length: 677380096