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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
