Fedora boots that are going via the bootaa64->fbaa64 path (installers) fail to boot on machines that have the EFI_MEMORY_ATTRIBUTES_PROTOCOL. There is an upstream fix which seems to fix this for 4k enviroments, so either shim needs to be pulled forward to the latest upstream (which I understand will be released RSN) or the alignment patch backported. Reproducible: Always Steps to Reproduce: 1. Grab latest EDK2 firmware for a machine 2. Try to boot fedora 3. Actual Results: Open: Open '\EFI\BOOT\fbaa64.efi' Success SetMemoryAttributes: BaseAddress == 0x33797000, Length == 0x1A000, Attributes == 0x4000 ClearMemoryAttributes: BaseAddress == 0x33797000, Length == 0x1A000, Attributes == 0x22000 Synchronous Exception at 0x000000003379B000 PC 0x00003379B000 PC 0x0000337EB288 PC 0x0000337EB338 PC 0x0000337EC1B4 PC 0x0000337E9030 PC 0x000039E9B480 (0x000039E94000+0x00007480) [ 1] DxeCore.dll PC 0x00003390E25C (0x000033903000+0x0000B25C) [ 2] UiApp.dll PC 0x000033913A98 (0x000033903000+0x00010A98) [ 2] UiApp.dll PC 0x000036E7B4B8 (0x000036E66000+0x000154B8) [ 3] SetupBrowser.dll PC 0x000036E71A1C (0x000036E66000+0x0000BA1C) [ 3] SetupBrowser.dll PC 0x00003390BD98 (0x000033903000+0x00008D98) [ 4] UiApp.dll PC 0x000039E9B480 (0x000039E94000+0x00007480) [ 5] DxeCore.dll PC 0x000036E43F9C (0x000036E3D000+0x00006F9C) [ 6] BdsDxe.dll PC 0x000036E4733C (0x000036E3D000+0x0000A33C) [ 6] BdsDxe.dll PC 0x000039E9EDA8 (0x000039E94000+0x0000ADA8) [ 7] DxeCore.dll PC 0x000000027040 PC 0x00000002716C [ 1] /home/jlinton/rpi2/Build/RPi4/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll [ 2] /home/jlinton/rpi2/Build/RPi4/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll [ 3] /home/jlinton/rpi2/Build/RPi4/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe/DEBUG/SetupBrowser.dll [ 4] /home/jlinton/rpi2/Build/RPi4/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll [ 5] /home/jlinton/rpi2/Build/RPi4/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll [ 6] /home/jlinton/rpi2/Build/RPi4/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll [ 7] /home/jlinton/rpi2/Build/RPi4/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll X0 0x0000000034B23798 X1 0x00000000373D0018 X2 0x000000003379B000 X3 0x0000000000000000 X4 0x0000000036F5D068 X5 0x0000000000000001 X6 0x0000000000000000 X7 0x0000000000000000 X8 0x0000000000000002 X9 0x0000000000000001 X10 0x00000000337CA018 X11 0x0000000000000000 X12 0x0000000000000002 X13 0x0000000000000002 X14 0x0000000000000001 X15 0x00000000000000FF X16 0x0000000036F562D0 X17 0x000000001EA68734 X18 0x0000000000000011 X19 0x000000003386A000 X20 0x0000000000000000 X21 0x0000000034B23798 X22 0x000000003387E2F0 X23 0x0000000000000001 X24 0x000000003387E000 X25 0x000000003387E3B8 X26 0x000000003387E3C0 X27 0x000000003387E3C8 X28 0x000000003387E3D0 FP 0x000000003B3FEFF0 LR 0x00000000337EB288 V0 0xAFAFAFAFAFAFAFAF AFAFAFAFAFAFAFAF V1 0xFFFFFF80FFFFFFD0 000000003B3FEE90 V2 0x4F43213A4C4C4100 3635324148535F4D V3 0x0000000000000000 0000000000000400 V4 0x0000000100000000 0000000000000000 V5 0x4010040140100401 4010040140100401 V6 0x0100000000000004 0100000000000004 V7 0x0000000000000000 0000000000000000 V8 0x0000000000000000 0000001B00000004 V9 0x0000000000000000 0000000000000000 V10 0x0000000000000000 0000000000000000 V11 0x0000000000000000 0000000000000000 V12 0x0000000000000000 0000000000000000 V13 0x0000000000000000 0000000000000000 V14 0x0000000000000000 0000000000000000 V15 0x0000000000000000 0000000000000000 V16 0x0000000000000000 0000000000000000 V17 0x0000000000000000 0000000000000000 V18 0x0000000000000000 0000000000000000 V19 0x0000000000000000 0000000000000000 V20 0x0000000000000000 0000000000000000 V21 0x0000000000000000 0000000000000000 V22 0x0000000000000000 0000000000000000 V23 0x0000000000000000 0000000000000000 V24 0x0000000000000000 0000000000000000 V25 0x0000000000000000 0000000000000000 V26 0x0000000000000000 0000000000000000 V27 0x0000000000000000 0000000000000000 V28 0x0000000000000000 0000000000000000 V29 0x0000000000000000 0000000000000000 V30 0x0000000000000000 0000000000000000 V31 0x0000000000000000 0000000000000000 SP 0x000000003B3FEFF0 ELR 0x000000003379B000 SPSR 0x60000209 FPSR 0x00000000 ESR 0x8600000F FAR 0x000000003379B000 ESR : EC 0x21 IL 0x1 ISS 0x0000000F Instruction abort: Permission fault, third level Stack dump: 000003B3FEEF0: 0000000000000001 000000003387E000 000000003387E3B8 000000003387E3C0 000003B3FEF10: 000000003387E3C8 000000003387E3D0 000000003B3FEF60 00000000337B11F0 000003B3FEF30: 000000003B3FF038 00000000337A6000 00000000337A6009 000000003385862A 000003B3FEF50: 00000000337AF000 00000000000000DF 000000003B3FEF80 D31AAEC05D36E324 000003B3FEF70: EB867F1A51BB14DB 000000006CA176BC ABA93E539C790EF5 2852AEF3743D7964 000003B3FEF90: A2F2674AB971207B 1125D02FD20A3F40 0000000000000000 0000000000019000 000003B3FEFB0: 0000000000004000 0000000000000400 000010000007EFF0 00000000337B11A0 000003B3FEFD0: 00000000337B1148 00000000337B1140 0000000000000010 00000000337B1098 > 000003B3FEFF0: 000000003B3FF050 00000000337EB338 0000000000000000 0000000033854000 000003B3FF010: 000000003386A000 0000000034B23798 00017F903B3FF050 000000003379B000 000003B3FF030: 0000000033797000 000000000000001A 0000000033900C18 00000000337B1018 000003B3FF050: 000000003B3FF0B0 00000000337EC1B4 0000000000000000 00000000337E9428 000003B3FF070: 000000003387E39F 0000000034B23798 000000003B3FF120 000000003387E000 000003B3FF090: 00000000351B6AC0 000000003525E030 0000000034B2CEA0 0000000035C605A0 000003B3FF0B0: 000000003B3FF150 00000000337E9030 0000000000000001 000000003392B000 000003B3FF0D0: 0000000035C74898 0000000000000001 0000000000000000 0000000000000001 Expected Results: Machine boots
To be clear this seems to be happening on shim in f38/39/rawhide because they are all 15.6-2
There is a PR here: https://src.fedoraproject.org/rpms/shim-unsigned-aarch64/pull-request/2
Proposed as a Blocker for 40-beta by Fedora user pbrobinson using the blocker tracking app because: aarch64 is a blocking archtecture and failing to boot on a bunch of devices is a problem :)
There is a whole Thing with shim: https://bugzilla.redhat.com/show_bug.cgi?id=2113005 pjones cut a new shim version upstream recently, which *probably* means it's coming to Fedora. I hope before F40. if so I'd expect it to fix this as well as 2113005. If not I would guess this would have kinda the same status as 2113005 : we can't fix it because we can't do a new shim build without SB signoff. Though maybe we have a bit more wiggle room for aarch64, I dunno.
+4 in https://pagure.io/fedora-qa/blocker-review/issue/1450 , marking accepted. For the record, I'd say the formal requirement here is "Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures", at https://fedoraproject.org/wiki/Basic_Release_Criteria under "Supported firmware types".
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
So shim 15.8 is released upstream and has been built for x86 but for some reason not aarch64 yet. shim-unsigned-x64-15.8-1
Yeah, I'm assuming pjones is waiting on Microsoft at this point. I *guess* the process goes "build a shim-unsigned, ask Microsoft to sign it, once they do we can build a signed 'shim', which is the thing we actually need".
(In reply to Adam Williamson from comment #8) > Yeah, I'm assuming pjones is waiting on Microsoft at this point. I *guess* > the process goes "build a shim-unsigned, ask Microsoft to sign it, once they > do we can build a signed 'shim', which is the thing we actually need". Yes, but he's not bumped the unsigned aarch64 shim.
FEDORA-2024-2aa28a4cfc (shim-15.8-2, shim-unsigned-aarch64-15.8-2, and 1 more) has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-2aa28a4cfc
FEDORA-2024-2aa28a4cfc has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2aa28a4cfc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-2aa28a4cfc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-2aa28a4cfc (shim-15.8-2, shim-unsigned-aarch64-15.8-2, and 1 more) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
Setting back to ON_QA as this is not stable for anything but F38 yet, and we need to confirm the fix.
(In reply to Adam Williamson from comment #13) > Setting back to ON_QA as this is not stable for anything but F38 yet, and we > need to confirm the fix. Works for me. I downloaded the 15.8 shim-aa64 from koji, installed it, and was able to update my RPi4 to the lastest UEFI emulation and it booted properly (it previously failed to boot because of EFI_MEMORY_ATTRIBUTES_PROTOCOL issue).
That's great news! Thanks for the confirmation. Thus setting VERIFIED.
> update my RPi4 to the lastest UEFI emulation and it booted properly (it > previously failed to boot because of EFI_MEMORY_ATTRIBUTES_PROTOCOL issue). By UEFI emulation do you mean the EDK2 firmware?
(In reply to Peter Robinson from comment #16) > > update my RPi4 to the lastest UEFI emulation and it booted properly (it > > previously failed to boot because of EFI_MEMORY_ATTRIBUTES_PROTOCOL issue). > > By UEFI emulation do you mean the EDK2 firmware? Yes. the pftf/RPi4 repo which runs the EDK2 firmware.
shim 15.8-3 is now tagged stable for every live Fedora release - https://koji.fedoraproject.org/koji/buildinfo?buildID=2423319 - so we can close this.