Hi,
I’ve created a UKI for booting a kernel,initramfs & dtb that work fine in bls mode. However trying to boot the UKI fails - no output just a reboot after about 15 seconds.
Is it possible to boot UKIs on the 20250120 firmware?
If so, are there any limitations on doing so? (e.g. memory size limits, timer watchdogs) or known firmware bugs that would prevent successful UKI boots?
On Q6A the kernel is booted by UEFI bootloader (grub2/systemd-boot/embloader), so it should not be a firmware problem.
You can try switching to different bootloader and see if the issue resolves. Also check your process on x64 VM.
Hi - thanks for the reply 
Booting a bootloader from UEFI is fine. I can boot into both systemd-boot and grub2 and run the OS from there.
What I’m asking about are UKI (Unified Kernel Image) booting where the kernel, initrd and dtb are combined into a single image that is itself a UEFI executable, and should be executablef from UEFI just like the bootloaders are. Normally this method can be used to boot a kernel directly rather than indirectly through a bootloader. When the UKI is run by the UEFI firmware the kernel extracts itself and the initrd and begins the boot process.
Is booting a UKI supported on this board? The firmware shouldn’t really care as it’s just another UEFI executable. I just wondered if there was some limitation such as timing or memory space.
I have not tested UKI boot so I can’t tell. However, our BIOS has been able to boot grub, sdboot, and another 3rd party UEFI bootloader (embloader), so I intend to believe it should be fine on that regard. What does the serial log say when you try booting it?
Haven’t got any serial access. However I do agree that it’s unlikely to be firmware which appears to handle other UEFI executables just fine - the UKI should be no different, it’s just bigger. I suspect the stub loader is failing somehow and am investigating that at the moment.
I am still trying to source serial access however the issue has been narrowed down to something in the systemd stub loader, or its interaction with the firmware.
linuxaa64.efi.stub (systemd 260) produces no output and causes silent reboot when loaded as a UEFI application on firmware version 6.0.260120. Direct zboot kernel and systemd-boot work correctly. Problem is reproducible with a minimal 5.5MB UKI containing only kernel+cmdline+DTB.
Could it be an incompatibility between the firmware’s loaded image protocol implementation and systemd-stub’s initialisation sequence? Are there memory limitations?
@strongtz have you seen this on your Arch system?
No, but I only tried GRUB2 and embloader on Arch. I’ll try if UKI works here.
Thank you for taking this seriously and looking into this, it’s appreciated.
If it helps at all here’s the deal so far:
Test configuration:
Conclusion: systemd-stub fails regardless of UKI contents.
Firmware version: 260120
Thank you for the report. I have reproduced the issue on my side as well. It does appear to be a firmware issue. I will investigate it further and work on a fix.
Thanks for the quick reply.
I’ll look forward to the fix as UKI is the primary boot method on my other systems and it would be nice to be consistent.