Phenomenon

This happened in the implementation of LinuxBoot on QEMU-ARM64.
When I replace UEFI shell with my Linux kernel Image, I found a weird Phenomenon:

Succeed:  UEFI(DT) ------> Kernel+U-root (Image) ---kexec---> Ubuntu

Fail: UEFI(ACPI) ------> Kernel+U-root (Image) ---x---> Ubuntu

Succeed: UEFI(ACPI) --grub--> Ubuntu --kexec--> Kernel+U-root (Image) --kexec--> Ubuntu

• The UEFI -->Kernel+U-Root means UEFI directly boot Kernel after BDS phase by EFI_stub.
• When I used the UEFI that use ACPI to config kernel, the first kernel would fail to boot Ubuntu by kexec, without any message.
• But when I first boot Ubuntu, then boot my little kernel ( I put the kernel Image in a virtual disk so Ubuntu can find this file ), then boot Ubuntu again, it would work well.

Reason

When UEFI using ACPI to config kernel, the kernel will generate an empty DT which contains some EFI map messages, command line, physical address for Linux, etc.

However, when Ubuntu is booted by grub, the fdt file (empty DT) it generated contains a node called "uefi-secure-boot", which cannot be generated by the kernel built by my own.

Thus, when my Linux with u-root is booting Ubuntu by kexec, Ubuntu cannot find the "uefi-secure-boot" node from the fdt, and consequently goes wrong.

Temporary solution

I commented the line blow in the source code of Ubuntu, then reinstalled Ubuntu.

UEFI_PARAM("Secure Boot Enabled", "linux,uefi-secure-boot", secure_boot)

Thus Ubuntu would not try to find this node and could be successfully booted by my Linux kernel.

Suggestion

The true solution to this problem is supposed to be modifying the source code of Linux kernel built on my own, to generate an additional "uefi-secure-boot" node.

This problem is important for LinuxBoot because it means we have to customize the Linux kernel in firmware to adapt to various target Runtime OS like Ubuntu and CentOS.

I just discovered the problem when I implemented LinuxBoot on ARM64. I hope this group could take it into consideration and come out with a good solution.