Description of problem: edk2-ovmf is taking a PMBR protective record's BootIndictor bit into account when deciding whether the GPT is valid or not. When pmbr_boot (a.k.a setting a bit on the protective record partition entry's BootIndictor in the PMBR, a.k.a. setting the boot flag, a.k.a. setting the active bit) is set, the GPT is seemingly considered invalid by edk2-ovmf and the system is not bootable. Version-Release number of selected component (if applicable): edk2-ovmf-20200801stable-4.fc34.noarch How reproducible: Always Steps to Reproduce: 1. Create a UEFI bootable image, boot it 2. parted /dev/vda disk_set pmbr_boot on 3. Try to boot the image Actual results: Firmware drops to an EFI shell. Expected results: It should boot. Additional info: Upstream bug has details including a test image attached.
There is now an upstream commit that can be backported to fix this: https://github.com/tianocore/edk2/commit/b3db0cb1f8d163f22b769c205c6347376a315dcd
Paolo, this has now been fixed in RHEL 9 (cf bug 1988760) and RHEL 8.5 (cf bug 1988762). Can we get this fixed in Fedora 34+ soon?
There is now a new stable release of edk2 that includes this fix: https://github.com/tianocore/edk2/releases/tag/edk2-stable202108 Can we get this fixed for F34+ now?
Fedora Linux 35 has been released *without* this fixed, can we *please* get this fixed as an update for F34 and F35 now?
(In reply to Neal Gompa from comment #4) > Fedora Linux 35 has been released *without* this fixed, can we *please* get > this fixed as an update for F34 and F35 now? I'll have a look how hard this is tomorrow. Next edk2 stable tag is scheduled for end of november (~2 weeks ahead). So my plan was to skip 2021-08 and jump straight to 2021-11 when it is released so we don't have to do the rebase dance twice ...
(In reply to Gerd Hoffmann from comment #5) > (In reply to Neal Gompa from comment #4) > > Fedora Linux 35 has been released *without* this fixed, can we *please* get > > this fixed as an update for F34 and F35 now? > > I'll have a look how hard this is tomorrow. > > Next edk2 stable tag is scheduled for end of november (~2 weeks ahead). > So my plan was to skip 2021-08 and jump straight to 2021-11 when it is > released so we don't have to do the rebase dance twice ... I'm fine with that as well. There's a lot of other nice updates in the upcoming edk2 release, so I can wait a couple of weeks if that's your plan. :)
rawhide scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=78895648 (failed, investigating ...). f35 scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=78893852 (worked).
> rawhide scratch build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=78895648 (failed, > investigating ...). Hmm, building in rawhide toolbox worked. /me looks confused.
2021-11 rebase scratch builds https://koji.fedoraproject.org/koji/taskinfo?taskID=79400390 (f35) https://koji.fedoraproject.org/koji/taskinfo?taskID=79400372 (rawhide, x86_64 (only) still failing)
FEDORA-2021-887e8d3a64 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-887e8d3a64
FEDORA-2021-887e8d3a64 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-887e8d3a64` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-887e8d3a64 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-887e8d3a64 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days