(7.1) Broken UEFI Boot for VM

K

kromberg

Member
Nov 24, 2021
87
6
13
53
I am running proxmox 7.1 and I got some behavior with a VM I do not understand. The VM is running Fedora 33 with a passthrough disk controller. Initially I had the BIOS set to SeaBIOS, but the VM would hang on boot with the Machine UUID line. I switched over to OVMF, added an efi disk, booted up into the fedora install iso, installed, and then rebooted. Now.... when the VM boots, it goes to the EFI setup screen. When I go to the boot manager, the VM os is listed, can be selected, and it boots.

What do I need to do to have the VM boot up as expected?
 

Attachments

  • boot.jpg
    boot.jpg
    32.3 KB · Views: 83
  • boot2.jpg
    boot2.jpg
    50.5 KB · Views: 83
Do you have an EFI disk attached?
 
Yes, it was added before I did the guest os install.
 

Attachments

  • guest.jpg
    guest.jpg
    163.8 KB · Views: 111
Is the boot order configured to first try the boot disk? (VM -> Options -> Boot Order)
 
The boot order is:

ide2, scsi0,net0

I tried swapping the order to:

scsi0, ide2,net0

and that did not make any difference.
 
Followed those steps, and it still boots to the initial OVMF Menu screen. I added a new 'fedora' option and made that the first entry, but still boots to the OVMF menu. Deleted both fedora entries, added a bootable iso image to the cd, and it still boots to the OVMF menu. Added back a new fedora entry, but still boots to the OVMF menu. I am completely stumped why it keeps booting to the OVMF menu.
 
Hmmm...... I think I see the problem. Looks like the order order change is NOT getting saved. I go 'Boot Maintenance Manager' -> 'Boot Options' -> 'Change Boot Order', make the fedora entry be first, and save at every point backing out of the menu options. Also the 'Boot Next Value' always reverts back to 'None'. So it seems that the OVMF bios is always reverting back to some default and changes are not saved.
 
The boot order defined in the VM options overrides the one in the EFI Boot Manager.
 
That is good to know. Looking at the boot order in the GUI, the UEFI does not show up. Is there a command line to add it and make it first?
 
It seems your only option is to boot with that workaround once and create a copy of the .efi file in $ESP/EFI/BOOT/BOOTX64.efi.
 
On the guest side. This issue has nothing to do with the host, but rather seems to be a misconfigured bootloader in the guest.
 
OK, I have played around with things a bit. After a clean install the vm boots as expected. After doing the initial update with adding the latest kernel, the next reboot things break. On a standard bare metal setup using UEFI, installing and running Fedora 33 just works even after several kernel updates with updating grub. For some reason going from the proxmox UEFI bios to the grub bootloader, there seems to be some disconnect. From the BIOS boot manager, selecting the boot option and then the fedora selection which is first, the VM boots fine. What am I missing here.

When you say "create a copy of the .efi file in $ESP/EFI/BOOT/BOOTX64.efi", are you saying copy /boot/efi/EFI/fedora/shimx64-fedora.efi to /boot/efi/EFI/BOOT/BOOTX64.EFI?

[root@balrog BOOT]# pwd /boot/efi/EFI/BOOT [root@balrog BOOT]# ls -lrt total 2744 -rwx------. 1 root root 357248 Oct 2 2018 fbx64.efi -rwx------. 1 root root 257472 Oct 2 2018 fbia32.efi -rwx------. 1 root root 1210776 Oct 2 2018 BOOTX64.EFI -rwx------. 1 root root 975536 Oct 2 2018 BOOTIA32.EFI [root@balrog fedora]# pwd /boot/efi/EFI/fedora [root@balrog fedora]# ls -lrt total 15640 -rwx------. 1 root root 1204496 Oct 2 2018 shimx64-fedora.efi -rwx------. 1 root root 1210776 Oct 2 2018 shimx64.efi -rwx------. 1 root root 969264 Oct 2 2018 shimia32-fedora.efi -rwx------. 1 root root 975536 Oct 2 2018 shimia32.efi -rwx------. 1 root root 1210776 Oct 2 2018 shim.efi -rwx------. 1 root root 1159560 Oct 2 2018 mmx64.efi -rwx------. 1 root root 927824 Oct 2 2018 mmia32.efi -rwx------. 1 root root 110 Oct 2 2018 BOOTX64.CSV -rwx------. 1 root root 112 Oct 2 2018 BOOTIA32.CSV -rwx------. 1 root root 2536712 Apr 11 2021 grubx64.efi -rwx------. 1 root root 1615112 Apr 11 2021 grubia32.efi -rwx------. 1 root root 2536712 Apr 11 2021 gcdx64.efi -rwx------. 1 root root 1615112 Apr 11 2021 gcdia32.efi -rwx------. 1 root root 6748 Dec 7 22:27 grub.cfg drwx------. 2 root root 4096 Dec 8 03:36 fonts -rwx------. 1 root root 1024 Dec 9 02:18 grubenv
 
Could you provide a list of all changed packages when updating Fedora?
 
There was about a total of 980ish packages updated going from the initial install of the iso to doing the dnf update. The most significant that would cause anything would be going from kernel 5.8.15-301.fc33.x86_64 to 5.14.18-100.fc33.x86_64. This would cause grub to be updated as well as the initrd modules. Not sure how this would impact things as once the BIOS loads/runs grub, things work as expected.
 
OK, tried that same thing. The VM always goes to the BIOS menu. Selecting continue or going to the boot manager and selecting fedora boots as expected. For some reason the proxmox BIOS/UEFI is not going to the bootable disk.
 
You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom