Problem
As the Fedora Linux 42 release was halfway out the door, we became aware of an issue with many of the Live images in the release. This issue also affects two of the Fedora 41 live images.
Affected images will add an unexpected entry to the UEFI boot manager list as soon as the medium is booted, even if you do not go on to install Fedora. The new entry is added to the top of the list (so it’s the first priority on boot). The entry is titled “Fedora”, and attempts to boot the Fedora live medium. If the system is TPM-capable, an unexpected “Boot Option Restored” screen will also be displayed, and without user interaction, cause an additional reboot after a five-second timeout before the medium boots.
While this may look alarming, the practical effect is largely benign: it will result in the Live medium being the boot target when inserted into the system and should not affect the boot process as long as the medium is not present.
The Fedora Project apologizes for the issue, and we’d like to emphasize that it’s entirely inadvertent.
Affected live images (Fedora 42):
- Workstation
- KDE Plasma Desktop
- Python Classroom
- Scientific Lab
- LXQt
- Xfce
- SoaS
- Budgie
- MiracleWM
- KDE Mobile
- COSMIC
Unaffected live images (Fedora 42):
- Cinnamon
- LXDE
- MATE-Compiz
- i3
- Sway
- Astronomy
- Comp-Neuro
- Design Suite
- Games
- Security
- Jam-KDE
- Robotics
For Fedora 41, only the MiracleWM and KDE-Mobile live images were affected.
Cause
This is caused by the inadvertent inclusion on the live media of the fallback path self-repair mechanism of the shim UEFI bootloader used by Fedora and many other distributions. This self-repair mechanism is intended to detect when an installed Linux system has been unexpectedly booted via the UEFI ‘fallback path’, and recreate the dedicated UEFI boot manager entry that (presumably) has been inadvertently deleted. This mechanism is triggered any time shim detects that it has been booted via the ‘fallback path’ and is able to locate the executable that implements the self-repair mechanism.
Because non-permanent media like live images always boot from the fallback path, the expectation is that the self-repair executable should be intentionally omitted from such media to prevent this mechanism from kicking in. In Fedora 42 we switched many live images to build with the Kiwi tool, but unfortunately did not notice that this caused the self-repair executable to be included in the images. Because it’s there, it will kick in any time an affected live image is booted in UEFI mode.
Related Issues
Bugzilla report: #2358785
Kiwi report: #2008
Workarounds
How to remove the extra Fedora boot entry
If you see too many “Fedora” entries in your UEFI firmware (mostly commonly still called the “BIOS”) boot selection, e.g. one “Fedora” entry when you have no Fedora installation, or two “Fedora” entries when you have one Fedora installation, and if it bothers you or causes some issues, you can try some of the following:
It is possible that your UEFI firmware will automatically remove the extra “Fedora” entry once the Live image device is not connected. Disconnect the USB drive used for Live image boot/installation, reboot, and see if an extra “Fedora” entry is still present.
If that doesn’t help, on many UEFI systems you should be able to remove the unwanted entry from the firmware UI that you can access by pressing a special key on boot (it varies between manufacturers, but often F1, F2, Delete, Escape or similar).
If needed, you can also remove it from any UEFI-booted Linux environment. First run efibootmgr to display the entries with their numbers, e.g.:
$ efibootmgr
BootCurrent: 0008
Timeout: 1 seconds
BootOrder: 0002,0000,0008
Boot0000* Fedora HD(1,GPT,d69364d1-6506-47bd-87e8-b135b919b717,0x800,0x12c000)/\EFI\FEDORA\SHIMX64.EFI
Boot0002* Fedora HD(2,GPT,edacc107-c81d-406a-bca5-f5d9b433a478,0x468b08,0xf000)/\EFI\FEDORA\shimx64.efi
Boot0008* UEFI: (FAT) KingstonDataTraveler 111 PciRoot(0x0)/Pci(0x1a,0x0)/USB(0,0)/USB(5,0)/HD(2,GPT,edacc107-c81d-406a-bca5-f5d9b433a478,0x468b08,0xf000)0000424f
This shows a system which already had Fedora installed, where we booted from an affected live image and a second Fedora entry was created. Some other entries have been edited out of the output for clarity. By comparing the UUIDs (the number+letter sequences after GPT,) in the Fedora entries with the UUID in the KingstonDataTraveler 111 (example name) entry the firmware created, we can see that Boot0002 is the rogue entry that points to the USB stick. To delete it, we run:
efibootmgr -b 0002 -B
which means “delete the Boot0002 entry”.
Replace 0002 with an actual number from your system.
If you have troubles identifying, which Fedora entry points to your USB stick device, you can also run lsblk -o +label,partuuid:
$ lsblk -o +label,partuuid
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS LABEL PARTUUID
sda 8:0 0 111,8G 0 disk Fedora-WS-Live-42
├─sda1 8:1 0 2,2G 0 part Fedora-WS-Live-42 edacc107-c81d-406a-bca6-f5d9b433a478
└─sda2 8:2 0 30M 0 part BOOT edacc107-c81d-406a-bca5-f5d9b433a478
...
In the LABEL column in the output, you can identify the Live image device, and in the PARTUUID column its matching UUID. Use this UUID to find it in the efibootmgr output.
If you do not have a real Fedora install, you can safely delete any Fedora entry.
How to avoid having the extra Fedora boot entry added
You can avoid triggering this issue at all by installing from a non-live installer image instead (these are not built with Kiwi and not affected by the bug). You can also use one of the non-affected live images, although of course if you want the content of an affected live image, that’s not really an option.
Additional information
This issue does not affect upgrades, so you don’t need to worry about it if you upgrade to Fedora 42 from an earlier Fedora release.
You can also just ignore the issue, and in most cases it will not cause any practical problems.