EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary

I've experienced this after installing Impish host on Raspberry Pi 4 with an Impish VM. The VM was working correctly up until just a moment ago, as I type this, I've installed `linux-modules-extra-raspi in order to get usb serial adapters to work inside the virtual machine. The package installed normally and initrd was created normally as well. Upon reboot, the only thing I see is the error mentioned in this bug report (you can see it if you do: lxc start --attach) and the VM is spinning at 100% CPU but linux is not booting.

@zyga: hm.. I wouldn't expect this to cause a functional problem, perhaps what you are seeing is unrelated. Can you try adding 'earlycon debug' to the kernel command line? If you see messages from the kernel with that, it's likely something else.

The error still occurs when installing https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/jammy-live-server-arm64.iso when booting the installer kernel.

2.06-2ubuntu5 should fix this issue for insecure boot cases, a future version will also fix secure boot use cases, but the new code is undergoing security review.

SRUs might pick up the new code, or use the rhboot code, not decided yet.

This bug was fixed in the package grub2 - 2.06-2ubuntu5

---------------
grub2 (2.06-2ubuntu5) jammy; urgency=medium

  [ Julian Andres Klode ]
  * Free correct size when freeing params, rather than 16 Ki (LP: #1958623)
  * Build with FUSE3 (LP: #1935659)
  * Only run os-prober on first run and if it previously found other OS
    (LP: #1955109)

  [ Heinrich Schuchardt ]
  * Rename grub-core/loader/efi/linux.c
  * Add patches for GRUB on RISC-V
  * fat: fix listing the root directory
  * Enable building for RISC-V (LP: #1876620)

  [ Julian Andres Klode ]
  * Re-enable peimage code on other archs outside secure boot; this
    fixes LP: #1947046 when not booting in secure boot mode (secure
    boot pending security review of the code)

 -- Julian Andres Klode <email address hidden> Fri, 18 Feb 2022 17:21:16 +0100

Good afternoon,

This also effects the https://cdimage.ubuntu.com/daily-live/current/jammy-desktop-arm64.iso
image. Currently I can boot debian arm64 UEFI ISOs and Fedora, but not the Jammy cd image using PI uefi.

Any idea when this fix will be incorporated on the ISO so can do further testing?

Kind regards,

  Pascal van Dam

According to reports in https://github.com/lima-vm/lima/issues/712 , this issue seems also affecting Impish kernel 5.13.0-35.40 and Focal kernel 5.4.0-103.117 .

Could you backport the fix to Impish and Focal, and release a new cloud image (https://cloud-images.ubuntu.com/releases/) ?

No, that fix is not reviewed for secure boot yet, but maybe we can cherry pick the other fixes.

Sorry, https://github.com/lima-vm/lima/issues/712 might not be related to this issue.

The reporters of https://github.com/lima-vm/lima/issues/712 say that the kernel doesn't boot at all after seeing the "EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary" lines.

They are using M1 macOS version of QEMU (https://gitlab.com/qemu-project/qemu/-/issues/899).

This also effects the https://cdimage.ubuntu.com/daily-live/current/jammy-desktop-arm64.iso

is there any fix to it yet?

Focal HWE kernels (5.15) are also affected with this issue. Is there a chance we can back-port this to Focal as well?

This is included in focal-proposed with the 2.06-2ubuntu14 backport. For technical reasons, due to binary copying the version around, only a tracking bug and a handful more are being notified and verified and closed. To see the status, please track the grub2-unsigned tasks in

bug #1996950

Hi

I found this issue is still not fixed.
Launch a VM with secure boot enabled on an arm64 machine running jammy, it shows the following:

BdsDxe: loading Boot0008 "ubuntu" from HD(15,GPT,5570F84F-4616-4E20-AD7E-CF915E637099,0x800,0x31801)/\EFI\ubuntu\shimaa64.efi
BdsDxe: starting Boot0008 "ubuntu" from HD(15,GPT,5570F84F-4616-4E20-AD7E-CF915E637099,0x800,0x31801)/\EFI\ubuntu\shimaa64.efi
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary <========
EFI stub: UEFI Secure Boot is enabled.
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
EFI stub: UEFI Secure Boot is enabled.
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd082]
[ 0.000000] Linux version 5.15.0-91-generic (buildd@bos03-arm64-015) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #101-Ubuntu SMP Tue Nov 14 13:29:11 UTC 2023 (Ubuntu 5.15.0-91.101-generic 5.15.131)

The fix mentioned in the bug description is not in the current grub code
https://github.com/rhboot/grub2/commit/6a5babc21e3ec665e0bae30e399db296451c121e

I also found this commit is not merged into upstream master branch, instead it's merged into rhel-9.x.x
and fedora-37 and later

Could we SRU it to our grub?
The commit needs to be modified a bit based on our current grub code, I will attach a diff for grub-core/loader/efi/linux.c which is a modified version of the above commit.
With this I can confirm it fixes the error message
EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary

I will also modify the bug description regarding the reproducer

Thanks,
Gerald

Hi Julian,

Could you help to review the above comments, thanks!

There was some state mix up but grub2 was fixed in jammy already, it's grub2-unsigned, specifically the loader that it used on secure boot that was not fixed.

I'll discuss this with Mate if that's worth fixing. It's a cosmetic issue, the patch is large, and all that code has been ripped out in 2.12.

Thanks for your patch but I'm afraid it won't be much use, we'll have to start from scratch with cherty-picking the commit properly in the patch queue git branch.

Understood, thank you Julian for reviewing this

Hi Gerald,

I'd prefer to live with the message and not SRU this.

The code being touched is in the boot path of every EFI machine, the diff is rather large, and messes with early boot memory allocation.

I don't feel comfortable with the regression potential, especially since this appears to be a merely cosmetic issue.

Mate

Some more context:

- dannf experienced this bug on a non-securely booting system, hence the fix applied for the bug (enabling peimage on arm64) solved it for him, that's why we closed it.

- we will backport 2.12 which has peimage on secure boot platforms in the coming months which will also fix the issue on secure boot platforms

Thanks Mate and Julian for the review and explanations

Should the jammy task be "Won't Fix" if the plan is to backport 2.12 which will fix it? Or is 2.12 not going back to jammy for some reason?

I think it's fine either way but the backports generally don't close the bug reports because then the SRU team gives up reviewing them with tens of bugs. Basically while we pass -v, we hand edit the changes to remove references to all bugs except the tracking one (or we forget to pass -v either way).

Hi Julian,

Is there any way that we can check the grub 2.12 backport status/progress, so we can keep our customers posted?

Thanks,
Gerald

Hi Gerald,

2.12 updates for stable releases should happen some time after the 24.04 release, early unsigned backports are in

https://launchpad.net/~ubuntu-uefi-team/+archive/ubuntu/backports-build

I was hoping we'd have signed backports in the

https://launchpad.net/~ubuntu-uefi-team/+archive/ubuntu/backports-proposed-public

now for easier testing, but the priority right now I think is to get 24.04 released.

Hi Julian,

Thank you very much for the info, I will update our customers about this