Fedora 42 Workstation Live ISO (Final? from nightly) manipulates EFI without permission

Ask Fedora
, , , , ,
1

Hi Community,

as already mentioned in another thread, The Live ISOs from Fedora Workstation manipulates the EFI Boot entries:

image
image814×591 1.21 KB

liveuser@localhost-live:~$ efibootmgr
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0002,0001,0000
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00001 	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0){auto_created_boot_option}
Boot0002* Fedora	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/CDROM(1,0x11a2c2,0xf000)/\EFI\fedora\shimx64.efi
liveuser@localhost-live:~$

as you can clearly see, the shimx64.efi creates an EFI Boot entry.
This is inacceptable, a Live ISO should never manipulate the current system.

I have compared the Live ISO with the Silverblue ISO which works correctly (at least on my machines). The Live iso has an extra Fedora directory inside the EFI tree. I can only assume that the BOOTX64 binary detects the shim binary inside the EFI and loads it, causing this problem.

This is the EFI Content from Fedora Silverblue 42 ISO:

Fedora-SB-ostree-x86_64-42/EFI$ tree
.
└── BOOT
    ├── BOOT.conf
    ├── BOOTIA32.EFI
    ├── BOOTX64.EFI
    ├── fonts
    │   └── unicode.pf2
    ├── grub.cfg
    ├── grubia32.efi
    ├── grubx64.efi
    ├── mmia32.efi
    └── mmx64.efi

3 directories, 9 files

And now, the Fedora Workstation 42 Live ISO

Fedora-WS-Live-42/EFI$ tree
.
├── BOOT
│   ├── BOOTIA32.EFI
│   ├── bootx64.efi
│   ├── BOOTX64.EFI
│   ├── fbia32.efi
│   ├── fbx64.efi
│   ├── grub.cfg
│   ├── grubx64.efi
│   └── mmx64.efi
└── fedora
    ├── BOOTIA32.CSV
    ├── BOOTX64.CSV
    ├── gcdia32.efi
    ├── gcdx64.efi
    ├── grub.cfg
    ├── grubia32.efi
    ├── grubx64.efi
    ├── mmia32.efi
    ├── mmx64.efi
    ├── shim.efi
    ├── shimia32.efi
    └── shimx64.efi

3 directories, 20 files

Hope, this helps. If I can contribute anything else, please let me know.

4

Please raise a fedora bug for this so that the developers get to see the problem. See How to file a bug :: Fedora Docs

5

That was quick!
Thank you, i’m on it, mate.

E: Done, I hope I got it right. :smiley:

2 Likes
6

This sounds interesting:

Just want to make sure the working patch makes its way upstream.

Who is upstream of CentoOS? :wink:

7

Thats interesting - but this is only valid for HDD and not for ISO (CDROM/USB)

i did the quick and dirty Test: I deleted all the extra files in /EFI/… , now the tree 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$

looks better now:

liveuser@localhost-live:/run/media/liveuser/8B00-10CD/EFI$ efibootmgr
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0001,0000,0002,0003,0004,0005,0006
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00001 	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0){auto_created_boot_option}
Boot0002* UEFI SanDisk Extreme 4C530000141223121332	PciRoot(0x0)/Pci(0x2,0x1)/Pci(0x0,0x0)/USB(2,0){auto_created_boot_option}
Boot0003* UEFI PXEv4 (MAC:525400B32115)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(525400b32115,1)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0){auto_created_boot_option}
Boot0004* UEFI PXEv6 (MAC:525400B32115)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(525400b32115,1)/IPv6([::],0,Static,[::],[::],64){auto_created_boot_option}
Boot0005* UEFI HTTPv4 (MAC:525400B32115)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(525400b32115,1)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(){auto_created_boot_option}
Boot0006* UEFI HTTPv6 (MAC:525400B32115)	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(525400b32115,1)/IPv6([::],0,Static,[::],[::],64)/Uri(){auto_created_boot_option}
liveuser@localhost-live:/run/media/liveuser/8B00-10CD/EFI$

my conclusion: mistakes happens while authoring/building the ISO

And almost forgot: In 2017 “upsteam” for centos was RHEL, iirc. Centos is dead since 2020/2021 - not to be confused with centos-stream :wink:

1 Like
8

I have just seen the posts at Merely booting some Fedora Linux 42 Live media adds an entry to the UFI boot table and Fedora Magazine.

The workaround is straightforward: remove the unwanted entries from within the Live session or booted from an installed system.

To do so, open a shell and inspect the current configuration by executing efibootmgr. You’ll get an output like this

BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0001,0007,0000
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* Fedora	HD(1,GPT,2bdebcd0-a66a-45a2-8ae8-b88476be27b0,0x800,0x12c000)/\EFI\fedora\shimx64.efi
Boot0007* Fedora	PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/CDROM(1,0x11a2c2,0xf000)/\EFI\fedora\shimx64.efi

Look at the two entries labelled “Fedora”. As you can see, the first enty (Boot0001) points to the right location on the disk. To Verify, compare the displayed UUID with sudo blkid

Output should look like this:

/dev/zram0: LABEL="zram0" UUID="f33f2365-c1e6-4fd2-8260-a9a8cbfcd890" TYPE="swap"
/dev/vda2: UUID="8cfcfdde-cea7-4f68-be9b-a98480cf1c9f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="f230f706-89e9-468b-be27-8adf586e71a6"
/dev/vda3: LABEL="fedora" UUID="2c3070fd-ea74-4b8a-846e-a13e0e51f741" UUID_SUB="b05af1b2-f925-4443-b5dd-61df8531e8f0" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="2e549dfe-4735-4dd4-8000-cf5fe0200f16"
/dev/vda1: UUID="C744-572F" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="2bdebcd0-a66a-45a2-8ae8-b88476be27b0"

Compare the PARTUUID from the EFI System Partition. It should match the UUID from efibootmgr.

Get rid of the other entry, which points to the DVD drive. There are several ways to accomplish this. Use efibootmgr to remove it – this should work in most cases. If that doesn’t work, enter the BIOS and remove the boot entry by hand. The BIOS manufacturer will determine the exact method.To remove the entry using efibootmgr, note the number in the first row of the output. In this example, it is Boot0007. We only need the four digits for removal:
Use the following command to remove the entry: sudo efibootmgr -b 0007 -B

You will then see a new list of boot entries as confirmation:

BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0001,0000
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* Fedora	HD(1,GPT,2bdebcd0-a66a-45a2-8ae8-b88476be27b0,0x800,0x12c000)/\EFI\fedora\shimx64.efi

Reboot. You’re all set.

I’ve tested this on a libvirt KVM.

DISCLAIMER: THIS POST IS PROVIDED “AS IS” WITHOUT ANY WARRANTY.

9

You will also see the text “CDROM” on the entry you want to remove. Also, in the live environment BootCurrent: 0007 indicates the newly added entry you want to remove.

10

Neither of those things is necessarily true. On my test system, when booted from a USB stick, the bogus entry is almost identical to a ‘real’ entry for an installed system:

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

Boot0002 is the bogus one there, but that’s not easy to spot. Also, it won’t necessarily be BootCurrent, it will only be BootCurrent if you rebooted after it was added - i.e. if you have TPM enabled and did not interact with the screen that is shown when TPM is active (so the system rebooted automatically), or you booted again with the affected medium attached. If you just attach an affected medium to a non-TPM system and boot it, the BootCurrent entry will not be the bogus Fedora entry, it will be the firmware’s generic “boot from this medium” entry, which you probably don’t want to delete (the firmware should recreate it if you do, but I don’t know if I would trust that 100%).

11

I wanted to try a dual boot tomorrow and I’m glad I saw this on the Fedora Magazine website as I don’t want to deal with any of this.

Do you think this will be addressed in a future ISO build any time soon? I’d rather wait than take any chances and mess around with EFI settings on my main machine.

Thanks.

1 Like
12

We’re looking into redoing the ISOs somehow, but the details are complicated (we can build ISOs as easy as pie, it’s the process of distributing them that’s complex - we need to decide what to call the updated images, what to do with the originals, how to get them spread across the mirror network, what to put on the download pages, what announcements to make, and so on).

It’s really not a major issue in practical terms, the additional boot entry will not cause any problems in any remotely common situation. If you hadn’t read this entry I would be surprised if you even noticed this had happened, unless you have TPM enabled (lots of people didn’t, which is why we didn’t catch it earlier…)

3 Likes
13

Thanks for the reassurance!

I have several SSDs in my PC and I always install Linux on a separate SSD. That’s how I always do my Windows/Linux dual boots, so I can select my boot option using BIOS boot menu rather than rely on GRUB or whatever. This always worked for me, even if I messed up the Linux disk somehow, Windows boot option was always there.

I never tinkered with EFI entries as I don’t feel competent to do so.

14

that’s why it’s worth to check against with blkid. I think, this is the safest* method to distinguish multiple Fedora entries, even if they look the same.

*But i’m just an average Fedora Silverblue user and could be wrong :smiley:

15

the Windows entry will still be there. I don’t think it’s possible for this bug to remove existing entries, it only creates new ones.

1 Like