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

[Laszlo Ersek]

On 08/27/17 18:05, ovirt at fateknollogee.com wrote:
>> 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.

Sorry, I may have put that the wrong way. I guess I meant "I'm unaware
of any reason why i440fx vs. Q35 might make a difference here".

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

I suggest using the default machine type unless you have a reason not to.

Thanks,
Laszlo

> 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