Re: [edk2-devel] Help needed in building UEFI qcow2 images

["Laszlo Ersek" <lersek@redhat.com>]

(+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@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