[virt-tools-list] UEFI/Q35: System BootOrder not found

[Laszlo Ersek]

On 08/26/17 00:23, Cole Robinson wrote:
> On 08/24/2017 07:34 AM, ovirt at fateknollogee.com wrote:
>> I used virt-manager (in a previous Fedora 25 install) to create a Fedora 26
>> virtual machine.
>> This Fedora26 image was qcow2 and UEFI (firmware/chipset: EFI/Q35.
>> The qcow2 images were stored on a separate disk (not on the same disk as the
>> Fedora 25 host).
>>
>> I changed the host o/s from Fedora 25 to 26.
>> I did not keep the XML files for the virtual machines.
>>
>> Using virt-manager, creating new vm & selecting "import existing disk image"
>> does not work.
>> When I boot the vm, I get an error "System BootOrder not found Initializing
>> defaults".
>> The virtual machine will not boot.
>>
>> Any ideas on how to "fix" the error?
> 
> Good question that I've wondered myself. I assume the failure to boot is
> because the default generated NVRAM doesn't have whatever boot knowledge is
> created at VM OS install time.
> 
> Laszlo, is there some way to regenerate NVRAM for a disk image?

That's actually what's being attempted (when you see the message "System
BootOrder not found Initializing defaults"). The message comes from
"fallback.efi". You can read all about it in Peter Jones's blog:

https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/

The intent is that "fallback.efi" is booted under the circumstances
described above, it recreates the UEFI boot option, and from then on you
can boot again normally. Unfortunately "fallback.efi" seems to have a
bug that triggers an ASSERT() failure in edk2 (you can see it if you
capture the OVMF debug log in a file), hence the above symptoms.

It can be mitigated manually: when the VM boots, interrupt it at the
TianoCore splash screen. In the setup utility, navigate to:

Boot Maintenance Manager
  Boot Options
    Add Boot Option

In the file chooser, select

  <whatever device you have>/EFI/fedora/shim.efi

and enter a description (name) for the boot option.

Then,

Boot Maintenance Manager
  Boot Options
    Change Boot Order

and move the new boot option to the top of the list.

After you commit the changes, you can forcibly reset the VM, or else
return to the setup TUI front page, and select Reset there.

> Also, for my own curiosity, what data is stored in the NVRAM that's critical
> for boot to 'just work' ? Is it just some pointer to the default boot device?

I don't know about "critical", but "important" can be: UEFI boot
options, Secure Boot-related variables, ... The UEFI spec lists quite a
few standardized variables. Plus, UEFI variables live under namespaces
(identified by "vendor GUID"s), so if you have some special app that has
its own UEFI variables (like shim / MokManager for their own certificate
handling), that could be important too.

If you don't really care about UEFI, you just want it to boot, then
"fallback.efi" should just work. (I'm not sure why it doesn't,
currently; there have been different issue reports and bugfixes in the
past.)

Thanks
Laszlo