GRUB 2.04 Release Candidate Brings Globs Of New Features

[FireBurn]

Systemd's bootctl just works fine if you want a menu

It boots the default or I press F12 and select the kernel / OS I want to load instead

[rmoog]

You know damn well we were all discussing single disk systems and the inherent limitations GRUB has in those setups. Full disk LUKS2 encryption? Not if you have to use GRUB. Full featured ZFS volume? Not with GRUB.

Like I said - delegate this functionality to the initrd.

[skeevy420]

I think that's a silly notion because:

1) GRUB is a bootloader. It's meant to load a kernel - not have laise faire access to your encrypted volumes. End of story. What do you want to do with GRUB-level access to encrypted stuff anyway? Watch porn from the bootloader in 8086 real mode? Maybe you want GoogleDocs, BattleNet, League of Legends and Amazon EC2 support in GRUB too?
2) regurgitate_point(1);

Here's how I managed this problem so far.
For any computer that I have, I have a USB drive. The content of the USB drive is a fitting GRUB setup - GPT with hybrid MBR for BIOSes, GPT with EFI for EFIs.

You know damn well we were all discussing single disk systems and the inherent limitations GRUB has in those setups. Full disk LUKS2 encryption? Not if you have to use GRUB. Full featured ZFS volume? Not with GRUB.

FWIW, I use the USB method with LUKS from time to time, but it doesn't mean that I wouldn't like having the contents of /boot covered with my system snapshots, the ability to use the same encryption implementation as everything else, to simply not have that one special disk that needs special treatment regardless of what the disk is actually used for...that last one is the reason I'm a ZFS user since it covers damn near anything I could do with a storage device in extremely flexible ways.

If you read the thread you'd realize that I have indirectly answered your GRUB level access question already...well starshipeleven did and I just agreed...

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.

We don't necessarily want the bootloader to be able to access all of that or to have all of those capabilities and would rather rely on our kernels for whatever functionality that we need. The only time you'd want the bootloader to be able to access all of that is if you FUBAR'd something and need a rescue shell.

[rmoog]

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.

I think that's a silly notion because:

1) GRUB is a bootloader. It's meant to load a kernel - not have laise faire access to your encrypted volumes. End of story. What do you want to do with GRUB-level access to encrypted stuff anyway? Watch porn from the bootloader in 8086 real mode? Maybe you want GoogleDocs, BattleNet, League of Legends and Amazon EC2 support in GRUB too?
2) regurgitate_point(1);

Here's how I managed this problem so far.
For any computer that I have, I have a USB drive. The content of the USB drive is a fitting GRUB setup - GPT with hybrid MBR for BIOSes, GPT with EFI for EFIs.
The makeup of the /boot partition on all of these drives is more or less this:
- kernels
- initrd matching each kernel with appropriate additions like ZFS, LVM, LUKS, GPG, NFS, MD support
- GRUB config
- additional GRUB files, but not that many really
Meanwhile the dormant drive is encrypted before anything else. It doesn't even have a partition table.
So here's how to properly boot:
1. Insert USB
2. Power on
3. Select kernel
4. Wait for GPG/ZFS/LUKS password prompt
5. At this point you can remove the drive since it's guaranteed the initrd and kernel loaded entirely into RAM
6. Enter password
7. The rest takes care of itself

Easy? Easy. No need to bother GRUB devs with adding LGFSoT encryption (Latest Gimmick File System or Thing).
This way any thief will have the impression the computer contains no OS unless they also obtain the bootloader USB.

[starshipeleven]

no idea why you are that married with 0.90 when 1.0 is fine too, otherwise my /boot won't work

because I always used 0.9 for these things, and I don't see why your /boot can't work with 0.9.

yeah, that sure will work on a MBR partitioned disks

EFI partitions work also in MBR disks as it's required by UEFI spec.

It's also perfectly possible to convert MBR partitions to GPT, as long as you shrink a few dozen MB the end of the partitions so it leaves some space for the backup GPT partition table.

http://www.rodsbooks.com/gdisk/mbr2gpt.html

that's bullshit, touching your partitioning *is* destructive

reinstalling from scratch is destructive.
copying to a folder and then rebuilding /boot array in another way that will still boot fine in legacy boot is not.

and other than you i am responsible for 6 machines sharing the same partitioning, same UUIDs and /etc/fstab content with just different network config and adjusted package set - and no you can't make sure to never forget stop rsync fstab after tested changes on a local machine when you trained for a decade that it works that way and never did reinstalls on any linux setup

Only 6? Those are rookie numbers.

that UEFI fuck don't even work proper in a VMware guest

I routinely boot completely untouched physical USB drives I passthrough inside a UEFI VMWare VM, so I'll just assume you are a noob like debianxfce.

yeah, that all will work fine having most of the machines up to 300 km away and only reachable via SSH....

Why do you want to migrate production servers to UEFI? Isn't that stupid and useless?

Don't shift the goalposts now that I answered your previous question.

[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.

[rmoog]

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

[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

[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.

[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.