Description of problem: Linux 5.7rc1 has a new commit c2136dceba9a3 "efi/libstub/arm: Avoid image_base value from efi_loaded_image" which is verifying the efi_loaded_images structure's image base field. 30 seconds of investigation make it appear that the comment in the bug about this being caused by older grub builds is what is happening on fedora. I see this on two different aarch64/edk2 machines (one is the rpi4/pftf build, which at first pass looks correct). Version-Release number of selected component (if applicable): F32+5.7rc1 How reproducible: 100% of the time during boot. Steps to Reproduce: 1. Install a f32 + a bleeding edge kernel 2. Boot machine, pay attention to messages from the kernel stub being displayed on the serial port. 3. Actual results: EFI stub: Booting Linux Kernel... EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... Expected results: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... Additional info:
This is easily reproducible with edk2-ovmf and qemu-system-aarch64. With the latest GRUB in Fedora Rawhide I get the output mentioned in the bug description: EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... and the issue is not present with upstream GRUB: EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... so one of the patches in the Fedora grub2 package seems to be the culprit.
I found the issue. Upstream GRUB uses the EFI LoadImage() and StartImage() services to boot the Linux kernel, but we have a custom EFI loader to support Secure Boot that instead uses the EFI handover protocol (for x86) or jumping directly to the PE/COFF entry point (for aarch64). This is done to allow the bootloader to verify the images using the shim lock protocol to avoid booting untrusted binaries. So since LoadImage() is not used and the Loaded Image base address is set by the firmware when that service is called, GRUB should set the base address. I'll attach a patch fixing this and also a scratch build for testing.
Created attachment 1681173 [details] [PATCH] efi: Set image base address before jumping to the PE/COFF entry point
Created attachment 1681174 [details] grub2-efi-aa64-2.04-14.fc33.aarch64.rpm
Changing the Version to Rawhide since the issue happens since v5.7-rc1 (already in Rawhide) but F32 still has v5.6.
FEDORA-2020-e38f21d14d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e38f21d14d
FEDORA-2020-e38f21d14d has been pushed to the Fedora 32 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-e38f21d14d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e38f21d14d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-e38f21d14d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
See this bug again with hpe servers https://beaker.engineering.redhat.com/jobs/4704179, others servers are fine:https://beaker.engineering.redhat.com/jobs/4704271. I checked f32 and f33 on the failed hpe servers, both work well.
(In reply to lnie from comment #9) > See this bug again with hpe servers > https://beaker.engineering.redhat.com/jobs/4704179, > others servers are fine:https://beaker.engineering.redhat.com/jobs/4704271. Unfortunately these logs have been already removed. I'ts better to share the relevant logs. > I checked f32 and f33 on the failed hpe servers, both work well. All Fedora branches since F32 have the relevant fix. Can you please share the kernel version used in all cases to check if there was a change there ?
>Unfortunately these logs have been already removed. I'ts better to share the relevant logs. Sure, here is one rawhide job: https://beaker.engineering.redhat.com/jobs/4937337 and here is one successful f33 job: https://beaker.engineering.redhat.com/jobs/4937353 >All Fedora branches since F32 have the relevant fix. Can you please share the kernel version used in all cases to check if there was a change there ? I've checked,the f33 job has kernel-5.9.16-200.fc33 installed,while rawhide has kernel-5.10.0-0.rc6.20201204git34816d20f173.92.fc34, if I get kernel-5.10.4-200.fc33 from koji and install it to the f33 server and reboot it,the server will stuck as follows: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map...
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
This should had been fixed by now, if the issue persists feel free to re-open the bug.