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

[ovirt at fateknollogee.com]

> I don't see how i440fx vs. Q35 is a relevant question here.
I asked since I wasn't sure if that was the reason for the Fedora vm's 
not booting vs Win 10 vm's booting.

A better question might be, is there a reason to "not" use Q35?

On 2017-08-27 08:53, Laszlo Ersek wrote:
> On 08/27/17 17:05, ovirt at fateknollogee.com wrote:
>> Cole & Laszlo, thanks for your help.
>> 
>> Questions:
>> 1 - Should I just create my Fedora virtual machines with UEFI + i440 
>> and
>> not use Q35.
> 
> I don't see how i440fx vs. Q35 is a relevant question here.
> 
>> 2 - The Windows 10 vm's I had (from the same host) had no problems
>> booting up, but they where UEFI + i440
> 
> That can be explained by something else:
> 
> The UEFI application that restores (recreates) your UEFI boot options,
> in case they were lost, comes from the OS vendor. (The OS installer 
> puts
> it in place on the EFI system partition.) So my take is that the
> Microsoft application that is the role-wise equivalent of 
> "fallback.efi"
> didn't crash, and restored your boot option(s).
> 
> Laszlo
> 
> 
>> 
>> 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