bug: UEFI boot parameters not preserved with Delta backups

rkelley

Greetings all,

Per this thread, I ran into the same problem: Delta backups with a UEFI bios won't boot. Instead of adding to that thread, I felt it would be better to start a new thread with the "bug" info in the title. Copying @creoleMalady and @olivierlambert as they were part of the initial thread.

Problem
When Delta backups are taken, the UEFI boot environment variables are not preserved from the full copy. It appears a blank/clean UEFI bios is added to the restore process to get the VM booted. When this happens, the boot list presented to the VM does not include the installed OS. The current workarounds are (1) boot from a rescue disk and reinstall grub, or (2) manually boot the system via the UEFI Shell then add the proper boot disk to the UEFI boot list.

Fix
The fix is to ensure the UEFI boot environment parameters are preserved from the running VM into the Delta copy. This is presumably inside the delta backup code.

Below is the UEFI boot list on a non-working system:

root@Debian-11-delta-restore:~# efibootmgr                                           
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0001,0000,0003,0002
Boot0000* UiApp
Boot0001* UEFI Misc Device
Boot0002* UEFI PXEv4 (MAC:0EE793689990)
Boot0003* EFI Internal Shell
                                                    <-- No local boot devices defined.

Below is the UEFI boot list on a working system (note the last entry "Boot0004* debian"):

root@Debian-11-full-restore:~# efibootmgr                                           
BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0005,0001,0000,0004,0003
Boot0000* UiApp
Boot0001* UEFI Misc Device
Boot0002* UEFI PXEv4 (MAC:1A5848A7B5DD)
Boot0003* EFI Internal Shell
Boot0004* debian.                                    <-- UEFI boot param kept from full backup

Workaround 1: Full grub reinstall

Mount a rescue disk to the VM
Boot into rescue mode
Select correct OS disk
Reinstall grub

Workaround 2: Boot via EFI Shell then re-install grub

At the UEFI "Shell" prompt, type map to get a list of EFI partitions. On my system, FS0: is the EFI partition
Type ls FS0:\EFI to get a list of installed OSs. On my system, debian is the name of the installed OS
Type ls FS0:\EFI\<os> to get a list of grub efi binaries. On my system, grubx64.efi is the bootable efi file
Run the efi binary. On my system, I used FS0:\EFI\debian\grubx64.efi to get my system running
Once the OS is running, reinstall grub.

Note: the UEFI Shell expects standard "DOS" partition identifiers. Specifically, note the use of drive:backslash (fs0:\) vs standard unix path/forwardslash (/fs0/)

For additional details on fixing UEFI grub installs, visit this page. It has much more detail on repairing UEFI boot problems.

olivierlambert

That's interesting, we'll have to explore how we can restore the UEFI variable (at least, if it's possible from XAPI perspective)

creoleMalady

@rkelley Thank you for doing all the work for us.

When there is a proper patch, I be happy to test it in our environment as well.

stormi

This will also be important to fix so that Secure-Boot protected VMs can keep their certificate databases (necessary for secureboot) with delta backups.

(CC @beshleman FYI)

rkelley

@stormi @olivierlambert @beshleman
FYI - I have opened a bug in github to track this issue

julien-f

Thank you all for your help

Please try the fix-uefi-delta-backups branch and keep me posted.