OVMF looses boot entries when drives are not present

Robert Dahlem

Active Member
May 7, 2018
18
1
43
61
Hello,

I'm trying a software RAID1 setup with a Debian12 VM. My 2 disks have each
  • a 1 GB partition, type Linux RAID, bound together as /dev/md0, for /boot
  • a 1 GB partition for ESP
  • a Linux LVM partition, bound together in one VG, providing LVs for root and swap
UEFI does not know about RAID1 for ESP, so /dev/sda2 is the "real" ESP on /boot/efi and gets synced to /dev/sdb2 on /boot/efi2.

The EFI boot manager is configured like this:
Code:
# efibootmgr -v
BootCurrent: 000A
Timeout: 3 seconds
BootOrder: 000A,0006,0001,0004,0002,0003,0005,0007,0008,0009,000B,0000
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00003     PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)N.....YM....R,Y.
Boot0002* UEFI QEMU QEMU HARDDISK       PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x1,0x0)/SCSI(0,0)N.....YM....R,Y.
Boot0003* UEFI QEMU QEMU HARDDISK  2    PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x2,0x0)/SCSI(0,1)N.....YM....R,Y.
Boot0004* EFI Internal Shell    FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0005* UEFI QEMU QEMU HARDDISK  3    PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x3,0x0)/SCSI(0,2)N.....YM....R,Y.
Boot0006* debian2       PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x2,0x0)/SCSI(0,1)/HD(2,GPT,cd9167c8-611f-4a00-97ee-58583bac4732,0x1dd000,0x1dd000)/File(\EFI\debian\shimx64.efi)
Boot0007* UEFI PXEv4 (MAC:BC2411731722) PciRoot(0x0)/Pci(0x12,0x0)/MAC(bc2411731722,1)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
Boot0008* UEFI PXEv6 (MAC:BC2411731722) PciRoot(0x0)/Pci(0x12,0x0)/MAC(bc2411731722,1)/IPv6([::]:<->[::]:,0,0)N.....YM....R,Y.
Boot0009* UEFI HTTPv4 (MAC:BC2411731722)        PciRoot(0x0)/Pci(0x12,0x0)/MAC(bc2411731722,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()N.....YM....R,Y.
Boot000A* debian1       PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x1,0x0)/SCSI(0,0)/HD(2,GPT,339df761-e6ff-4d63-ac30-a339fa86a3e5,0x1dd000,0x1dd000)/File(\EFI\debian\shimx64.efi)
Boot000B* UEFI HTTPv6 (MAC:BC2411731722)        PciRoot(0x0)/Pci(0x12,0x0)/MAC(bc2411731722,1)/IPv6([::]:<->[::]:,0,0)/Uri()N.....YM....R,Y.
As far as I know these boot entries are stored in the EFI disk.

When I remove the first disk, the system boots into debian2, but then debian1 (and all the PXE* and HTTP* entries) are missing:
Code:
# efibootmgr -v
BootCurrent: 0006
Timeout: 3 seconds
BootOrder: 0006,0002,0001,0004,0000
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM00003     PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)N.....YM....R,Y.
Boot0002* UEFI QEMU QEMU HARDDISK       PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x2,0x0)/SCSI(0,1)N.....YM....R,Y.
Boot0004* EFI Internal Shell    FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0006* debian2       PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x2,0x0)/SCSI(0,1)/HD(2,GPT,cd9167c8-611f-4a00-97ee-58583bac4732,0x1dd000,0x1dd000)/File(\EFI\debian\shimx64.efi)

Unfortunately, this is persistent: when I re-attach the first drive, I am still unable to boot into debian1, because it does not exist any longer.

There is a documentation for Arch Linux that says exactly so and that it is a firmware behavior, probably meaning OVMF in this case.

They also say: "The solution is to install the boot loader to the default/fallback boot path", by which they mean /EFI/BOOT/BOOTx64.EFI. This is not a viable solution because for secure boot I need shimx64.efi.

I would prefer not to loose boot entries for disks that are temporarily missing. Can that be achieved?

Kind regards,
Robert
 
are both disks checked in boot order in VM options ?
Well, not while one is removed (detached). :) But that is the point where I see that the boot entry has been removed already. And it does not return, when I re-attach the disk and check its box in the VMs options.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!