[PATCH] x86_64: add systemd-boot images

[Jonas Lochmann]

Am Tue, Dec 30, 2025 at 09:15:55AM -0800, schrieb Elliott Mitchell:
> > Yes, that's the main motivation. Unlike grub, it only supports UEFI
> > boot but this is the only boot method supported by recent x86 hardware.
> 
> The motherboard on this system is 3 years old yet will still boot using
> the traditional bootsector.  Some things are disabled in that mode, but
> it can still boot without UEFI.  This though isn't a bottom tier
> motherboard bought with price as the only criterion, nor is this a laptop
> which comes with fewer options.

"Starting with server platforms launching in 2020, Intel began phasing out
support for Legacy Boot Mode. Starting with server platforms launching in
2024, Intel has discontinued support of Legacy Boot Mode in all segments." [1]

> Depends on the hypervisor and its configuration.  Both GRUB and
> Tianocore/EDK2 have been ported to be directly loadable by at least one
> hypervisor and serve as the first stage loader.  If GRUB is the first
> stage, then grub.cfg is the first OpenWRT built piece to be loaded.
> If Tianocore/EDK2 is the first stage, then it will be UEFI-only.

I know the theoretical option of loading grub as first stage in
hypervisors and early in physical hardware. I never saw this beeing used
in practice.

> On the surface the patch didn't look too problematic, but beware of
> making needless changes with booting.  Of note SuSE chose to use
> "grub2.cfg" and has invested significant energy in keeping that.
> Resulting in pull #3791 which I'm unsure of working around a SuSE bug in
> OpenWRT.

That's why this is a new independent image type. Hybrid booting grub
for legacy systems and systemd-boot for uefi would be possible, but
useless.

PR #3791 [2] is for using other grub builds? I would absolutely avoid
that. It's like booting one distribution with another ones grub. It can
work for a moment, but I would not expect it to be stable. I consider
basic things like efi files the best possible entry point. The linux
kernel itself can be executed by the uefi, but then I can not specify
the command line parameters while still using the default path.
systemd-boot is just used as a helper to fill this gap - read a config
file and tell the uefi to load the actual kernel. It is possible to
develop an own solution for this step - but it's not worth it.

[1] https://cdrdv2-public.intel.com/630266/630266_WW31_2023.pdf
[2] https://github.com/openwrt/openwrt/pull/3791/files