FS#66322 - [edk2-ovmf] qemu VM doesn't start when using /usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.fd

Attached to Project: Arch Linux
Opened by nl6720 (nl6720) - Monday, 20 April 2020, 11:13 GMT
Last edited by freswa (frederik) - Wednesday, 22 April 2020, 20:10 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
After updating from ovmf 1:202002-1 to edk2-ovmf 202002-2, I can't run a qemu VM with Secure Boot support.

With ovmf 1:202002-1, it used to (mostly) work with:

qemu-system-x86_64 -enable-kvm -machine q35,accel=kvm -cpu host -m 2G -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=/usr/share/ovmf/x64/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,file=$HOME/qemu-VM/ArchLinux_SecureBoot/OVMF_VARS.fd -drive file=$HOME/qemu-VM/ArchLinux_SecureBoot/ArchLinux-disk1.qcow2,format=qcow2,if=virtio -net nic,model=virtio -net user -boot menu=on

In firmware menu > Device Manager there was "Secure Boot Configuration" (some while ago, the options set in there started to get reset after powering off the VM, but's another issue).

Now with edk2-ovmf 202002-2, running:

qemu-system-x86_64 -enable-kvm -machine q35,accel=kvm -cpu host -m 2G -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.fd,readonly=on -drive if=pflash,format=raw,file=$HOME/qemu-VM/ArchLinux_SecureBoot/OVMF_VARS.fd -drive file=$HOME/qemu-VM/ArchLinux_SecureBoot/ArchLinux-disk1.qcow2,format=qcow2,if=virtio -net nic,model=virtio -net user -boot menu=on

I get a VM window with "Guest has not initialized the display (yet)." And nothing happens.

If I use /usr/share/edk2-ovmf/x64/OVMF_CODE.fd instead, then there is no "Secure Boot Configuration" in the firmware menu.


Additional info:
* package version(s)
* config and/or log files etc.
* link to upstream bug report, if any
edk2-ovmf 202002-2
qemu 4.2.0-2


Steps to reproduce:
see above
This task depends upon

Closed by  freswa (frederik)
Wednesday, 22 April 2020, 20:10 GMT
Reason for closing:  Fixed
Additional comments about closing:  got qemu to start by adding:

-global ICH9-LPC.disable_s3=1
Comment by David Runge (dvzrv) - Tuesday, 21 April 2020, 08:20 GMT
@nl6720: Thanks for testing this!

Okay, we have two things to check here I guess (in regards to my mail to arch-dev-public [1]):

* will this be fixed by providing qemu firmware descriptor files (as provided by the ovmf package [2]) or not
* will this work out of the box with the files found in qemu-arch-extra or not

I'll add the descriptor files and push an update to testing so you can check it out!

[1] https://lists.archlinux.org/pipermail/arch-dev-public/2020-April/029949.html
[2] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/ovmf
Comment by David Runge (dvzrv) - Tuesday, 21 April 2020, 09:38 GMT
I also realized, that this is potentially now a duplicate of https://bugs.archlinux.org/task/64206
I've added the firmware descriptors in edk2-ovmf 202002-3. Please try!
Comment by Pascal Ernster (hardfalcon) - Tuesday, 21 April 2020, 11:02 GMT
@dvzrv: Note that the fact that the old ovmf package and your new edk2-ovmf package contain the firmware images in different locations without providing symlinks for backwards compatibility will cause issues for Archlinux installations with existing libvirt VMs.

Libvirt seems to read the firmware image location from the JSON file upon creation of the VM, but won't automatically update that location later on if the path specified inside the JSON file changes.
Comment by David Runge (dvzrv) - Tuesday, 21 April 2020, 11:53 GMT
@hardfalcon: Thanks for the heads up.

This is something that needs to be reported upstream as well, as this makes migration between different systems rather painful.
I will add the libvirt package maintainers as well.
Comment by Pascal Ernster (hardfalcon) - Tuesday, 21 April 2020, 12:45 GMT
@dvzrv: You're welcome, thanks for your effort to provide reproducible binaries for the EFI shell and the EDK2 firmwares. :-)

I don't consider libvirt's behaviour the root/cause of the issue though - it does exactly what it is supposed to do, and what its documentation claims it does. Libvirt's XML format specification for the definition/configuration of VMs has always been using the direct path to the OVMF firmware file, and never the JSON files.

Also, even if libvirt changed its behaviour now in this regard and created new VMs in a different way, this still wouldn't fix existing VMs - and it shouldn't, because there's no way for libvirt to be sure that the user didn't intentionally reference a specific firmware image file within the XML definition of a VM.
Comment by David Runge (dvzrv) - Tuesday, 21 April 2020, 15:54 GMT
@hardfalcon: Yeah, you're probably right. I've added symlinks for backwards compatibility now but also added an install file to inform users to change the path to the firmware.

Please check whether 202002-4 works as expected!

The firmware files packaged in ovmf are all with secure boot included. edk2-ovmf provides both with and without secure boot. More confusion! \o/
Comment by David Runge (dvzrv) - Wednesday, 22 April 2020, 12:49 GMT
@nl6720: Is this working for you with edk2-ovmf 202002-6 in [testing]?
Comment by nl6720 (nl6720) - Wednesday, 22 April 2020, 13:11 GMT
Nothing changed with edk2-ovmf 202002-6.

Firmware descriptors are not relevant to me since I run qemu directly from a terminal not via libvirt.
Comment by nl6720 (nl6720) - Wednesday, 22 April 2020, 14:52 GMT
After re-reading  FS#59465  , I got qemu to start by adding:

-global ICH9-LPC.disable_s3=1

Loading...