On Thu, Jun 10, 2021 at 05:41:45AM -0000, Luya Tshimbalanga wrote: > Hello team, > > Fedora Design lab maintainer here. I recently replaced GRUB2 by systemd-boot following this [instruction](https://kowalski7cc.xyz/blog/systemd-boot-fedora-32). > I had to remove shim after backing up otherwise secure boot prevent systemd-boot to execute. > The experience is completely refreshing seen the boot screen instead of the bootloader (activated by holding escape button on a start-up). It will be much better with secure boot available for. > Will it be time to use it on Workstation as alternate bootloader for device running on EFI? The ideal will be fore Fedora 35 but Fedora 36 may be the fallback. I think this would be something worth pursing… sd-boot has a smaller set of capabilities, but for the cases it covers, it works rather well. The scheme is simple, so there is less things to break, and its easy to introspect/reconfigure the boot loader from user space (e.g. 'bootctl list').

On Thu, Jun 10, 2021 at 3:13 PM Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote: > > On Thu, 2021-06-10 at 07:38 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jun 10, 2021 at 05:41:45AM -0000, Luya Tshimbalanga wrote: > > > Hello team, > > > > > > Fedora Design lab maintainer here. I recently replaced GRUB2 by systemd-boot following this [instruction](https://kowalski7cc.xyz/blog/systemd-boot-fedora-32). > > > I had to remove shim after backing up otherwise secure boot prevent systemd-boot to execute. > > > The experience is completely refreshing seen the boot screen instead of the bootloader (activated by holding escape button on a start-up). It will be much better with secure boot available for. > > > Will it be time to use it on Workstation as alternate bootloader for device running on EFI? The ideal will be fore Fedora 35 but Fedora 36 may be the fallback. > > > > I think this would be something worth pursing… sd-boot has a smaller > > set of capabilities, but for the cases it covers, it works rather well. > > The scheme is simple, so there is less things to break, and its easy > > to introspect/reconfigure the boot loader from user space (e.g. 'bootctl list'). > > The problem with this is that its smaller set of breakage possibilities > just gets added to grub's existing large set of breakage possibilities > to give us a SUPER large set of breakage possibilities. For a > distribution, adding choice can only possibly result in *more* > potential problems (and more engineering work, and more QA time), never > *fewer*. This is the http://islinuxaboutchoice.com/ problem. > > It's only worth adding a choice if that choice makes life so much > better for someone that it's *worth taking on* the additional work. Is > that really the case for a bootloader? If I were going to advocate for a change, I would: * Advocate for rEFInd instead of sd-boot or grub2 * Switch to emulated UEFI on BIOS systems ** edk2 provides a fake UEFI implementation for BIOS Otherwise, it's just not worth it.

While there's a lot of complexity in GRUB that gives us lots of grief, and Fedora is still carrying >100 patches on top of upstream GRUB, and rebasing to upstream is therefore also complicated and can involve regressions... I think it would be a lot of work to switch bootloaders. And it is too much work to offer an additional bootloader and support it in any official way, other than in a quickdoc for those who want to opt in. I suggest starting with the quickdoc approach though, because it gets more users familiar with the alternative. I'm pretty sure the bootloader team can't take on another bootloader right now. The work on incorporating Boot Loader Spec has put Fedora in a better position to switch to a different bootloader down the road. There are a number of use cases that sd-boot doesn't support and won't support, at least not directly: * has no file system support; so we can't boot off an ext4, xfs, btrfs /boot volume. Or software raid. All of which we do support today. Getting rid of these use cases would simplify things a lot but it comes with consequences. Could we enhance sd-boot so it can use efifs, and therefore support these file systems? Is it worth it? If not, then: * /boot becomes FAT32. We can mount FAT file systems using -o context, for selinux MAC. (And possibly the new mount_setattr(2) call in kernel 5.12 to set ID's). But I don't know if this is considered adequate by security folks. Maybe it becomes more workable with bootupd, but then are we just rearranging the deck chairs that we need to depend on three projects to boot the way we want rather than one? I can get on board dropping GRUB as a bootloader but it has to be really compelling.