Cole & Laszlo, thanks for your help.
Questions:
1 - Should I just create my Fedora virtual machines with UEFI + i440 and
not use Q35.
2 - The Windows 10 vm's I had (from the same host) had no problems
booting up, but they where UEFI + i440
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@xxxxxxxxxxxxxxxxx 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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
