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

[ovirt at fateknollogee.com]

No offense taken & no worries at all.
With your helpful suggestion, I was able to get the Fedora vm's back up 
& running, thanks for that.
Right now, I have both Fedora 26 & Win 10 vm's installed (& booting) 
with UEFI & Q35

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