20.04 LTS's OVMF_CODE.ms.fd does not boot

[Ryutaroh Matsumoto]

This is an upstream issue reported at
https://bugzilla.tianocore.org/show_bug.cgi?id=3064

/usr/share/OVMF/OVMF_CODE.ms.fd does not boot by qemu-system-x86_64.
To reproduce the symptom, on Ubuntu 20.04 amd64, do the following:

cp /usr/share/OVMF/OVMF_VARS.ms.fd .
qemu-system-x86_64 -enable-kvm -cpu host -machine q35,smm=on,accel=kvm -global driver=cfi.pflash01,property=secure,value=on -m 1024 -drive if=pflash,unit=0,format=raw,read-only=on,file=/usr/share/OVMF/OVMF_CODE.ms.fd -drive if=pflash,unit=1,format=raw,file=OVMF_VARS.ms.fd

On the other hand, if OVMF_CODE.ms.fd in the above command is replaced by OVMF_CODE.fd, the qemu starts fine.

Fedora 33 somehow built a working version of OVMF_CODE.ms.fd as OVMF_CODE.secboot.fd.
Borrowing those files from Fedora 33 suppress this symptom...

I hope working OVMF_CODE.ms.fd will be delivered in a future updates to Ubuntu Focal LTS.

[dann frazier (dannf)]

On Tue, Nov 10, 2020 at 4:01 AM Ryutaroh Matsumoto
<email address hidden> wrote:
> cp /usr/share/OVMF/OVMF_VARS.ms.fd .
> qemu-system-x86_64 -enable-kvm -cpu host -machine q35,smm=on,accel=kvm -global driver=cfi.pflash01,property=secure,value=on -m 1024 -drive if=pflash,unit=0,format=raw,read-only=on,file=/usr/share/OVMF/OVMF_CODE.ms.fd -drive if=pflash,unit=1,format=raw,file=OVMF_VARS.ms.fd

You need to include:
  -global ICH9-LPC.disable_s3=1

 -dann

[Ryutaroh Matsumoto (emojifreak)]

Thanks. I was told at the upastream
https://bugzilla.tianocore.org/show_bug.cgi?id=3064#c5

that
(1) Ubuntu/Debian packaging of ovmf should be built with -a X64 -a IA32, or
(2) Ubuntu/Debian packaging of qemu-system-x86_64 should include -global ICH9-LPC.disable_s3=1.

In their opinion, Ubuntu/Debian packaging is unsuitable.

[dann frazier (dannf)]

"Unsuitable" seems like your characterization. It is true that users who choose to launch SecureBoot guests with QEMU directly need to know to add the "disable_s3" arg, and I agree that is not ideal. For users using higher level software (vir-install/OpenStack), they'll find that this parameter is already set for them. It is also true that SecureBoot guests will inherently not support S3 - but I haven't seen any reports of users missing that feature. That said, it is worth looking into whether we'd want to switch to an IA32X64 build for future releases. Are we losing any significant support by moving to a 32-bit PEI?

[Ryutaroh Matsumoto (emojifreak)]

Thanks. I will use OVMF files from Fedora 33.

[dann frazier (dannf)]

Adding a QEMU task to air out the suggestion in Comment #2.2

[Christian Ehrhardt  (paelzer)]

Thanks for tackling that in edk2 Dannf!
For qemu I think setting ICH9-LPC.disable_s3=1 as default will negatively affect as much (or actually more) cases that it fixes. So if you can get the IA32X64 working without major impacts I'd clearly prefer that.
Setting qemu to Won't Fix for now but subscribing myself to track this.
If all tries on edk2 would fail we'd need to think about a better way than making this default (something conditional).

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 2020.11-2

---------------
edk2 (2020.11-2) unstable; urgency=medium

  * autopkgtest: Add allow-stderr to Restrictions to fix failure.

 -- dann frazier <email address hidden> Tue, 15 Dec 2020 11:42:37 -0700