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

[Laszlo Ersek]

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