On Wed, 2020-07-01 at 16:30 +0200, Lennart Poettering wrote: > On Mi, 01.07.20 14:45, Hans de Goede (hdego...@redhat.com) wrote: > > > I'm not in the bootloader-team, but I do work very closely with > > them, > > 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 > maintain! > > > Also note that this entails a lot more work then just maintaining > > sd-boot, > > 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 > already. > > > 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 > correctly. > > 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 > > would > > 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 > > 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 > yesteryear > because of it.
Note that this is not only about exotic platforms. I can give you examples with: 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 systems. Best regards, Nikolay _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
