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

[ovirt at fateknollogee.com]

Cole & Laszlo, thanks for your help.

Questions:
1 - Should I just create my Fedora virtual machines with UEFI + i440 and 
not use Q35.
2 - The Windows 10 vm's I had (from the same host) had no problems 
booting up, but they where UEFI + i440

On 2017-08-27 07:04, Laszlo Ersek wrote:
> 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