On Wed, 2020-07-01 at 16:30 +0200, Lennart Poettering wrote:
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
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
> 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,
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
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
(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
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
> it next to grub then all I see is a whole lot of extra work, with
> little gain.
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
because of it.
Note that this is not only about exotic platforms. I can give you
1. My 2019 HP laptop with an AMD Ryzen CPU. Purchased without Windows,
so it came with FreeDOS preinstalled. Obviously, FreeDOS only runs in
legacy mode. I just booted from an USB flash drive and installed Fedora
on it, without changing the BIOS settings.
2. A 2017 Dell laptop, purchased also without Windows. Came with Ubuntu
preinstalled, also in legacy mode. I installed Fedora on it, also
without changing the BIOS settings.
It's not unrealistic to expect that a lot of people would buy laptops
such as these, if they specifically want to run Linux. And it's not
unrealistic to expect many users to just install Fedora without
changing any BIOS settings, related to legacy vs UEFI boot mode. In
fact, most users wouldn't probably know anything about these settings.
Both of these computers are very far away from being considered legacy
or exotic. They can be switched to UEFI mode, but that requires
repartitioning and an OS reinstall (and that gets very complicated when
you consider multiboot scenarios with Windows 10 as well). Upgrading
these systems without reinstall is possible, but *very* difficult and
can't be automated, because, even if in the single OS scenario, it
requires the user to change the BIOS settings to disable legacy boot.
Note that I don't disagree with the general idea of simplifying
bootloader configuration. But it's not at all realistic to drop legacy
BIOS support anytime soon, and it isn't about legacy and exotic