[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 fateknollogee com wrote:
Cole & Laszlo, thanks for your help.

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).


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 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
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:


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.


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
for boot to 'just work' ? Is it just some pointer to the default boot

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]