Grub is like a turd that won't flush. It's been completely unnecessary for years, is massively overcomplicated, pretty much unusable as a shell with it's 1995 idioms, and there are much, MUCH lighter (and as useful) replacements (extlinux etc) -- and you can even just remove it completely and boot the kernel directly these days with the EFI stub...
But still, it gets installed, trying to justify its existence.
I thought the advent of UFEI would finally put GRUB to rest.
Worse, if you dual boot and each OS installs its own GRUB you can get all kinds of silly situations where one GRUB will chain load to another GRUB and then boot the OS.
Why not just hit F12 (or whatever) and UEFI gives you this nice little menu of all your boot options right there, before installers can come in and ruin it. (Like Windows that always seems to barge in and put itself on top trashing whatever you had before.)
> Grub is like a turd that won't flush. It's been completely unnecessary for years, is massively overcomplicated
shim + grub suck, but bare bones EFI sucks way more, generally speaking. Vendors of consumer-oriented EFI platforms ("client platforms") are batshit insane; they don't offer UEFI console redirection to/from the serial port even if the motherboard has one; they expose neither secure boot configuration nor boot options management to the user, and so on. A purely EFI-based boot loader such as systemd-boot or rEFInd remains the least annoying choice, IMO.
Not the parent, but I've spent enough time in the GRUB recovery shell trying to recover inexplicably corrupted GRUB installs even as recently as last year.
GRUB is shockingly fragile and painful to debug, though the recent movement on BLS hopefully will help with this.
Okay. I have a laptop here with windows, haiku and Linux. And actually the grub (2) configuration to get haiku to start was strange. What exactly do I install best to replace grub?
Or alternatively, I have a PC with only Void Linux. Compatibility mode for booting, since uefi mode did not work (I dont know why - some secure boot shenanigans? MBR vs GPT mode? There is no EFI partition as well). What could replace grub there?
On the booting Windows front, this thread has a few people describing how they successfully used BootManager to dual and triple boot Haiku, Windows 7, and/or Linux:
I have a laptop (Lenovo ThinkPad T410s) with Haiku, Linux Mint, and Devuan GNU/Linux. I use BootManager in the MBR, and it gives me a menu of all three to choose from. For the two Linux options, I have GRUB installed on each of their own partitions, so BootManager just sends me to the GRUB installed on whichever Linux partition. (Of course, this isn't exactly "replacing" GRUB altogether.)
I do it this way because I find dealing with BootManager to send me to individual GRUBs to boot a particular Linux partition much, much easier than fiddling with GRUB to boot Haiku.
(One last thought, parenthetical as I'm not sure it can even work from a USB drive: Worst case, you might make a USB "boot stick" that uses BootManager to choose between Haiku and Linux and let Windows do its jolly thing on the MBR?)
I tried to install the BootManager, but the limitations mentioned in the docs blocked the install. I think this part:
> BootManager isn't yet tested very well and still has a few restrictions that it will complain about if they aren't met: the menu can only be installed on your first harddisk and there has to be a 2KiB space after the Master Boot Record (MBR).
No idea how to create those conditions, the 2KiB space, and since I would have to do it with gparted in Linux anyway this made me install Linux instead first (with grub).
BootManager actually sounded nice - like you describe, I expected it to simply offer me the other OS(s) option(s), and I wasn't even set on installing Linux in the first place on that machine.
To your parenthesis: Yeah, I even had a boot manager on USB once for my PC, so it crossed my mind here, but for a travel laptop this would be a bit uncomfortable.
In same boat here. I just do not understand the *EFI stuff anymore, and I've tried.
I somehow got refind to work, after disabling some vaguely named "secure boot" option in the BIOS. It shows my several linux options, and the only one that works is "rescue", that boots what is apparently a systemd bootloader with Nix generations. When I select Windows, I get some windows boot menu/loader instead of directly booting Windows.
I have no clue how it all works - there is some partition with some files, but I also must run some command to "apply" changes - I think. It's horrible.
I personally would like to be able to enable the UEFI boot mode of the board, so that I can enable Resizeable bar - for the performance benefit and to have the option to add an Intel GPU later. So cleaning up the GRUB situation could help me there - that's why my comment above was completely serious, I'd really look at suggestion.
Because otherwise I see it like you, why change what works. Even the move to Grub 2 with the more complicated config options wasn't all that bad, since it really needed less often to be configured manually. So after a bit I was fine with that.
What I don't understand is why GRUB needs to be regenerated every time you add a kernel or OS.
Make the bootloader smart enough to find read the underlying filesystems and find kernels. rEFInd does it. If I put in a bootable USB or install Windows on a second SSD, it just shows up on the menu without explicitly demanding it.
Maybe you have to say "/boot needs to be one of n well-supported filesystem types" but one-size-fits-most is probably good enough, relying on something GRUB for the people running ZFS-atop-RAID6-atop-a-collection-of-128-USB-floppy-drives.
Setting GRUB up with full-disk encryption and BTRFS snapshots is braindead easy. Maybe it'd be just as easy with Gummiboot or rEFInd, but you know what they say about fixing things that aren't broken.
What's the current state of the art on this? Last time I looked it was really not trivial, because of two things:
1) there is only one bootloader (grub2) that can load kernels from encrypted /boot partitions, but the support for that is limited, you have to use a weaker encryption if I remember correctly, AND decryption speed (after entering the luks password) is super slow, because the CPU extensions that speed that up (AES) are not yet online that early in the boot process
2) you can choose to not encrypt /boot, and have it as a separate partition, but now your btrfs snapshots will not include the kernel, so restoring after kernel upgrades is going to break your system
I am only really familiar with Arch and OpenSUSE, so I don't know how other distros do it, but OpenSUSE keeps the (I believe) latest 5 kernels, so I just have to delete snapshots older than the oldest kernel in my /boot. I like that system so I do the same thing on Arch (but don't tell anyone, otherwise I'm gonna get yelled at).
Doesn't deleting old kernels defeat snapshots? You do a system update, you get a new kernel, you delete the old ones, now all snapshots that depend on that older kernel are busted, what am I missing?
You may have misread, what I do is I keep the 5 latest versions of the kernel the distro ships and I delete snapshots which depend on kernels older than those 5. I could keep all the kernels and snapshots, but I don't have that much storage dedicated to / and /boot.
It really is easy, it is just mostly a matter of proper initramfs, and a "linux" line in the GRUB configuration file. Arch wiki gets into it in detail.
But still, it gets installed, trying to justify its existence.