Fedora May Make It Easier To Switch To systemd-boot, Making A GRUB-Free System

[jrch2k8]

Damn every systemd tinfoil hat extremist woke up early today.

GRUB is nice for many cases but is broken as hell most of the time for many cases over time and its development is dead snail slow, if you have a complex setup systemd-boot is actually pretty damn nice and is so minimal that barely gets in your way and in my experience using it since it was released has proven stable AF outside few UEFI glitches years ago.

no matter how crazy your boot setup actually is systemd-boot will most likely work(on UEFI systems ofc) because is extremelly minimal and basically the only thing it does is to show a menu and then give control to the kernel/initcpio and pass the parameters you put in the 3 line config file, so all the heavy lifting is done by the kernel and initcpio, so things like encryption, zfs, btrfs, iscsi, lvm, virtual raids(aka at least 1 phy disk on the machine and iscsi mirror for example), etc, etc ,etc. will work as long as the kernel is properly configured.

Now for a home system with no special case GRUB and systemd boot work fine on most systems, so use whatever you feel works best for you

[Vistaus]

One of the advantages of UEFI is that it can fully replace bootloader and just boot linux image with initramfs from EFS, also that the OS can alter the boot list & kernel command line via efivars. This is the way to go, not replacing GRUB with dumber GRUB.

That's the first time I've heard “advantages” and “UEFI” in one sentence.

[caligula]

I wouldn't like efi vars being touched on every Kernel update: nvram write resource is limited and what's more important some smart-ass UEFIs rearrange boot order to their own liking after adding or removing boot entry.
So having small yet predictable bootloader with text configs (and handy features like hotkeys) is more preferable rather than barebone vendor-dependent and sometimes glitchy uefi boot menu.

Yes, but the free capitalistic world hates your resource conserving communism tactics. Motherboards are designed to fail in a few years. If people don't buy a new motherboard + CPU + RAM combo every 3 years, this means less taxpayer money gets collected, and as a result some poor homeless refugees starve to death. Also poor Chinese mining companies in Africa would not have any work to do if we did'nt need new rare earth minerals. Wiping out the nvram entries every second week thanks to millions of kernel upgrades is actually helping the global economy.

systemd-boot is more like an external patch to substitute a horribly broken UEFI own boot menus. All you need is just to somehow get systemd-boot loaded, and then you are saved. But still, it is a bugfix.
I just wish for a simple GUI tool to directly manipulate UEFI boot menu through variables. UEFI's own tools is just awful dumb to do this. To clean up dead entries, make alternate boot entries, etc.

This is correct. Some mobo uefi bioses already use 32 to 64 megabytes of space and still don't have any kind of (decent) boot menu editors. You might be able to shuffle entries or delete them, but that's it. No even option to rename the entries. It's surprising how shitty the quality of this software is. You can fit kernel, all drivers, systemd, busybox, and lots of other stuff in that space. But the piece of shit mobo companies can't do it. But they previously claimed that UEFI would improve the productivity.

[milo_hoffman]

I think that systemd-boot actually looks like a pretty decent solution. One thing I am wondering is what about the things that use dynamic grub menus to provide the ability to boot into a snapshot etc.

[FeRD_NYC]

Removing GRUB is a planned-obsolescence, NIH, anti-feature in my book, meant to kick BIOS computers to the curb.

This, OTOH, is classic FUD. The proposal is to offer systemd-boot as an alternative boot option — it's not like Linux has a spare history of those. (SYSLINUX, grub1, Clover, LILO, rEFInd... need I go on?) Grub2 is only one of many; it is not the sacred cow you seem to view it as. Nobody is trying to get rid of Grub2. Nobody is trying to get rid of BIOS booting. But the fact is, having a machine with EFI booting makes a separate /boot partition seem sort of redundant and unnecessary, only persisting because it's a legacy requirement of Fedora's Grub2 setup. That is unlikely to change.

For users who don't want that (see the very first comment here), providing an alternative based on systemd-boot offers a path to doing away with /boot and booting solely from the ESP. There's virtually zero likelihood Grub2-in-Fedora would ever take the same path, even optionally, even if it's theoretically/technically possible to do so.

[FeRD_NYC]

For users who don't want that (see the very first comment here), providing an alternative based on systemd-boot offers a path to doing away with /boot and booting solely from the ESP. There's virtually zero likelihood Grub2-in-Fedora would ever take the same path, even optionally, even if it's theoretically/technically possible to do so.

Fun fact: I maintained a dual-boot Windows/Fedora laptop (BIOS booting) for a while that had the /boot partition formatted NTFS instead of ext4, so that I could access it from Windows as well as Linux. Primarily, that allowed me to edit the grubenv even when booted into Windows, so that I could (for example) tell the system "reboot into Linux" directly from Windows, rather than having to catch a boot prompt and select a different option.

Grub2 (and either Grub4dos or Grub2Win — I can't remember which I used, on the Windows side) supported all that just fine, but every 6 months Fedora's stuff — which is built with a lot of assumptions regarding the boot setup — would freak out when upgrading the OS, and eventually it proved more trouble than it was worth so I gave up on the idea.

The systemd-boot setup will have to contend with all of those same built-in assumptions, but if it's being done as an accepted Change Proposal then the devs will have the necessary backing to actually change things. (Which would also benefit users who want to continue to use Grub2, but in non-standard ways like I was.)

[woddy]

I don't like systemd, RedHat and IBM who only think about making maximum financial profit on the backs of GNU developers. Shame on IBM and strongly that new rules for the use of Linux arrive to prevent manufacturers from appropriating it.

I'm not interested in defending RH much less IBM, however if there weren't these companies and other Google, SUSE etc. Linux would be small and maybe it would have evaporated some time ago.
Yes, companies think about profit (like their employees think about salary) because this is the only way they can pay salaries and invest, but if you like working for free I'm sure they would hire you (for free), but I assure you that there are few people who can afford it.

As for systemd-boot, my problem with it is that I can't boot Btrfs snapshots, I don't know if that has changed today, but until a while ago it wasn't possible.
This is a big limitation for me.

[kreijack]

For users who don't want that (see the very first comment here), providing an alternative based on systemd-boot offers a path to doing away with /boot and booting solely from the ESP. There's virtually zero likelihood Grub2-in-Fedora would ever take the same path, even optionally, even if it's theoretically/technically possible to do so.

I don't understand why grub2 cannot deal with a 'boot-dir-less' setup. In fact it is enough to set the root to the ESP partition.
Of course it would break a lot of assumption so it is not an easy change. But in any case t is the same for sd-boot. So from this point of view these are equal.

What it is true, is that grub2 comes from an old era where the BIOS was very basic, with nothing more than an limited access to disk by block basis. This caused to the grub2 team to develop driver for any kind of configuration (different raid profiles, encryption via luks, different filesystem...)

Now we have uefi, which provides access to a filesystem and can be extended using driver[*] (which ironically are grub2 based). So it is time to get rid to a complex grub2 e to leave the door open to more simple bootloader (like sd-boot). I counted the LOC of grub2 and sd-boot: ~400k vs ~20k

I use sd-boot, and for me it works flawless; the only thing that I miss is that this setup doesn't allow to have kernel and initrd in the /boot directory, and often I fill the ESP one and I had to empty it. This is annoying. Having a /boot in the root solved this issue (or the empty is less often required).

Finally I want to say that even tough grub2 may have some bugs, I don't think that these are more (or more severe) than the ones of the UEFI shipped with several motherboards.[*] see https://efi.akeo.ie/

[wangling]

Motherboards with UEFI support are not recent things, they are something like 10 years or more on market and now some of the manufacturers are talking about releasing motherboards without BIOS compatibility mode. Hardware that has more than 10 years is not recent by any means. And yes, GRUB provides many features that bootloader should have but thing is we don't need bootloader anymore when we can just run kernel directly.

Linux distributions should get rid of GRUB years ago, it's bloated, had security issues and it's simply not needed anymore. Things like rEFInd should be already standard in distributions. It's simple (so less potential security issues), easy to use (compared to GRUB config file, rEFInd config file is like comparing art to garbage) and provides most needed features (like support for file system drivers so it can load kernel from different filesystems).

When we talk about Linux, it not only represents x86 Linux, but also includes a variety of architectures, and everything you say only holds true under x86.

Grub provides a universal solution for cross architecture situations without having to do many architecture specific configurations.

If you want to achieve these compatibility with any alternative, I think you will end up with another grub.

[kreijack]

As for systemd-boot, my problem with it is that I can't boot Btrfs snapshots, I don't know if that has changed today, but until a while ago it wasn't possible.
This is a big limitation for me.

It is not a problem of sd-boot, but more of the infrastructure around that.
I think that around grub there are scripts that automate the passage:
- do a snapshot -> updated the grub.cfg

But nothing prevent to do the same with sd-boot.

I think that is the classic problem: until a distribution starts to used a tool, the infrastructure doesn't grow enough to satisfy the all needing. Godd or bad, this fedora choice will help the grows of the infrastructure.