[PATCH] x86_64: add systemd-boot images

[Elliott Mitchell]

On Tue, Dec 30, 2025 at 07:51:29PM +0100, Jonas Lochmann wrote:
> 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]

I'm well-aware x86 bootsector booting is being killed.  UEFI is better in
several ways, but rather higher overhead.  Yet it was still possible to
purchase current-generation hardware with bootsector support.  I also
note that is *Intel*, not every company which has ever produced an
x86-compatible processor.

Not a strong argument, merely a comment bootsector will be around a long
time.  OpenWRT x86 images in theory support hardware manufactured in
1995, so bootsector support will need to stick around a long time.


> > 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.

I guess this shows we're in different circles.  GRUB-PV is recommended
for booting Linux images on Xen, most Linux distributions document this
and have packages available.


> > 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

Such is quite stable.  Unlike Python, GRUBv2's configuration file syntax
has been quite stable.  Since 2.0 most changes have been bugfixes and
module additions.  There was talk of chainloading the VM's version of
GRUB to ensure compatibility, but to my knowledge that has merely been
proposed.


> 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.

There is one key thing which GRUB allows, but this doesn't claim to.
GRUB allows having multiple kernels installed and choosing between them.
Not too urgent for most OpenWRT targets, but critical kernel bugs do
show up.  Being able to keep an older known working kernel around has
been extremely helpful.

This might mostly be an issue for x86 which has a great deal of drivers
available and plenty of space to keep one or two older kernels around.
Yet for x86 it is big win.

(typing as someone who recently ran into such a severe bug)


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445