On Mi, 01.07.20 14:45, Hans de Goede (hdegoede(a)redhat.com) wrote:
I'm not in the bootloader-team, but I do work very closely with
so I have only one question: who is going to pick up the extra
maintenance load this is going to cause ?
There are distros already using it. And so far we have been pretty OK
with supporting it upstream and downstream. At least upstream I am not
aware of any big issues left open.
Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain
Turing complete programming languages, module loaders, file system
drivers, storage stacks and such. There's simply not that much to
Also note that this entails a lot more work then just maintaining
anaconda will need to be adjusted, kernel-install scripts will need to
be adjusted, etc.
kernel-install itself is actually maintained in the same repo as
sd-boot: systemd upstream. They are developed along the same lines
Also I wonder, if you are not proposing to completely drop grub2 on
x86_64 what does offering sd-boot in addition to grub2 actually
offer as advantages?
Primarily simplicity, and that it implements the boot loader spec
it automatically discovers windows and Macos installations at each
boot, without any userspace involvement. You can talk to it very
nicely, i.e. implement trivially "boot-into-windows" buttons and such
in GNOME and so on. It makes things very robust, since you don't need
a script that generates a script that generates a script (yeah, that's
how grub is hooked up). it just works on its own. You drop in boot
menu items, and that's it. You don't need to regenerate stuff, and you
never have to run an interpretor for a turing complete language.
By using sd-boot, you can do stuff like "systemctl reboot
--boot-loader-entry=windows", you can do "systemctl reboot
--boot-loader-menu=0", you can do "systemctl kexec" and it boots the
right thing, and so on.
It also implements boot time assessement that is simple and just works
(i.e. automatic revert to previous boot menu choice when the one
selected doesn't work).
Oh, and it as support for seeding the Linux random seed pre-boot
already, in a safe and simple fashion.
Moreover, it communicates which ESP is used to the host OS, so that
the host can automatically discover what other partitions to mount.
And the list goes on and on and on.
All these features are very simple individually, but put together they
are just a much nicer and expose a much more integrated behaviour
than Grub ever did.
sd-boot is simpler and a bit tighter integrated with systemd, which
mean it is less work to maintain if we use it instead of grub, but if we
use it next to grub then all those advantages fall away. IOW if we use
it next to grub then all I see is a whole lot of extra work, with very
Well, you appear to believe in the race to the bottom, i.e. that the
lowest common denominator should be where the future is. I am pretty
sure it's the wrong approach: pick the simple contender that can do
all the nice things, and has the nice integration, and use it as a
blueprint for the other archs where Grub is still needed, and make
them catch up.
I mean, I understand you are interested in exotic platforms that lack
modern things like UEFI, but it kinda sucks to hold the boot loader
hostage due to that, and just stick to the terrible ways of yesteryear
because of it.
AFAIK this (lot of extra work, very little gain) is exactly why we
been sticking with grub2 so far. We need to maintain it anyway, at which
point we want to use it in as much cases as possible so that we can have
unified code and documentation for dealing with the bootloader.
I don't see "very little gain". I see a lot of gain, and all while
things become simpler. Much simpler.
Lennart Poettering, Berlin