Discovery

Legacy cloud templates often lack the partitioning and bootloader
binaries required for UEFI Secure Boot. Attempting to switch such a VM
to OVMF in Proxmox results in “not a bootable disk.” We discovered that
a surgical promotion is possible by manipulating the block device and
EFI variables from the hypervisor.

The Problem

1. Protective MBR Flags: Legacy installers often set
   the pmbr_boot flag on the GPT’s protective MBR. Strict UEFI
   implementations (OVMF) will ignore the GPT if this flag is present.
2. Missing ESP: Cloud images often lack a FAT32 EFI
   System Partition (ESP).
3. Variable Store: A fresh Proxmox
   efidisk0 is empty and lacks both the trust certificates
   (PK/KEK/db) and the BootOrder entries required for an automated
   boot.

The “Promotion” Rule

To upgrade a SeaBIOS VM to Secure Boot without a full OS reinstall:
1. Surgical Partitioning: Map the disk on the host and
add a FAT32 partition (Type EF00). Clear the
pmbr_boot flag from the MBR. 2. Binary
Preparation: Boot the VM in SeaBIOS mode to install
shim and grub-efi packages. Use
grub2-mkconfig to populate the new ESP. 3. Trust
Injection: Use the virt-fw-vars utility on the
hypervisor to programmatically enroll the Red Hat/Microsoft CA keys and
any custom certificates (e.g., FreeIPA CA) into the VM’s
efidisk. 4. Boot Pinning: Explicitly set
the UEFI BootOrder to point to the shimx64.efi
path via virt-fw-vars --append-boot-filepath.

Solution (Example Command
Sequence)

On the Proxmox Host (root):

# Map and Clean MBR
DEV=$(rbd map pool/disk)
parted -s $DEV disk_set pmbr_boot off

# Inject Trust and Boot Path (VM must be stopped)
virt-fw-vars --inplace /dev/rbd/mapped_efidisk \
  --enroll-redhat \
  --add-db <GUID> /path/to/ipa-ca.crt \
  --append-boot-filepath '\EFI\centos\shimx64.efi' \
  --sb

This workflow enables high-integrity Secure Boot environments using
existing SeaBIOS infrastructure templates.