[edk2-devel] Help needed in building UEFI qcow2 images
Laszlo Ersek
lersek at redhat.com
Tue Jun 4 16:10:14 UTC 2019
(+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 [ pavankumar_a at 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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list