Bug details: ** https://bugzilla.redhat.com/show_bug.cgi?id=2391723 ** Information from BlockerBugs App:
Commented but haven't voted yet: supakeen
The votes have been last counted at 2026-03-11 15:15 UTC and the last processed comment was #comment-1008047
To learn how to vote, see: https://pagure.io/fedora-qa/blocker-review A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)
BetaBlocker +1
BetaBlocker
FinalBlocker
BetaFE
FinalFE
0Day
PreviousRelease
+1
0
-1
First, do we have a criterion to boot the ISO on 32-bit efi on 64-bit systems or is it best effort? I couldn't find one from a quick scan around the criteria and the one that came closest was:
Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures.
The image-builder produced ISO (currently: only Fedora IoT) that are part of the Fedora compose are have never included shim-ia32 previously.
From a cursory review this was reverted and fixed up in kiwi. It would still need to be reverted in lorax and potentially implemented in image-builder (there's a re-opened PR to introduce this functionality which will likely make it into next weeks release, so before the final freeze)?
I am a weak -1 FinalBlocker, +1 FinalFE; I don't think the setup is that common and many of the artifacts work.
The ones that wouldn't work (that I'm aware of) are the everything/server network installer/dvd installer (produced by lorax) and the Fedora IoT ISO (produced by image-builder).