Re: UEFI/Q35: System BootOrder not found

[ovirt@xxxxxxxxxxxxxxxxx]

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@xxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxx 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@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