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
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
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
because the default generated NVRAM doesn't have whatever boot
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
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
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
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
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
I don't know about "critical", but "important" can be: UEFI boot
options, Secure Boot-related variables, ... The UEFI spec lists quite
few standardized variables. Plus, UEFI variables live under
(identified by "vendor GUID"s), so if you have some special app that
its own UEFI variables (like shim / MokManager for their own
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