Laszlo have you heard of any edk2 regression with TPM emulation?

(CC'ing Marc-André.)

(In reply to Cole Robinson from comment #1)
> Laszlo have you heard of any edk2 regression with TPM emulation?

No, I'm not aware -- on the other hand, I certainly don't *use* TPM in any of my VMs.

Andrew: would you be willing to bisect the issue perhaps? From your bug report, the problem looks bisectable.

Thanks!
Laszlo

Yes I will try to complete a bisect this week; I agree it seems it would be helpful. It may take a while to get through, though, as there are many patch changes. Even just on the first bisect step I’m running into several build issues. Hopefully it’s not too bad, though.

Created attachment 1732721 [details]
fix-tpm-enable.patch

Bisect showed 07952a962a40efe65729c3ccb9b8934571cec1af as the first bad commit. Did not revert cleanly, but didn’t matter because upon reviewing the commit the problem became apparent: compilation flag was renamed upstream, so this is a packaging issue. Patch attached, which I’ve tested and passes my test scenario.

As an aside: one aspect of this package that slowed things down somewhat when moving around a lot was the `openssl-patch-to-tarball.sh`. It’s not clear to me why this is done out-of-band from the package building itself, I did the following to simply building. Perhaps it’s worth including (would need updating of the script as well).

diff --git a/edk2.spec b/edk2.spec
--- a/sources/edk2/edk2.spec
+++ b/sources/edk2/edk2.spec
@@ -121,6 +121,7 @@ BuildRequires:  qemu-img
 BuildRequires:  genisoimage
 BuildRequires:  bc
 BuildRequires:  sed
+BuildRequires:  perl
 
 # These are for QOSB
 BuildRequires:  python3-requests
@@ -239,6 +240,7 @@ rm -rf ShellBinPkg
 cp -a -- %{SOURCE2} .
 # extract openssl into place
 tar -xf %{SOURCE1} --strip-components=1 --directory CryptoPkg/Library/OpensslLib/openssl
+(cd CryptoPkg/Library/OpensslLib && perl process_files.pl)
 # extract softfloat into place
 tar -xf %{SOURCE4} --strip-components=1 --directory ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3/

(In reply to Andrew M. from comment #5)
> Created attachment 1732721 [details]
> fix-tpm-enable.patch
>
> Bisect showed 07952a962a40efe65729c3ccb9b8934571cec1af as the first
> bad commit. Did not revert cleanly, but didn't matter because upon
> reviewing the commit the problem became apparent: compilation flag was
> renamed upstream, so this is a packaging issue. Patch attached, which
> I've tested and passes my test scenario.

Thanks for the bisection and the patch!

I feel bad about not notifying Cole about this upstream change. I
updated the edk2 binaries / build scripts bundled with upstream QEMU
recently, and there the same flag refresh was necessary. (I didn't find
it by testing; I found it by reviewing the upstream edk2 commit range
that would be incorporated into the QEMU update.) See QEMU commits
504fffb9e526 ("roms/Makefile.edk2: prepare for replacing TPM2*_ENABLE
macros", 2020-09-13) and e105de7579e3 ("roms/Makefile.edk2: complete
replacing TPM2*_ENABLE macros", 2020-09-13). It's unfortunate I'm no
longer able to "broadcast" such upstream edk2 changes to Fedora, ahead
of time (and probably to a few other places that should learn about
these tweaks in time). I'll attempt to file a Fedora RHBZ in advance
next time. My bad.

No worries Laszlo. Andrew nice work and thanks for tracking this down! I'll do a build today

FEDORA-2020-ccd53da415 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ccd53da415

Reviewing the commit (https://src.fedoraproject.org/rpms/edk2/c/ce201154d66a9c56841767843d3f35ef7db058ec), it appears that only my (somewhat unrelated) suggestion about the RPM build process was committed, but not the patch to change the TPM_ENABLE compilation flag. Apologies if it was confusing that I included the former in a comment but the latter in an attachment.

FEDORA-2020-ccd53da415 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ccd53da415`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ccd53da415

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-ccd53da415 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

As noted in my previous comment above this is *not* resolved as the resolving patch was not applied. (Not sure what state to move to, so just going back to “new”)

Sorry for screwing it up, I'll do another build today.

FEDORA-2020-78a2ed6df9 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-78a2ed6df9

FEDORA-2020-78a2ed6df9 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.