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
