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.
Luya
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').
That said, we should probably do some things before making it more widely used: - improve the boot editor on hidpi screens (we try to autoselect some appropriate resolution, but this doesn't seem to work too well. Somebody who knows uefi should look into this). - set up automated testing on real hardware (or add to QA SOPs?). - make the setup on Fedora automatic with some one-liner. - make the grub2 and shim packages not brick sd-boot on their updates. - sign sd-boot so shim can boot it (?)
I think it's all doable, and none of those points are hard requirements really. But it'd need to people who want to drive this forward. I'm doing most of the maintenance work for systemd in Fedora, and I can't take this on myself.
Zbyszek
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?
On Thu, Jun 10, 2021 at 3:13 PM Adam Williamson adamwill@fedoraproject.org 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.
On Thu, Jun 10, 2021 at 8:22 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jun 10, 2021 at 3:13 PM Adam Williamson adamwill@fedoraproject.org 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.
Who's going to do all the extra engineering work on top of the original proposal, it's a quite a difference, but either way it adds a lot of extra for QE and others.
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.
[1] https://github.com/pbatard/efifs [2] https://github.com/coreos/bootupd/
Chris Murphy
On Fri, Jun 11, 2021 at 3:33 AM Chris Murphy lists@colorremedies.com wrote:
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.
You miss a number of other things that would require us to keep grub, one big one in particular is that it only supports UEFI booting. With the opposition and associated "discussion" to dropping BIOS support you've missed probably the biggest problem which is systems that aren't UEFI, there's also POWER and s390x in there.
On Fri, Jun 11, 2021, 1:10 AM Peter Robinson pbrobinson@gmail.com wrote:
You miss a number of other things that would require us to keep grub, one big one in particular is that it only supports UEFI booting. With the opposition and associated "discussion" to dropping BIOS support you've missed probably the biggest problem which is systems that aren't UEFI, there's also POWER and s390x in there.
I figured on emulating UEFI, per Neal's message. But since BIOS and UEFI GRUB are significantly different, most of the Fedora patches being related to UEFI (in particular Secure Boot), it could be true that substitution for only UEFI GRUB still helpful. i.e. keep BIOS GRUB, and use the upstream version of it.
Still another issue is to what degree the 2nd bootloader needs to be SBAT aware - I think there's some kind of interchange/relay between shim and GRUB? I don't know the status of or scope of work implied by that for anything.
Another idea is petitboot or Linux Boot, i.e. using linux and just kexec. This could plausibly replace all boot loaders. If it's really simpler and more maintainable, I'm in favor of it. But if it's just rearranging the deck chairs, I'm not. And I'm aware that even evaluating the alternatives consumes resources we probably don't presently have. But that itself suggests we keep treading water out more out of desperation than that it's the best solution long term.
Chris Murphy
desktop@lists.fedoraproject.org
-
Adam Williamson -
Chris Murphy -
Luya Tshimbalanga -
Neal Gompa -
Peter Robinson -
Zbigniew Jędrzejewski-Szmek