[Bug 2101209] [NEW] grub2 can not boot arm Linux kernel

Sat Mar 8 09:42:06 UTC 2025

Public bug reported:

I found that grub2 can not boot arm Linux kernel due to inconsistent
header definition.

I downloaded the image below and tried to use it in qemu.

https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-
armhf.img

$ qemu-system-armhf -m 2048 -cpu cortex-a15 -M virt \
    -drive if=pflash,format=raw,file=/usr/share/AAVMF/AAVMF32_CODE.fd,readonly=on \
    -drive if=pflash,format=raw,file=AAVMF32_VARS.fd \
    -drive if=none,file=focal-server-cloudimg-armhf.img,id=hd0 \
    -device virtio-blk-device,drive=hd0 \
    -netdev type=tap,id=net0 \
    -device virtio-net-device,netdev=net0

qemu can run grub2 successfully but there's error message after "Loading
initrd".

I troubleshooted this issue with gdb and found that the kernel
(vmlinuz-5.4-205-generic-lpae) contains a PE header but grub2's
corresponding header definition listed below is inconsistent with the PE
header:

struct linux_arm_kernel_header {
    grub_uint32_t code0;
    grub_uint32_t reserved1[8];
    grub_uint32_t magic;
    grub_uint32_t start;
    grub_uint32_t end;
    grub_uint32_t reserved2[4];
    grub_uint32_t hdr_offset;
}

grub2 tries to calculate PE header address by using field hdr_offset but
as you can see from the hex dump below hdr_offset points to "PE":

Hex View  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F

00000000  4D 5A 25 E2 4D 5A 25 E2  00 00 A0 E1 00 00 A0 E1  MZ%.MZ%.........
00000010  00 00 A0 E1 00 00 A0 E1  00 00 A0 E1 00 00 A0 E1  ................
00000020  F6 03 00 EA 18 28 6F 01  00 00 00 00 00 02 A4 00  .....(o.........
00000030  01 02 03 04 45 45 45 45  78 B8 00 00 40 00 00 00  ....EEEEx... at ...
00000040  50 45 00 00 C2 01 02 00  00 00 00 00 00 00 00 00  PE..............
00000050  00 00 00 00 90 00 06 03  0B 01 02 14 00 F0 A3 00  ................
00000060  00 14 00 00 00 00 00 00  34 19 00 00 00 10 00 00  ........4.......
00000070  00 00 A4 00 00 00 00 00  00 10 00 00 00 02 00 00  ................

I also found a patch which change reserved2[4] to reserved[3]:
https://lore.kernel.org/linux-efi/20201104123105.GU1664@vanye/t/

This inconsistency will lead to incorrect handover_offset so the kernel
are not executed correctly.

I tried to mitigate this issue by fixing handover_offset in gdb and
grub2 ran EFI stub correctly and displayed following messages:

EFI stub: Booting Linux Kernel...
...
EFI stub: Exiting boot services and installing virtual address map...

The kernel hanged after this message and I have not figure out the root
cause.

** Affects: grub2 (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  I found that grub2 can not boot arm Linux kernel due to inconsistent
  header definition.

  I downloaded the image below and tried to use it in qemu.

  https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-
  armhf.img

  $ qemu-system-armhf -m 2048 -cpu cortex-a15 -M virt \
-     -drive if=pflash,format=raw,file=/usr/share/AAVMF/AAVMF32_CODE.fd,readonly=on \
-     -drive if=pflash,format=raw,file=AAVMF32_VARS.fd \
-     -drive if=none,file=focal-server-cloudimg-armhf.img,id=hd0 \
-     -device virtio-blk-device,drive=hd0 \
-     -netdev type=tap,id=net0 \
-     -device virtio-net-device,netdev=net0
+     -drive if=pflash,format=raw,file=/usr/share/AAVMF/AAVMF32_CODE.fd,readonly=on \
+     -drive if=pflash,format=raw,file=AAVMF32_VARS.fd \
+     -drive if=none,file=focal-server-cloudimg-armhf.img,id=hd0 \
+     -device virtio-blk-device,drive=hd0 \
+     -netdev type=tap,id=net0 \
+     -device virtio-net-device,netdev=net0

  qemu can run grub2 successfully but there's error message after "Loading
  initrd".

  I troubleshooted this issue with gdb and found that the kernel
  (vmlinuz-5.4-205-generic-lpae) contains a PE header but grub2's
  corresponding header definition listed below is inconsistent with the PE
  header:

  struct linux_arm_kernel_header {
-     grub_uint32_t code0;
-     grub_uint32_t reserved1[8];
-     grub_uint32_t magic;
-     grub_uint32_t start;
-     grub_uint32_t end;
-     grub_uint32_t reserved2[4];
-     grub_uint32_t hdr_offset;
+     grub_uint32_t code0;
+     grub_uint32_t reserved1[8];
+     grub_uint32_t magic;
+     grub_uint32_t start;
+     grub_uint32_t end;
+     grub_uint32_t reserved2[4];
+     grub_uint32_t hdr_offset;
  }

  grub2 tries to calculate PE header address by using field hdr_offset but
  as you can see from the hex dump below hdr_offset points to "PE":

  Hex View  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
-  
+ 
  00000000  4D 5A 25 E2 4D 5A 25 E2  00 00 A0 E1 00 00 A0 E1  MZ%.MZ%.........
  00000010  00 00 A0 E1 00 00 A0 E1  00 00 A0 E1 00 00 A0 E1  ................
  00000020  F6 03 00 EA 18 28 6F 01  00 00 00 00 00 02 A4 00  .....(o.........
  00000030  01 02 03 04 45 45 45 45  78 B8 00 00 40 00 00 00  ....EEEEx... at ...
  00000040  50 45 00 00 C2 01 02 00  00 00 00 00 00 00 00 00  PE..............
  00000050  00 00 00 00 90 00 06 03  0B 01 02 14 00 F0 A3 00  ................
  00000060  00 14 00 00 00 00 00 00  34 19 00 00 00 10 00 00  ........4.......
  00000070  00 00 A4 00 00 00 00 00  00 10 00 00 00 02 00 00  ................

  I also found a patch which change reserved2[4] to reserved[3]:
  https://lore.kernel.org/linux-efi/20201104123105.GU1664@vanye/t/

- This inconsistency will lead to an incorrect handover_offset so the
- kernel are not executed correctly.
+ This inconsistency will lead to incorrect handover_offset so the kernel
+ are not executed correctly.

  I tried to mitigate this issue by fixing handover_offset in gdb and
  grub2 ran EFI stub correctly and displayed following messages:

  EFI stub: Booting Linux Kernel...
  ...
  EFI stub: Exiting boot services and installing virtual address map...

  The kernel hanged after this message and I have not figure out the root
  cause.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/2101209

Title:
  grub2 can not boot arm Linux kernel

Status in grub2 package in Ubuntu:
  New

Bug description:
  I found that grub2 can not boot arm Linux kernel due to inconsistent
  header definition.

  I downloaded the image below and tried to use it in qemu.

  https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-
  armhf.img

  $ qemu-system-armhf -m 2048 -cpu cortex-a15 -M virt \
      -drive if=pflash,format=raw,file=/usr/share/AAVMF/AAVMF32_CODE.fd,readonly=on \
      -drive if=pflash,format=raw,file=AAVMF32_VARS.fd \
      -drive if=none,file=focal-server-cloudimg-armhf.img,id=hd0 \
      -device virtio-blk-device,drive=hd0 \
      -netdev type=tap,id=net0 \
      -device virtio-net-device,netdev=net0

  qemu can run grub2 successfully but there's error message after
  "Loading initrd".

  I troubleshooted this issue with gdb and found that the kernel
  (vmlinuz-5.4-205-generic-lpae) contains a PE header but grub2's
  corresponding header definition listed below is inconsistent with the
  PE header:

  struct linux_arm_kernel_header {
      grub_uint32_t code0;
      grub_uint32_t reserved1[8];
      grub_uint32_t magic;
      grub_uint32_t start;
      grub_uint32_t end;
      grub_uint32_t reserved2[4];
      grub_uint32_t hdr_offset;
  }

  grub2 tries to calculate PE header address by using field hdr_offset
  but as you can see from the hex dump below hdr_offset points to "PE":

  Hex View  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F

  00000000  4D 5A 25 E2 4D 5A 25 E2  00 00 A0 E1 00 00 A0 E1  MZ%.MZ%.........
  00000010  00 00 A0 E1 00 00 A0 E1  00 00 A0 E1 00 00 A0 E1  ................
  00000020  F6 03 00 EA 18 28 6F 01  00 00 00 00 00 02 A4 00  .....(o.........
  00000030  01 02 03 04 45 45 45 45  78 B8 00 00 40 00 00 00  ....EEEEx... at ...
  00000040  50 45 00 00 C2 01 02 00  00 00 00 00 00 00 00 00  PE..............
  00000050  00 00 00 00 90 00 06 03  0B 01 02 14 00 F0 A3 00  ................
  00000060  00 14 00 00 00 00 00 00  34 19 00 00 00 10 00 00  ........4.......
  00000070  00 00 A4 00 00 00 00 00  00 10 00 00 00 02 00 00  ................

  I also found a patch which change reserved2[4] to reserved[3]:
  https://lore.kernel.org/linux-efi/20201104123105.GU1664@vanye/t/

  This inconsistency will lead to incorrect handover_offset so the
  kernel are not executed correctly.

  I tried to mitigate this issue by fixing handover_offset in gdb and
  grub2 ran EFI stub correctly and displayed following messages:

  EFI stub: Booting Linux Kernel...
  ...
  EFI stub: Exiting boot services and installing virtual address map...

  The kernel hanged after this message and I have not figure out the
  root cause.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2101209/+subscriptions