GRUB 2.04 Release Candidate Brings Globs Of New Features

[skeevy420]

Except for systems still around that don't have UEFI....

There is still the option of UEFI emulation and systemd-boot. I'm in the same boat as yourself with my dual socket Xeons and that's the route I'm looking into since systemd-boot is one of the few methods on Linux, possibly the only method, that supports every ZFS feature.

Combined with an RX 580, all my games play at 60 fps. That's good enough for what I need so I don't feel the need to upgrade.

[chithanh]

UEFI might be convenient, but if you are interested in a secure system then best avoid it if you can.
The UEFI specification has grown to over 2500 pages. It is a horrible complex mess and almost impossible to implement correctly and securely.
For comparison Open Firmware/IEEE1275 is just 266 pages.

Ideally I just use the EFISTUB boot method if the computer supports it. Don't even bother with a bootloader and use the EFI menu if you want to boot to other installations. There are some strange EFI implementations that don't work with it

EFISTUB cannot boot 64 bit kernels when UEFI is only 32-bit. This is the case with some Intel Atom systems, which have a 64-bit CPU but only 32-bit UEFI.

[starshipeleven]

Again, not every modern system uses UEFI, for example POWER, SPARC and IBM z/Series.

Do note that the point isn't that everything uses UEFI, but that GRUB is useless on modern hardware. And this still stands true.

Let's see what the mentioned systems actually use in 2019.

POWER's bootloader loads and executes a linux kernel on its own, similarly to UEFI https://wiki.raptorcs.com/wiki/OpenPOWER_Firmware so GRUB on Power is not required.

IBM z/series (modern ones alyway) uses zipl bootloader which is likewise able to boot linux kernel on its own

SPARC uses SILO https://en.wikipedia.org/wiki/SILO_(boot_loader) which is again able to boot a linux kernel on its own.

Now, can you get them to booot GRUB? probably. I didn't check, but it's just as unnecessary as it is on UEFI.

EDIT: bonus:

u-boot on embedded or x86+coreboot can boot a kernel on its own from a normal filesystem, and u-boot supports the "boot scripts" aka a text file where you provide the boot commands it will read and use to boot your kernel, so you don't need to update its static config each time you update the kernel

Your assumption that anything but UEFI is legacy is simply wrong and uninformed.

I never claimed that.

[skeevy420]

Do note that the point isn't that everything uses UEFI, but that GRUB is useless on modern hardware. And this still stands true.

Yep. There are just better alternatives these days and GRUB can be slow to keep up since it implements everything on its own.

Makes more sense to use a bootloader that relies on the kernel for supported features than on the bootloader itself. It's one of the biggest limitations I run into as a person that uses GRUB due to my older system. If you (want to) move on to LUKS2, BTRFS, or ZFS, GRUB starts to show its limitations that UEFI and other loaders don't have.

[starshipeleven]

surely, that's basically what happens with the classical /boot on RAID1 but when you google for EFI-partition and RAID that all sounds not nice

oh lord help us. It's debianxfce not being able to clone his drives in UEFI all over again.

I have a RAID1 btrfs system at home, and I personally use the following setup for the EFI partition on my array.

I'm using a static rEFInd installation in a EFI partition (refind-install --use-default /dev/sda1 for example, see here http://www.rodsbooks.com/refind/refind-install.html and then copy EFI filesystem drivers for my root drive, either from refind's archive/build folder or https://efi.akeo.ie/ , in /EFI/BOOT/drivers in the EFI partition).

UEFI spec mandates that it will eventually try to boot /EFI/BOOT/bootx64.efi from the first EFI partition it finds.
This does not require you to muck around with efibootmgr and even shit UEFI firmwares will be able to boot it because it's also used by Windows installers.

Then I just copy the same EFI partition in all drives in the array (I have just 2 drives). The UEFI will choose randomly what UEFI partition to use, but all are the same, and they never change because rEFInd scans for kernel on each boot and will try to boot the last modified kernel (usually the newest) it finds in the same folder.
If I need to replace a drive I will have to copy this partition on it too, but this can be done from the running system while I also rebuild the array, as each drive in the array is bootable.

nor have i found out how you are supposed to get a existing setup with /boot as RAID1 on ext4 relieable migrated to UFEI

if you use rEFInd should be as easy as:

1. boot normally and migrate your /boot as a mdadm array with metadata=0.90
   (afaik you need to erase and rebuild it so you probably will have to adjust the fstab after that too) https://serverfault.com/questions/14...existing-array
2. create the EFI partitions in all the drives as said above
3. create a refind_linux.conf text file in the directory/partition you have the kernel in, and write into it what you see in GRUB's kernel command line options, this is an example config with 3 different kernel command line options. It will boot with the first line by default, you can choose the others through the GUI:
   

   	"Boot with standard options"  "ro root=UUID=084f544a-7559-4d4b-938a-b920f59edc7e splash=silent quiet showopts "
   	"Boot to single-user mode"    "ro root=UUID=084f544a-7559-4d4b-938a-b920f59edc7e splash=silent quiet showopts single"
   	"Boot with minimal options"   "ro root=UUID=084f544a-7559-4d4b-938a-b920f59edc7e"

4. boot in UEFI mode through your mobo's setup options, the UEFI will load rEFInd, which will scan for kernels and find it in the /boot partition, and should boot the system in UEFI mode.

Note that none of these operation is destructive, so if at the end you can't boot in UEFI for some reason you can still be able to boot in Legacy mode as normal.

I'm pretty sure any modern Linux installation that also offers a UEFI installation can boot in UEFI mode without much issues as the kernel and stuff are the same for both, but if you want to try before doing the above, boot a SuperGrubDisk2 in UEFI mode and use it to boot your system, after you added the same kernel command line as you have in your current GRUB2. https://www.supergrubdisk.org/super-grub2-disk/

[starshipeleven]

Makes more sense to use a bootloader that relies on the kernel for supported features than on the bootloader itself.

Linuxboot went this way, for example.
There the linux kernel acts as bootloader, and executes another kernel (the actual OS kernel) with kexec.

I would really like to see a UEFI bootloader which is in fact a mini linux kernel.

[fuzz]

There is still the option of UEFI emulation and systemd-boot. I'm in the same boat as yourself with my dual socket Xeons and that's the route I'm looking into since systemd-boot is one of the few methods on Linux, possibly the only method, that supports every ZFS feature.

Combined with an RX 580, all my games play at 60 fps. That's good enough for what I need so I don't feel the need to upgrade.

Interesting, I use systemd-boot on my system76 laptop and it works great. Didn't know about the UEFI emulation so I'm going to have to look into it. Thanks!

I also have an RX 580 and feel the system will last me for a while longer. It's getting a bit long in the tooth for some games (still bulldozer-based and not that high of frequency) but I mostly play slower strategy-type stuff. Even once I replace it for gaming it will be a great server for a long time.

[fuzz]

Do note that the point isn't that everything uses UEFI, but that GRUB is useless on modern hardware. And this still stands true.

For what it's worth, I was arguing for its use in the modern "era", not on modern "hardware". Small distinction but In your case I agree with you

[rmoog]

To all the people with encryption/compression problems with GRUB:
Why can't you just keep /boot as a separate EFI partition?

[skeevy420]

To all the people with encryption/compression problems with GRUB:
Why can't you just keep /boot as a separate EFI partition?

1) Because we're stuck with GRUB due to not having UEFI to begin with or we have a 32-bit UEFI that doesn't support a 64-bit OS. I reckon that most of us complaining are in one of those situations.

2) Laptop theft, physical access reasons, security paranoia.