(+Gerd) On 06/04/19 13:28, Pavan Kumar Aravapalli wrote: > Hi Laszlo, > > Thank you for your quick response, and apologies for the your pervious mail > thread which i could not observed as I only monitor the mail [ > pavankuma...@accelerite.com ]inbox. And I am not receiving mail reply's to my > inbox even though i have subscribed to devel group. Here after i will proceed > with web console https://edk2.groups.io ( https://edk2.groups.io/ ) for > tracking info. > > as you suggested, I have done the dom xml changes you suggested in previous > mail that > > * Dom XML Changes for OVMF loader stuff > * deleted existing varstore file /var/lib/libvirt/qemu/nvram/ > > I am unable to boot the VM saying that there is no bootable device to boot , > attached the screen shot with this thread for the same. I have been using > image > https://www.kraxel.org/repos/images/fedora-28-efi-systemd-x86_64.qcow2.xz for > Guest VM Boot. Please suggest me if i missed out some thing.
When you import a pre-made disk image like this, with a UEFI OS installation on it, but without any Boot#### and BootOrder UEFI variables in the domain's variable store, that amounts to an installed UEFI system losing its Boot#### and BootOrder variables. The UEFI spec covers this case; a great writeup can be found at <https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>. However: you're using a systemd-related UEFI boot loader, and I have no clue whether it implements the above-referenced "fallback" behavior. For now, I would suggest trying the shim+grub2 variant, and even Fedora 29 rather than Fedora 28: "fedora-29-efi-grub2-x86_64.qcow2.xz". If it still doesn't work, then you can modify your domain XML as follows, for saving a firmware debug log (note that the xmlns:qemu attribute (namespace definition) in the root element is important): <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='isa-debugcon.iobase=0x402'/> <qemu:arg value='-debugcon'/> <qemu:arg value='file:/tmp/secvm.log'/> </qemu:commandline> </domain> The file "/tmp/secvm.log" will contain the OVMF debug log. Additionally, I'd suggest removing the <boot dev='hd'/> element, and adding the following <boot order='1'/> instead: <disk type='file' device='disk'> ... <source file='/var/lib/libvirt/images/sec-boot.qcow2'/> ... <boot order='1'/> </disk> ... I guess it's also possible that the UEFI boot loader in the disk image that you've tried isn't properly signed, against the certificates enrolled in "/usr/share/OVMF/OVMF_VARS.secboot.fd". If that's the case, the OVMF debug log will show it. Thanks, Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41872): https://edk2.groups.io/g/devel/message/41872 Mute This Topic: https://groups.io/mt/31718606/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
