Legacy Bios instead of UEFI

[macamba]

I am doing a fresh install of my Proxmox with VE 8.2.2. because I wanted the OS installed on a ZFS raid 1 filesystem on two NVME ssd drives.
After my install I see my Boot mode = Legacy Bios although I recall that my previous install (not ZFS raid 1 and only one NVME ssd) had Boot mode set to UEFI.
I don't recall an option during the install to choose between the two. UEFI is enabled in BIOS. What did I overlooked?

Macamba

 

[_gabriel]

Where you see Boot mode = Legacy Bios ?
PVE docs say "efibootmgr -v" to check boot mode.
If it returns a message that EFI variables are not supported, GRUB is used in BIOS/Legacy mode.

 

[leesteken]

GRUB is used in BIOS/Legacy mode.

But also when using secure boot in UEFI mode. Or one can chose to use GRUB with UEFI instead of systems-boot nowadays (I think). The Proxmox bootloader seems to become less simple each time. I wish they would just phase systemd-boot out. It's more simple but it's use case seems to diminish and half my post are about this confusion (since it determines the kernel parameters).

 

[_gabriel]

Or one can chose to use GRUB with UEFI instead of systems-boot nowadays (I think).

We can't choose during installer, but switch afterward with proxmox-boot-tool.

I wish they would just phase systemd-boot out

+1

 

[esi_y]

But also when using secure boot in UEFI mode. Or one can chose to use GRUB with UEFI instead of systems-boot nowadays (I think). The Proxmox bootloader seems to become less simple each time. I wish they would just phase systemd-boot out. It's more simple but it's use case seems to diminish and half my post are about this confusion (since it determines the kernel parameters).

I suspect the direction was meant to be ... towards unified kernel images - or at least e.g. putting /boot on the vfat ESP would imply that.

Also, while I am not a fan of ZFS on root, but it seems very popular for lots of users and then ZFSBootMenu would have been the natural choice.

 

[macamba]

Where you see Boot mode = Legacy Bios ?
PVE docs say "efibootmgr -v" to check boot mode.
If it returns a message that EFI variables are not supported, GRUB is used in BIOS/Legacy mode.

Initially I derived it from the Proxmox web interface. Issuing 'efibootgmr -v' results in:


How can I switch to UEFI? And why did my previous install had UEFI out-of-the-box?

 

[fabian]

whether a system boots in legacy or proper EFI mode is determined by the UEFI settings, not by PVE..

the boot loader situation is like it is for historical reasons:

- PVE used to use Grub for everything
- ZFS and Grub became increasingly brittle, because the ZFS code in Grub didn't keep up with the real ZFS code
- we switched to systemd-boot for ZFS on / on new UEFI installs, and grub-with-kernel-on-ESP for legacy ones (non-ZFS installs remained with regular Grub)
- when implementing secure boot support, we had to switch back to grub-with-kernel-on-ESP for ZFS on UEFI with secure boot enabled (systemd-boot was not on the list of "approved bootloaders" at the time)

now actually it would be possible to get systemd-boot signed as well, and we could support that for (ZFS and non-ZFS) EFI booting in theory, also with secure boot enabled. we haven't decided yet whether we'll enable that. Debian itself is also discussing how to proceed with regards to UKIs and kernel related tooling, so there might be more changes coming in the future.

 

[macamba]

Just reading 'https://pve.proxmox.com/wiki/Host_Bootloader' and understand that when I install PVE root on ZFS without secure boot enabled it's suppose to use UEFI boot by default. Since this is true in my case I wonder why it uses GRUB instead. What can I do to make sure UEFI boot is used? Also happy to install again form scratch since I am not that far in the process of re-building my system.

I use the first two listed disks as rpool for both it created an EFI partition. Ignore the third disk entry, thats' my previous PVE install.

 

[esi_y]

now actually it would be possible to get systemd-boot signed as well, and we could support that for (ZFS and non-ZFS) EFI booting in theory, also with secure boot enabled. we haven't decided yet whether we'll enable that. Debian itself is also discussing how to proceed with regards to UKIs and kernel related tooling, so there might be more changes coming in the future.

Or it will be abandoned sooner than it reaches stable. The gummiboot might be just fine, but UKIs for "better security" ... next thing to experience is not being able to customize own initramfs simply anymore. I wonder if enterprise customers actually ask for SB support ...

 

[esi_y]

Just reading 'https://pve.proxmox.com/wiki/Host_Bootloader' and understand that when I install PVE root on ZFS without secure boot enabled it's suppose to use UEFI boot by default. Since this is true in my case I wonder why it uses GRUB instead. What can I do to make sure UEFI boot is used? Also happy to install again form scratch since I am not that far in the process of re-building my system.

I think you got your answer in the first line, somehow condensed ...

whether a system boots in legacy or proper EFI mode is determined by the UEFI settings, not by PVE..

If you have a BIOS/UEFI that is trying to be smart about booting Legacy, the thing that already booted that way can't really do anything about it. The best thing you can do is to disable whatever kind of Legacy / UEFI with CSM support in your firmware.

 

[fabian]

Just reading 'https://pve.proxmox.com/wiki/Host_Bootloader' and understand that when I install PVE root on ZFS without secure boot enabled it's suppose to use UEFI boot by default. Since this is true in my case I wonder why it uses GRUB instead. What can I do to make sure UEFI boot is used? Also happy to install again form scratch since I am not that far in the process of re-building my system.

I use the first two listed disks as rpool for both it created an EFI partition. Ignore the third disk entry, thats' my previous PVE install.
View attachment 74425

again - PVE is not deciding whether your system uses UEFI boot, it has to follow what your system does. it will always create an ESP, both to make it easier to switch, and to allow the Grub+Kernels-on-ESP use case for legacy boot with ZFS.

 

[fabian]

Or it will be abandoned sooner than it reaches stable. The gummiboot might be just fine, but UKIs for "better security" ... next thing to experience is not being able to customize own initramfs simply anymore. I wonder if enterprise customers actually ask for SB support ...

UKIs can be extended, and that is the current plan if they get implemented (give the user the option to add their own overlays/extensions, that the user can sign with their MOK).

(enterprise) users asking for SB support and easier installs out of the box are the main reasons we implemented secure boot support in the first place, and I guess that is true for most distros.

 

[macamba]

I think you got your answer in the first line, somehow condensed ...



If you have a BIOS/UEFI that is trying to be smart about booting Legacy, the thing that already booted that way can't really do anything about it. The best thing you can do is to disable whatever kind of Legacy / UEFI with CSM support in your firmware.

Thansk. Fully disabling CSM on the motherboard worked! Even setting all related CSM settings to enforce UEFI explicitly didn't work (so not disabling fully). Enabling Secure Boot after words is that possible with UEFI?

 

[esi_y]

Thansk. Fully disabling CSM on the motherboard worked! Even setting all related CSM settings to enforce UEFI explicitly didn't work (so not disabling fully).

That's the "smartness" of the CSM.

Enabling Secure Boot after words is that possible with UEFI?

I would not do this. I mean, l would not want to do any troubleshooting upon later upgrades. But maybe it works with PVE "out-of-the-box", I just really wonder what benefit it has for non-encrypted root installs. I understand it feels good to tick the box, but to me it's like asking for HTTPS repos of signed binaries.

And no, you would need to convert manually, albeit there's a tool for that:

https://forum.proxmox.com/threads/c...fter-switching-bios-to-sb.144423/#post-651282

https://pve.proxmox.com/wiki/Host_Bootloader#sysboot_proxmox_boot_tool

 

[macamba]

That's the "smartness" of the CSM.



I would not do this. I mean, l would not want to do any troubleshooting upon later upgrades. But maybe it works with PVE "out-of-the-box", I just really wonder what benefit it has for non-encrypted root installs. I understand it feels good to tick the box, but to me it's like asking for HTTPS repos of signed binaries.

And no, you would need to convert manually, albeit there's a tool for that:

https://forum.proxmox.com/threads/c...fter-switching-bios-to-sb.144423/#post-651282

https://pve.proxmox.com/wiki/Host_Bootloader#sysboot_proxmox_boot_tool

Didn't look yet into what secure boot encompasses. Assuming secure boot enables TPM for secure key storage and assuring boot integrity. Than you stand fully correct that it does not make sense on a non-encrypted rpool.

 

[esi_y]

Thansk. Fully disabling CSM on the motherboard worked! Even setting all related CSM settings to enforce UEFI explicitly didn't work (so not disabling fully). Enabling Secure Boot after words is that possible with UEFI?

I just want to add, if you have (in the future) any sort of tool (e.g. memtest) that only supports BIOS boot, keep that in mind if it rejects to boot. Your firmware most likely goes by the fact that it found BIOS boot partition on the PVE install, that's why it defaults to BIOS boot when allowed to. I have no idea what implications it would have on the PVE supplied tools if you removed it, but obviously, for EFI booting, you really could do away with it.