Bug 2358785
| Summary: | Fedora 42 kiwi-built live images contain shim fallback executable, so they create 'Fedora' EFI boot manager entries on boot, and show a 'Boot Option Restored' screen if TPM is enabled | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David <truster> | ||||
| Component: | kiwi | Assignee: | Neal Gompa <ngompa13> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 42 | CC: | agurenko, alexvillacislasso, anaconda-maint, awilliam, bcl, bughunter2, davide, fmartine, kparal, lsandova, marcus-schaefer, massi.ergosum, mcatanza, michel, mjg, mystyle48, ngompa13, patrick.lang, pjones, ppywlkiqletw, travier | ||||
| Target Milestone: | --- | Keywords: | CommonBugs | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | https://discussion.fedoraproject.org/t/common-issue/148774 | ||||||
| Fixed In Version: | kiwi-10.2.18-1.fc42 kiwi-10.2.18-1.fc41 kiwi-10.2.18-1.el10_1 kiwi-10.2.18-1.fc40 kiwi-10.2.18-1.el10_0 kiwi-10.2.18-1.el9 | Doc Type: | --- | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2025-04-29 20:39:59 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 2324223 | ||||||
| Attachments: |
|
||||||
|
Description
David
2025-04-10 08:07:30 UTC
It also happens on the XFCE shim beta version, but without the message. Thus the proper component is probably whatever program is used to create the iso files and not the shim component per se. It is actually the existence of EFI/BOOT/fbx64.efi which causes this. yeah, a quick and dirty test in a KVM reveals removing those extra-file will fix the issue.
my EFI tree in the "patched" ISO now looks like this:
liveuser@localhost-live:/run/media/liveuser/8B00-10CD/EFI$ tree
.
└── BOOT
├── BOOTIA32.EFI
├── BOOTX64.EFI
├── grub.cfg
├── grubx64.efi
└── mmx64.efi
2 directories, 5 files
liveuser@localhost-live:/run/media/liveuser/8B00-10CD/EFI$
Yeah, it looks like someone wrote their own stuff from scratch to build the boot image instead of using the existing lorax templates, and they put fbx64.efi where it doesn't belong. I don't think there are actually any security implications here. The lives are built with kiwi these days. Not sure if this is an issue in the tool or the templates, but either way the bug needs to go to Neal, and assigning it to kiwi will do that. I guess there needs to be some kind of filtering mechanism available in kiwi for what stuff goes into an ISO's boot volume. Right now, one does not exist. I confirmed the behavior on my Lenovo X13, dual booting with Windows 11. I was concerned adding the extra boot entry could break the TPM measurements used by Windows Bitlocker, but in my setup it was fine. I do have a useless "Fedora" boot entry left over in the EFI boot settings that references the USB drive. This is confusing because I already have another "Fedora" boot entry which is a second partition on my SSD. worth noting, for some reason, this doesn't always happen. I have a test box which I run various test installs on around release time, I did multiple UEFI boots of workstation live from a USB key and never saw this shim screen. this looks like the magic which is supposed to 'recover' installed Fedora UEFI systems if we hit fallback path boot on the disk Fedora is installed to, right, Peter? Any idea what might be causing that to kick in, but only sometimes? Filed an upstream kiwi bug requesting a filter mechanism: https://github.com/OSInside/kiwi/issues/2777 Hmm. Poking through the code myself - https://github.com/rhboot/shim/blob/main/fallback.c - one thing does stand out: I think we only get the interactive blue screen if TPM is enabled. But we hit the boot manager editing codepaths whether or not TPM is there, I think. The blue screen stuff is around line 1136, after `#ifndef FALLBACK_NONINTERACTIVE`, which only happens if we find TPM at line 1126. But the menu editing happens in `update_boot_order`, which is called by `find_boot_options`, which happens a bit earlier, line 1119. There are various early bailouts in update_boot_order and find_boot_options which *could* prevent the edit happening, I guess, but the intent seems to be that it should happen any time we wind up in this executable at all. It definitely seems pretty clear that we do *not* want the EFI executable built from fallback.c to be on live media at all, and we definitely don't want it to be the thing that gets booted by default. The 'thing that gets booted by default' should be EFI/BOOT/BOOTX64.EFI (on an x86_64 system), which on the live image isn't the same thing as fbx64.efi , at least they're different sizes. I've forgotten exactly how that's set up. Is BOOTX64.EFI just a slightly bigger version of fbx64.efi ? Does it *run* fbx64.efi ? I don't remember. yeah, now I know what I'm looking for, I can reproduce this on a standard virt-manager UEFI VM, and on my test box. Both get extra "Fedora" EFI boot manager entries just from booting an F42 Workstation live, but not the blue screen (because they don't have TPM). I had actually noticed multiple 'Fedora' boot manager entries on my test box, but it has a pretty screwy UEFI firmware that duplicates things sometimes, and two installs of Fedora on hard disks, so I kinda assumed it was just some fallout from that mess, not something F42 lives were causing :( Ah. https://github.com/rhboot/shim/blob/main/README.fallback explains how this works. Basically, BOOTX64.EFI is shim; it checks whether it's been started 'normally' or via fallback path. If it was started via the fallback path, and the fallback executable is present, it calls the fallback executable. otherwise, it runs grub. (AIUI). Pull request for fixing this: https://github.com/OSInside/kiwi/pull/2778 Common Issue description: https://discussion.fedoraproject.org/t/common-issue/148774 FEDORA-EPEL-2025-32f0fcbf72 (kiwi-10.2.16-4.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-32f0fcbf72 FEDORA-EPEL-2025-87fbc68a94 (kiwi-10.2.16-4.el10_1) has been submitted as an update to Fedora EPEL 10.1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-87fbc68a94 FEDORA-2025-eb02bf6686 (kiwi-10.2.16-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-eb02bf6686 FEDORA-2025-27dbfcb5f9 (kiwi-10.2.16-4.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2025-27dbfcb5f9 FEDORA-2025-03e4e6c0cf (kiwi-10.2.16-4.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2025-87fbc68a94 (kiwi-10.2.16-4.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2025-27dbfcb5f9 (kiwi-10.2.16-4.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2025-656865fea1 (kiwi-10.2.16-4.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2025-eb02bf6686 (kiwi-10.2.16-4.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2025-32f0fcbf72 (kiwi-10.2.16-4.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2025-abc2389dd4 (kiwi-10.2.18-1.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-abc2389dd4 FEDORA-2025-b9ae42c8d7 (kiwi-10.2.18-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2025-b9ae42c8d7 FEDORA-EPEL-2025-1516ba47ea (kiwi-10.2.18-1.el10_1) has been submitted as an update to Fedora EPEL 10.1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-1516ba47ea FEDORA-2025-caba97efbd (kiwi-10.2.18-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-caba97efbd FEDORA-EPEL-2025-a6bd816644 (kiwi-10.2.18-1.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-a6bd816644 FEDORA-2025-7cf125b833 (kiwi-10.2.18-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7cf125b833 FEDORA-2025-caba97efbd (kiwi-10.2.18-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2025-7cf125b833 (kiwi-10.2.18-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2025-1516ba47ea (kiwi-10.2.18-1.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2025-b9ae42c8d7 (kiwi-10.2.18-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2025-a6bd816644 (kiwi-10.2.18-1.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2025-abc2389dd4 (kiwi-10.2.18-1.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. Fedora 43 just released. I have checked the ISO filesystem and it looks like the issue could still be present on Fedora 43 Workstation due to the extra files: ls -lR Fedora-WS-Live-43/EFI/ Fedora-WS-Live-43/EFI/: total 4 drwx------. 1 alex alex 2048 oct 22 23:09 BOOT drwx------. 1 alex alex 2048 oct 22 23:09 fedora Fedora-WS-Live-43/EFI/BOOT: total 11866 -rwx------. 1 alex alex 747681 oct 22 23:09 bootia32.efi -rwx------. 1 alex alex 747681 mar 18 2024 BOOTIA32.EFI -rwx------. 1 alex alex 949424 oct 22 23:09 bootx64.efi -rwx------. 1 alex alex 949424 mar 18 2024 BOOTX64.EFI -rwx------. 1 alex alex 70360 mar 18 2024 fbia32.efi -rwx------. 1 alex alex 87816 mar 18 2024 fbx64.efi -rw-rw-r--. 1 alex alex 141 oct 22 23:09 grub.cfg -rwx------. 1 alex alex 3026240 oct 22 23:09 grubia32.efi -rwx------. 1 alex alex 4046144 oct 22 23:09 grubx64.efi -rwx------. 1 alex alex 673992 oct 22 23:09 mmia32.efi -rwx------. 1 alex alex 848080 oct 22 23:09 mmx64.efi Fedora-WS-Live-43/EFI/fedora: total 17888 -rwx------. 1 alex alex 112 mar 18 2024 BOOTIA32.CSV -rwx------. 1 alex alex 110 mar 18 2024 BOOTX64.CSV -rwx------. 1 alex alex 3026240 ago 5 19:00 gcdia32.efi -rwx------. 1 alex alex 4046144 ago 5 19:00 gcdx64.efi -rw-rw-r--. 1 alex alex 141 oct 22 23:09 grub.cfg -rwx------. 1 alex alex 3026240 ago 5 19:00 grubia32.efi -rwx------. 1 alex alex 4046144 ago 5 19:00 grubx64.efi -rwx------. 1 alex alex 673992 mar 18 2024 mmia32.efi -rwx------. 1 alex alex 848080 mar 18 2024 mmx64.efi -rwx------. 1 alex alex 949424 mar 18 2024 shim.efi -rwx------. 1 alex alex 747681 mar 18 2024 shimia32.efi -rwx------. 1 alex alex 949424 mar 18 2024 shimx64.efi See discussion at https://pagure.io/fedora-kiwi-descriptions/pull-request/177#comment-218232 . That's not the right place to look. After this little fiasco I did add an openQA test to check we don't break this again, and it passed for the F43 gold candidate - https://openqa.fedoraproject.org/tests/3899326 - so I'm pretty sure this is OK. Although, Neal, looks like something's up with the duplicated upper-case/lower-case files - can that be cleaned up? (In reply to Adam Williamson from comment #39) > Although, Neal, looks like something's up with the duplicated > upper-case/lower-case files - can that be cleaned up? That's not from me, that's from the RPMs themselves. This bug is still occurring for me with Fedora 43 KDE. Two "Fedora" boot entries appear in my system's UEFI boot menu after installation. That's not what this bug is about, though. This bug was about live images creating "Fedora" entries on systems that did not previously have them, *without* any installation happening. This problem kept occurring on an old Minix Neo Z83-4 (Intel Atom x5-Z8350, 4 GB DDR3 RAM) mini PC here. While the 'Fedora' boot option is shown in the 'efibootmgr -v' output, I was unable to set the first boot option to 'Fedora' using the UEFI firmware setup (it was simply not listed there). Also, the system always restores the 'Android-IA' (Android on Intel Architecture) boot option and prefers to boot that instead. Even when I modified the boot order using 'efibootmgr', Fedora kept showing the 'Boot Option Restored' blue screen, as the UEFI firmware seemed to ignore the modified boot order and simply booted the 'Android-IA' boot option again. Also, even if I deleted the 'Android-IA' boot option using 'efibootmgr', the UEFI firmware restores the 'Android-IA' boot option. The 'Android-IA' boot option boots the 'EFI\BOOT\BOOTX64.EFI' file, which by default is identical to the 'shimx64.efi' binary which shows the 'Boot Option Restored' message. My workaround: $ cp -v /boot/efi/EFI/fedora/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI I copied the regular (non-shim) grubx64.efi binary to the fallback path. Afterwards, the system booted Fedora normally and didn't show the 'Boot Option Restored' screen. |