Description of problem: When I try to perform this test case [1] and I select *the second drive* for installation, the resulting system doesn't boot. In my case (virt-manager VM), the UEFI bootloader entry is created during installation, but points to the first drive, not the second one. After reboot, the edk2-ovmf UEFI implementation immediately removes the invalid entry (I assume), and so I see no "Fedora" UEFI boot options and the system chooses a different device instead (the virtual DVD drive, in my case). Initially I wanted to report this against anaconda, but anaconda seems to be calling efibootmgr correctly. But efibootmgr seems to be creating the boot entries incorrectly - always pointing to the first drive. This is the disk layout: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 2.2G 1 loop /run/rootfsbase sr0 11:0 1 2.6G 0 rom /run/initramfs/live zram0 251:0 0 5.6G 0 disk [SWAP] vda 253:0 0 20G 0 disk └─vda1 253:1 0 1.9G 0 part vdb 253:16 0 25G 0 disk ├─vdb1 253:17 0 600M 0 part /mnt/sysroot/boot/efi │ /mnt/sysimage/boot/efi ├─vdb2 253:18 0 2G 0 part /mnt/sysroot/boot │ /mnt/sysimage/boot └─vdb3 253:19 0 22.4G 0 part /mnt/sysroot/home /mnt/sysroot /mnt/sysimage/home /mnt/sysimage These are partition IDs: /dev/sr0: BLOCK_SIZE="2048" UUID="2025-10-16-05-32-45-00" LABEL="Fedora-WS-Live-43" TYPE="iso9660" PTTYPE="PMBR" /dev/vdb2: UUID="32e9f1c5-109d-42fc-888b-a9e9fa7bc997" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="12d70400-de8e-4e80-a7dd-29cc52da1327" /dev/vdb3: LABEL="fedora" UUID="783e9584-75b5-44a8-87b7-4c779de15cc5" UUID_SUB="cb1485f4-bd0c-4921-a02c-ec3bcf0262d9" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="486a1fc0-d0c2-4a09-9745-b9bf1fa2d2fc" /dev/vdb1: UUID="1428-4B93" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="c766fb61-5a86-43b0-9d8e-f489a7df433a" /dev/loop0: UUID="91a11d9d-fb85-4402-a086-ec3938519ac3" BLOCK_SIZE="4096" TYPE="erofs" /dev/zram0: LABEL="zram0" UUID="83ebbc3e-30c7-47de-82c1-ec4821395970" TYPE="swap" /dev/vda1: LABEL="data" UUID="0fc16528-75e8-43d3-a553-4296f3afe9fa" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="f9d6509a-c1a2-4952-9663-e532e8739192" Anaconda called this (reading from storage.log): 2656:INFO:program:Running in chroot '/mnt/sysroot'... efibootmgr -c -w -L Fedora -d /dev/vdb -p 1 -l \EFI\fedora\shimx64.efi However, the "Fedora" boot option points to HD(1) instead of HD(2) (I believe UEFI indexes disks from 1): BootCurrent: 0003 Timeout: 3 seconds BootOrder: 0009,0002,0000,0001,0003,0004,0005,0006,0007,0008 Boot0000* BootManagerMenuApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(eec25bdc-67f2-4d95-b1d5-f81b2039d11d) Boot0001* EFI Firmware Setup FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331) Boot0002* UEFI Misc Device PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0){auto_created_boot_option} Boot0003* UEFI QEMU DVD-ROM QM00001 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0){auto_created_boot_option} Boot0004* UEFI Misc Device 2 PciRoot(0x0)/Pci(0x2,0x5)/Pci(0x0,0x0){auto_created_boot_option} Boot0005* UEFI PXEv4 (MAC:5254000AF0F3) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254000af0f3,1)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0){auto_created_boot_option} Boot0006* UEFI PXEv6 (MAC:5254000AF0F3) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254000af0f3,1)/IPv6([::],0,Static,[::],[::],64){auto_created_boot_option} Boot0007* UEFI HTTPv4 (MAC:5254000AF0F3) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254000af0f3,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} Boot0008* UEFI HTTPv6 (MAC:5254000AF0F3) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254000af0f3,1)/IPv6([::],0,Static,[::],[::],64)/Uri(){auto_created_boot_option} Boot0009* Fedora HD(1,GPT,c766fb61-5a86-43b0-9d8e-f489a7df433a,0x800,0x12c000)/\EFI\fedora\shimx64.efi Now see what happens when I try to test efibootmgr by creating two boot entries, one pointing to /dev/vda1 and the second pointing to /dev/vdb1: $ sudo efibootmgr -c -w -L TESTVDA -d /dev/vda -p 1 -l '\EFI\fedora\shimx64.efi' ... $ sudo efibootmgr -c -w -L TESTVDB -d /dev/vdb -p 1 -l '\EFI\fedora\shimx64.efi' BootCurrent: 0003 Timeout: 3 seconds BootOrder: 000B,000A,0009,0002,0000,0001,0003,0004,0005,0006,0007,0008 Boot0000* BootManagerMenuApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(eec25bdc-67f2-4d95-b1d5-f81b2039d11d) Boot0001* EFI Firmware Setup FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331) Boot0002* UEFI Misc Device PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0){auto_created_boot_option} Boot0003* UEFI QEMU DVD-ROM QM00001 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0){auto_created_boot_option} Boot0004* UEFI Misc Device 2 PciRoot(0x0)/Pci(0x2,0x5)/Pci(0x0,0x0){auto_created_boot_option} Boot0005* UEFI PXEv4 (MAC:5254000AF0F3) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254000af0f3,1)/IPv4(0.0.0.0,0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0){auto_created_boot_option} Boot0006* UEFI PXEv6 (MAC:5254000AF0F3) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254000af0f3,1)/IPv6([::],0,Static,[::],[::],64){auto_created_boot_option} Boot0007* UEFI HTTPv4 (MAC:5254000AF0F3) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254000af0f3,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} Boot0008* UEFI HTTPv6 (MAC:5254000AF0F3) PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254000af0f3,1)/IPv6([::],0,Static,[::],[::],64)/Uri(){auto_created_boot_option} Boot0009* Fedora HD(1,GPT,c766fb61-5a86-43b0-9d8e-f489a7df433a,0x800,0x12c000)/\EFI\fedora\shimx64.efi Boot000A* TESTVDA HD(1,GPT,f9d6509a-c1a2-4952-9663-e532e8739192,0x800,0x3c6800)/\EFI\fedora\shimx64.efi Boot000B* TESTVDB HD(1,GPT,c766fb61-5a86-43b0-9d8e-f489a7df433a,0x800,0x12c000)/\EFI\fedora\shimx64.efi They both point to HD(1)! (the PARTUUIDs are correct) So this seems to be a problem in efibootmgr or the UEFI implementation in edk2-ovmf. The result is that installations to a second (or possibly later) drive don't boot. I'm attaching full anaconda logs. [1] https://fedoraproject.org/wiki/QA:Testcase_partitioning_webui_guided_multi_select Version-Release number of selected component (if applicable): VM guest: Fedora-Workstation-Live-43-1.4.x86_64.iso efibootmgr-18-10.fc43.x86_64 anaconda-core-43.44-3.fc43.x86_64 VM host: edk2-ovmf-20250812-21.fc43.noarch libvirt-11.6.0-1.fc43.x86_64 How reproducible: always Steps to Reproduce: 1. Either create a completely fresh UEFI VM in virt-manager, or make sure to removing UEFI vars for an existing one before starting it, to remove any existing "Fedora" entries: $ sudo rm -v /var/lib/libvirt/qemu/nvram/<VM NAME>_VARS.qcow2 2. Make sure the VM has two disks attached 3. Boot F43 Workstation Live image 4. Before starting Anaconda, create /dev/vda1 (ext4) as your "data" partition 5. Start Anaconda, pick /dev/vdb as your install target, and perform a default installation using the whole disk 6. After exiting Anaconda, look at `efibootmgr` output, whether it points to the correct drive - it should be HD(2), but it's HD(1) instead 7. Reboot and hit Esc, see that there's no "Fedora" boot menu in the boot list. If reboot again and don't hit Esc, it will boots from the virtual DVD drive again (most probably). Actual results: "Fedora" entry is always created pointing to /dev/vda Expected results: "Fedora" entry is created pointing to the requested disk device
Created attachment 2110241 [details] anaconda.log
Created attachment 2110242 [details] anaconda-webui.log
Created attachment 2110243 [details] dbus.log
Created attachment 2110244 [details] journal.log
Created attachment 2110245 [details] packaging.log
Created attachment 2110246 [details] program.log
Created attachment 2110247 [details] storage.log
Created attachment 2110248 [details] rpm-qa.txt
Created attachment 2110249 [details] libvirt VM dumpxml
Proposing as a Final blocker: https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Disk_layouts https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Bootloader_disk_selection In this case, Fedora installations to a second drive under UEFI don't boot.
Hmm, on an actual bare metal machine with two disks, if I perform the same steps, the UEFI boot entry still points to HD(1), but the system actually boots. So clearly there's something that I'm either missing or that's behaving otherwise than expected.
If you're doing this on a VM, then when you reboot it, both disks need to be on the list of bootable devices. Otherwise you can use the connectefi command at the grub> and it should find the other disks.
Sigh, thank you Marta! I already got burned by this once in the past, but I didn't realize :( After I set both drives as bootable devices in virt-manager, it all works, so this is not an actual bug, closing... Still, could someone enlighten me why both disks are marked as HD(1) in efibootmgr output and not HD(1) and HD(2)? I still can't understand that.
Happy to help. ;) I think that might be the partition number, since the UUIDs are correct? I haven't learned how to read the whole output of efibootmgr yet.
After experimentation (because searching for this online is surprisingly difficult), it really is a partition number, not a disk number. Oh well.