GRUB 2.06 Should Be Released This Year, Cooperation Increasing With Distro Vendors

[Guest]

Nice try , but been there - done that. And having RAM, PWR, crappy BIOS, bad blocks, cabling, whatever issues on 5 boxes where 3 of them has ECC ram as well is simply not even remotely possible no matter how drunk you are.

The only sensible answer is that GRUB is too complex for it's own good, or that I have for some reason had nearly impossible back luck with GRUB and BTRFS especially. And yes, I am perfectly aware that GRUB does not support all BTRFS features so I stay clear of those it does not support, and yes I have my BTRFS filesystem on partitions e.g. not on raw disks, and yes it is not because all machines run Debian testing/sid/experimental either, and yes I have checked that the disks are not re-ordered etc.

If something breaks on my Debian installs you can bet that it is GRUB every single #@%$!!!! time. I am pretty fed up about all the issues I have had, but luckily I can usually fix it with a livecd by just doing exactly the same the update script did. GRUB may be great for some , but in this period of my life - I HATE IT!!!!

You could just switch to systemd-boot, rEFInd or EFISTUB........

[shmerl]

Dunno, but you can set it up manually. I have it setup that way on Arch Linux. GRUB doesn't need a separate /boot partition.

I don't really want to do it manually. Last time I tried it was a horrible mess to set up. Having installer support it would be very neat.

[Guest]

I tried to run Arch on LUKS in a few ways with GRUB, it took 45s for GRUB to load /boot encrypted inside root partition, and that only worked with LUKS1. In a 6-core Ryzen 2600.

Currently I'm using systemd-boot with LUKS2 and a separate unencrypted /boot ESP, reboot is quick because root is unlocked after the kernel. GRUB is really bad at decrypting.

What keysize are you using, and what encryption algorithm? That's probably causing the problem.

It would be great if GRUB supported using AES-NI, so that you can get it to unlock quickly with AES-XTS and key sizes supported by AES-NI.

Since the kernel already uses AES-NI, if you can use EFISTUB, that should considerably speed up your boot time.

[Guest]

I don't really want to do it manually. Last time I tried it was a horrible mess to set up. Having installer support it would be very neat.

The Arch Linux Wiki has plenty of good documentation. But yes, you have to piece it together from different pages. It's not too complicated, just takes some effort to read and understand what to do.

[trilean]

But.......you can already do something like that. If you just specify the key for / in /etc/crypttab, the kernel will just use that. No need for GRUB to pass keys to the kernel. That takes care of #3.

The other steps are also already possible.

True, but that requires to have the key stored on the disk. Sure, it's stored inside the LUKS container, but it is still necessary to store it as as file. Also luksOpen needs to be run twice. IMO that's kinda hacky and not the clean solution I'm looking for.

[clapbr]

What keysize are you using, and what encryption algorithm? That's probably causing the problem.

It would be great if GRUB supported using AES-NI, so that you can get it to unlock quickly with AES-XTS and key sizes supported by AES-NI.

Since the kernel already uses AES-NI, if you can use EFISTUB, that should considerably speed up your boot time.

I tried various encryption options, the only way I could get it to boot in reasonable time was forcing a (by a lot) lower number of iterations than default when adding my key to slot 0.
EFISTUB was my last alternative indeed, so I haven't tried it since I settled with LUKS2 on systemd-boot.

What I couldn't make work was GRUB with unencrypted /boot. Followed guides on the wiki and other sources, but couldn't get it right and gave it up.

I tried something like https://endeavouros.com/docs/encrypt...rbose-version/ but with an unencrypted ESP mounted at /boot - even in a manual install, without calamares, it wouldn't boot

[waxhead]

You could just switch to systemd-boot, rEFInd or EFISTUB........

Only possible for one box that actually has EFI. The rest uses BIOS and for that GRUB is the only sensible solution (sadly)

[Guest]

I tried various encryption options, the only way I could get it to boot in reasonable time was forcing a (by a lot) lower number of iterations than default when adding my key to slot 0.
EFISTUB was my last alternative indeed, so I haven't tried it since I settled with LUKS2 on systemd-boot.

What I couldn't make work was GRUB with unencrypted /boot. Followed guides on the wiki and other sources, but couldn't get it right and gave it up.

I tried something like https://endeavouros.com/docs/encrypt...rbose-version/ but with an unencrypted ESP mounted at /boot - even in a manual install, without calamares, it wouldn't boot

But GRUB with unencrypted /boot is easy......... that's liek the default setup for many distros that offer encryption in their installers.

[Old Grouch]

I second that. GRUBs time on x64 should be long over x64. It actually forces partitioning schemes that makes, e.g. Debian on LUKS, only viable with GRUB (kernel in unencrypted /boot vs. kernel in the EFI partition).
It is actually beyond me why none of the mainstream distros support kernel updates with systemd-boot.

No, GRUB 2.x does not force that. My setup (which took a bit of work) has two partitions: an unencrypted ESP and a single (large) encrypted partition with everything else. That 'everything else' starts with LVM. In the appropriate place on the ESP there is a grubx64.efi

On power up, once UEFI does its stuff, grubx64.efi accesses the encrypted partition and requests the decryption string from the user. That string is used by the LUKS module in grubx64.efi to decrypt the key used to encrypt the partition, and that key is subsequently used to pass decrypted data from the encrypted partition to grubx64 for further processing.
grubx64.efi then uses its LVM module for subsequent processing of the data from the encrypted partition. grubx64.efi then mounts the LVM volume /boot and loads initramfs and the kernel. Control is then passed to the kernel loaded from the /boot LVM volume on the LUKS encrypted partition.

That kernel starts from scratch and has to go through the same process: so it has to request the decryption string again so it can access the LUKS encrypted partition, start LVM, mount all the volumes (including a swap volume, so I happen have an encrypted swap) and go through the rest of a normal boot process.

It works fine, and updates to grub have worked automatically. The minor downside is needing to supply the decryption string twice. One can opt to store it in the (encrypted) Initramfs. Here is not the place to discuss the level of security this provides.

The key points were to ensure that grubx64 had the appropriate modules - for LUKS, for LVM, and for the filesystems I use for /boot and /

GRUB is extremely flexible, and many constraints that people blame on GRUB are actually constraints generated by the choices the distributions make - probably/possibly for ease of support.

[Old Grouch]

To follow from my previous post...

I will point out that most distributions are using a version of GRUB that does not currently support LUKS2, so if you want to encrypt the partition that boot resides upon using LUKS2, the GRUB version used by many (?most) distributions cannot currently access it. One of the benefits of the new GRUB version is LUKS2 support.

I tried to run Arch on LUKS in a few ways with GRUB, it took 45s for GRUB to load /boot encrypted inside root partition, and that only worked with LUKS1. In a 6-core Ryzen 2600.

Currently I'm using systemd-boot with LUKS2 and a separate unencrypted /boot ESP, reboot is quick because root is unlocked after the kernel. GRUB is really bad at decrypting.

I'm not sure that GRUB is really bad at decrypting. It certainly doesn't take 45 seconds on my laptop, so I'd be careful about generalising from your particular case.

You might want to read the cryptsetup FAQ section 3.4

https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions

• 3.4 Unlocking a LUKS device takes very long. Why?

The unlock time for a key-slot (see Section 5 for an explanation what iteration does) is calculated when setting a passphrase. By default it is 1 second (2 seconds for LUKS2). If you set a passphrase on a fast machine and then unlock it on a slow machine, the unlocking time can be much longer. Also take into account that up to 8 key-slots (LUKS2: up to 32 key-slots) have to be tried in order to find the right one.

If this is the problem, you can add another key-slot using the slow machine with the same passphrase and then remove the old key-slot. The new key-slot will have the unlock time adjusted to the slow machine. Use luksKeyAdd and then luksKillSlot or luksRemoveKey. You can also use the -i option to reduce iteration time (and security level) when setting a passphrase. Default is 1000 (1 sec) for LUKS1 and 2000 (2sec) for LUKS2.

However, this operation will not change volume key iteration count ("MK iterations" for LUKS1, "Iterations" under "Digests" for LUKS2). In order to change that, you will have to backup the data in the LUKS container (i.e. your encrypted data), luksFormat on the slow machine and restore the data. Note that MK iterations are not very security relevant.

My LUKS1 benchmark results are:

$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 524812 iterations per second for 256-bit key
PBKDF2-sha256 606814 iterations per second for 256-bit key
PBKDF2-sha512 405795 iterations per second for 256-bit key
PBKDF2-ripemd160 391844 iterations per second for 256-bit key
PBKDF2-whirlpool 214520 iterations per second for 256-bit key
argon2i 4 iterations, 260211 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 4 iterations, 372051 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 256.4 MiB/s 741.4 MiB/s
serpent-cbc 128b 40.2 MiB/s 134.6 MiB/s
twofish-cbc 128b 82.6 MiB/s 114.7 MiB/s
aes-cbc 256b 192.0 MiB/s 628.1 MiB/s
serpent-cbc 256b 39.1 MiB/s 129.5 MiB/s
twofish-cbc 256b 80.5 MiB/s 113.7 MiB/s
aes-xts 256b 492.8 MiB/s 460.8 MiB/s
serpent-xts 256b 127.6 MiB/s 134.0 MiB/s
twofish-xts 256b 107.4 MiB/s 111.6 MiB/s
aes-xts 512b 420.4 MiB/s 418.2 MiB/s
serpent-xts 512b 128.4 MiB/s 124.9 MiB/s
twofish-xts 512b 108.7 MiB/s 113.0 MiB/s

It takes one second to unlock a keyslot on my machine. If you have manually changed your iteration counts, you might possibly have set them too high.