On Thu, Aug 06, 2015 at 11:28:25AM -0700, Ryan Barry wrote:
On 08/06/2015 08:08 AM, Martin Kletzander wrote:
On Tue, Aug 04, 2015 at 07:11:29AM -0700, Ryan Barry wrote:
On 08/03/2015 10:47 PM, Martin Kletzander wrote:
On Mon, Aug 03, 2015 at 03:39:30PM -0700, Ryan Barry wrote:
On 08/03/2015 01:43 PM, Ryan Barry wrote:
Using:
edk2.git-0-20150803.b1141.ga0973dc.x86_64 edk2.git-ovmf-x64-0-20150802.b1139.gb234418.noarch
On Fedora 22.
Provisioning a i440FX system in virt-manager and attempting to boot results in successful EFI initialization, but the VM exits ungracefully after the bootloader (with F22 and CentOS 7 installer images). There's no really useful information in any of the logs.
I haven't tried EFI with 440fx, only with q35. I haven't found an option to enable EFI neither a secureboot anywhere in virt-manager.
q35 doesn't help here. secureboot is in the EFI config menus (press <ESC> or <DEL> in the guest while booting, go look at the boot configuration, and you'll see secureboot options -- it's disabled by default and not able to be enabled until LockDown_ms is applied).
Oh, so that's what I misunderstood, sorry for that.
What I don't understand is why this matters, since I was able to boot with basically the generated command (see below) from a console, but it's 100% reproducible.
Using qemu-kvm directly (qemu-kvm -bios /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd -m 1G -cdrom ~rbarry/Downloads/Fedora-Server-netinst-x86_64-22.iso) boots and loads successfully.
We don't use '-bios' but '-drive file,if=pflash' and that's done once for the OVMF code and second time for the efivars storage. What's the guest XML and full command line of qemu being started?
I was able to boot with this (once I removed -S, -spice, and -netdev). After installing with -netdev user..., and applying LockDown_ms, it boots normally from virsh/virt-manager.
So the generated command (from libvirt) works for you if there is no -S (of course) and -netdev (I guess because of the fd= we're passing)? Why did you remove '-spice'?
If the only difference in this case really is libvirt, then we need to know why the machine shuts down. If neither the 'virsh domstate --reason <domain>' helps nor there is any information in the logs, then I suggest enabling debug logs and looking through those (both the domain log and libvirtd log).
I removed -spice because I was ok with a basic console.
I enabled libvirtd debug logging and got nothing useful out of it. I'll try guest debugging next week
Just a note, if 'virsh domstate --reason <domain>' says 'shut off (crashed)', then that's not a libvirt problem, but probably qemu.