The two last builds of `shim` (shim-15.8-4, shim-15.8-5) both no longer include the `shim-ia32` subpackage, these have been tagged into rawhide. I'm wondering if this is intentional. Fedora IoT Installer builds are currently failing in rawhide as it explicitly tries to include the package. See for example root.log in this build: https://koji.fedoraproject.org/koji/taskinfo?taskID=136501539 The dependency on it can be removed but I'd like to figure out if this is meant to happen or accidental :) Reproducible: Always
The same question was raised on bodhi, see comment https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a839fa19e#comment-4278695
FYI https://github.com/fedora-silverblue/issue-tracker/issues/671
I see in bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a839fa19e#comment-4278695 That pjones writes: "I honestly don't think anyone has been using it - or that it has even worked in several years." Neither of those statements are true. 1. "I honestly don't think anyone has been using it" That is not true, I still have at least a dozen x86_64 devices which boot with a 32 bit UEFI. And as the person who has been doing most of the kernel side hw-enablement for Intel Bay Trail systems which typically ship with a 32 bit UEFI firmware I can tell you that I still regularly get inquires, bug reports and regression reports about these systems. These systems not only include many smaller laptops (the last generation where 10" laptops where common which some people like) but also various top-set-boxes / NUC style devices used for things like pihole setups and home assistant setups. IOW quite a few people are still using this. 2. "or that it has even worked in several years." Again this is also simply not true. I just booted a F43 workstation liveusb on an Asus T100TA (which still is a very popular mini laptop) which has 32 bit UEFI and it boots just fine. So shim-ia32 was working fine until it was disabled. Please re-enable the shim-ia32 builds and after that we will need to undo all the changes to the various x86_64 compose which were made because of this being disabled out of the blue. If you insist on disabling shim-ia32 builds for F44 then IMHO you MUST create a change proposal for F44 for this as this will drop support for a whole bunch of hardware which still works fine in F43.
I was about to start working on a pull-request to re-enable the shim-ia32 builds, but while preparing this I noticed that shim-16.1 was just build in koji and that that includes a shim-ia32 build again, thank you. Judging on the changelog, the 16.1 build seems to be based on the 15.8-3 build though. Where as the problems with the missing shim-ia32 were introduced in 15.8-4. I assume the changes in the 15.8-4 / 15.8-5 builds to prepare for https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1 will get ported to the 16.1 builds soon? When porting those changes please take care to not re-introduce the problem of the missing shim-ia32 again, as explained in comment 3 we really still need shim-ia32.
After taking a quick look at the changes in shim-15.8-4 I did not see how those could account for shim-ia32 no longer being build. So I dived in a bit deeper and this is controlled by the value of the rpm-build _efi_has_alt_arch global. Which is defined by efi-srpm-macros. Peter has already fixed efi-srpm-macros no longer setting _efi_has_alt_arch to 1 on x86_64 in: efi-rpm-macros-6-5.fc43 efi-rpm-macros-6-5.fc44 Peter, thank you for fixing this! Note the efi-rpm-macros-6-5.fc43 build really _must_ be submitted to bodhi as an update so that any future shim updates for f43 will not have shim-ia32 missing, can one of you please take care of this ? I suspect that the just done shim-16.1 build is mainly for testing purposes and it may be a while before this actually hits the rawhide repo / buildroot. Can we perhaps get a shim-15.8-6 rawhide build (just a release bump + rebuild) to get shim-ia32 added back to the repos / buildroot so that we can start working on undoing the changes which were done to the composes to deal with shim-ia32 missing ?
Hans, when the package is available again in rawhide a revert of this commit: https://pagure.io/fedora-kiwi-descriptions/c/01d839d633816b2f9804c64331379d4051a15805?branch=rawhide is likely sufficient to re-enable 32-bit efi in built media.
Hi @hans, yes you're right that the rawhide build needs to be redone so that shim once again gets unpacked to /usr/lib/... and only later gets copied to /boot/efi That change is not related to the missing ia32 efi, as you noted, so we'll try to get everything right this time. ;) Does any other shim (besides rawhide) need rebuilding/repackaging?
Hi Marta, AFAICT Fedora 43 still has shim-15.8-3 which is not affected. Note Peter Jones is working on an update to shim 16.1 so you may want to coordinate doing a new 15.8-x build for rawhide with Peter. The 16.1 builds are already build against the fixed efi-rpm-macros so they do have shim-ia32 available, but they lack your changes for https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1 . I assume this is intentional since 16.1 will likely also go out as an update for Fedora 42 and Fedora 43. So I expect Peter when things are ready to first push a 16.1 build _without_ the BootLoaderUpdatesPhase1 changes to Fedora 42 and Fedora 43 and then a newer build with the BootLoaderUpdatesPhase1 changes can be done for rawhide only. But again please coordinate this with Peter. Thank you for looking into this.
Hi Hans, No worries: no shim without Peter. ;) I just wanted to have all the information before we make a plan for what needs to be done to fix everything... hopefully in one go!
It looks like dropping the ia32 builds was reverted with https://src.fedoraproject.org/rpms/efi-rpm-macros/c/ce8d82dfd6a69dc042794e6626e95f09d33027a9?branch=rawhide & https://src.fedoraproject.org/rpms/efi-rpm-macros/c/3b8dc74cc92df1da2241d838f002c0b77924cc2e?branch=rawhide and shim rebuilt in F43 with https://src.fedoraproject.org/rpms/shim/c/deb26f49588fd3e498134fb250b0d21396de49d9?branch=f43 as it potentially breaks support for a lot of hardware: https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a839fa19e#comment-4391919. I also see the ia32 build in the latest rawhide build https://koji.fedoraproject.org/koji/buildinfo?buildID=2932715. So this is mostly done. However we now need to revert all the changes that we made everywhere to drop shim-ia32 (comps, installer/lorax/kiwi, etc?). I'm submitting this as a F44 release blocker.
Proposed as a Blocker and Freeze Exception for 44-final by Fedora user siosm using the blocker tracking app because: shim-ia32 is needed to keep a lot existing supported hardware working with Fedora 44. See bug comment #10 for details.
Comps: https://pagure.io/fedora-comps/pull-request/1256
Other PRs that likely need to be reverted: - https://github.com/weldr/lorax/pull/1489 - https://github.com/osbuild/images/pull/1862
Looks like this was already reverted for kiwi descriptions: https://pagure.io/fedora-kiwi-descriptions/pull-request/237
For Atomic Desktops: - https://pagure.io/workstation-ostree-config/pull-request/737 - https://pagure.io/workstation-ostree-config/pull-request/738
For Fedora CoreOS, it looks like we haven't included it at all since the begining. Similarly for Fedora IoT: https://pagure.io/fedora-iot/ostree/blob/main/f/fedora-iot-base.yaml#_191 For Fedora bootc I'm not sure if that gets included or not: https://gitlab.com/fedora/bootc/base-images/-/blob/main/minimal/bootupd.yaml?ref_type=heads#L23
For bootc images it's also important to know if bootupd actually copies these binaries into the ESP if they are available on the system; or if it doesn't :)
I vaguely remember discussions/work about this but not the exact state of support: https://github.com/coreos/bootupd/issues?q=sort%3Aupdated-desc%20shim-ia32.
CC @hhei
I've reverted the change in Lorax for rawhide and f44 - https://bodhi.fedoraproject.org/updates/FEDORA-2026-ea1a86a8eb
(In reply to Simon de Vlieger from comment #17) > For bootc images it's also important to know if bootupd actually copies > these binaries into the ESP if they are available on the system; or if it > doesn't :) Yes, it does. I think it is because shim-ia32 has files under /usr/lib/efi/shim See test results: $ cat Containerfile FROM quay.io/fedora/fedora-bootc:44 RUN dnf install -y shim-ia32 $ sudo podman build -t bootc-shim . Build qcow2 disk $ sudo podman run \ --rm \ -it \ --privileged \ --pull=newer \ --security-opt label=type:unconfined_t \ -v ./config.toml:/config.toml:ro \ -v $(pwd)/output:/output \ -v /var/lib/containers/storage:/var/lib/containers/storage \ quay.io/centos-bootc/bootc-image-builder:latest \ --type qcow2 \ --rootfs xfs \ localhost/bootc-shim sudo virt-install \ --name fedora-bootc \ --cpu host-model \ --vcpus 4 \ --memory 4096 \ --import --disk ./output/qcow2/disk.qcow2,format=qcow2 \ --os-variant fedora-eln --nographics --boot uefi,menu=on,useserial=on After booted, check the ia32 files are installed to /boot/efi [coreos@fedora ~]$ sudo su bash-5.3# ls -al /boot/efi/EFI/*/* -rwx------. 1 root root 806195 Jan 1 1980 /boot/efi/EFI/BOOT/BOOTIA32.EFI -rwx------. 1 root root 1026520 Jan 1 1980 /boot/efi/EFI/BOOT/BOOTX64.EFI -rwx------. 1 root root 91576 Jan 1 1980 /boot/efi/EFI/BOOT/fbia32.efi -rwx------. 1 root root 119280 Jan 1 1980 /boot/efi/EFI/BOOT/fbx64.efi -rwx------. 1 root root 112 Jan 1 1980 /boot/efi/EFI/fedora/BOOTIA32.CSV -rwx------. 1 root root 110 Jan 1 1980 /boot/efi/EFI/fedora/BOOTX64.CSV -rwx------. 1 root root 53 Mar 12 01:30 /boot/efi/EFI/fedora/bootuuid.cfg -rwx------. 1 root root 657 Mar 12 01:30 /boot/efi/EFI/fedora/grub.cfg -rwx------. 1 root root 3079488 Jan 1 1980 /boot/efi/EFI/fedora/grubia32.efi -rwx------. 1 root root 4144448 Jan 1 1980 /boot/efi/EFI/fedora/grubx64.efi -rwx------. 1 root root 695016 Jan 1 1980 /boot/efi/EFI/fedora/mmia32.efi -rwx------. 1 root root 874352 Jan 1 1980 /boot/efi/EFI/fedora/mmx64.efi -rwx------. 1 root root 1026520 Jan 1 1980 /boot/efi/EFI/fedora/shim.efi -rwx------. 1 root root 806195 Jan 1 1980 /boot/efi/EFI/fedora/shimia32.efi -rwx------. 1 root root 1026520 Jan 1 1980 /boot/efi/EFI/fedora/shimx64.efi bash-5.3# rpm -ql shim-ia32 | grep usr /usr/lib/efi/shim/16.1-5/EFI/BOOT/BOOTIA32.EFI /usr/lib/efi/shim/16.1-5/EFI/BOOT/fbia32.efi /usr/lib/efi/shim/16.1-5/EFI/fedora/BOOTIA32.CSV /usr/lib/efi/shim/16.1-5/EFI/fedora/mmia32.efi /usr/lib/efi/shim/16.1-5/EFI/fedora/shimia32.efi bash-5.3# rpm -ql shim-x64 | grep usr /usr/lib/efi/shim/16.1-5/EFI/BOOT/BOOTX64.EFI /usr/lib/efi/shim/16.1-5/EFI/BOOT/fbx64.efi /usr/lib/efi/shim/16.1-5/EFI/fedora/BOOTX64.CSV /usr/lib/efi/shim/16.1-5/EFI/fedora/mmx64.efi /usr/lib/efi/shim/16.1-5/EFI/fedora/shim.efi /usr/lib/efi/shim/16.1-5/EFI/fedora/shimx64.efi
@hhei Awesome. Should the base images for bootc start including the 32-bit binaries by default? The next release of image-builder (53, will release today or monday) will also address the issue there.
(In reply to Simon de Vlieger from comment #22) > Should the base images for bootc start including > the 32-bit binaries by default? Not sure, I test it using Containerfile that installs shim-ia32. @traiver do you have any context for this?
+4 FE in https://pagure.io/fedora-qa/blocker-review/issue/2075 , marking accepted (blocker vote still open).
needinfo'ing travier as there was a typo in comment #23 so it didn't work.
FEDORA-2026-ea1a86a8eb (lorax-44.6-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-ea1a86a8eb
FEDORA-2026-94622507b1 (image-builder-53-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-94622507b1
AGREED AcceptedFinalBlocker Discussed at the 2026-03-16 (blocker / freeze exception) review meeting: This is accepted as a violation of "All release-blocking images must boot in their supported configurations" in the case of x86_64 systems with 32-bit UEFI firmwares. Our subjective decision was that this is a significant enough class of systems to constitute a release blocking bug. Note we accept this only in the context of 'making an effort to support such systems', as the fix is relatively straightforward. We don't necessarily intend to establish a precedent that any kind of bug in this unusual path becomes a blocker; one that required more work by the developers may not reach the bar. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-03-16/f44-blocker-review.2026-03-16-16.01.log.txt
FEDORA-2026-94622507b1 (image-builder-53-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
> (In reply to Simon de Vlieger from comment #22) > > Should the base images for bootc start including the 32-bit binaries by default? > (In reply to HuijingHei from comment #23) > Not sure, I test it using Containerfile that installs shim-ia32. At this point in the cycle for F44, I don't think we should introduce more changes beyond reverting the removals that we had done a few months back when shim-ia32 was dropped. I've created an issue in the bootc tracker for additional work specific to the Fedora bootc images: https://gitlab.com/fedora/bootc/tracker/-/work_items/86 --- As Hans wrote in https://bugzilla.redhat.com/show_bug.cgi?id=2391723#c3, if we want to drop shim-ia32 in a future release then this should go through the Fedora Change process.
Looks like we only need https://bodhi.fedoraproject.org/updates/FEDORA-2026-ea1a86a8eb to land and all images rebuilt with it.