Nixpkgs: GRUB silently generates wrong config (cryptsetup default is now LUKS2)

[deliciouslytyped]

(Edit: Slight clarification: The issue is, IIRC, IIUC, that GRUB doesn't support LUKS2 at this time, while creating a new LUKS partition now defaults to LUKS2 - and nothing errors when telling GRUB to try booting the LUKS2.)

This isn't necessarily a nixpkgs bug but I would be happy if we could find some way to prevent people needlessly wasting time figuring this out:

GRUB doesn't support LUKS2, which is now the default with cryptsetup 2.1.0 (see also the warning at http://web.archive.org/web/20190722114948/https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encrypting_devices_with_cryptsetup). (Therefore, presumably some people may have issues if they create a fresh setup on the next release.)

When trying to generate a boot configuration per http://web.archive.org/web/20190409165127/https://elvishjerricco.github.io/2018/12/06/encrypted-boot-on-zfs-with-nixos.html (which should soon be updated to mention this problem) GRUB will silently select the zfs partition as the root device and generate an improper configuration. This part of the configuration is embedded inside the bootx64.efi binary and can be checked by something along the lines of strings file.efi | tail,yielding among other things, the following:

search.fs_uuid <zfsuuid> root
set prefix=($root)'/thezfs@/boot/grub'
/thezfs@/boot/grub

Note: the zfs uuid is the hex encoding of the decimal zfs GUID - which may be initially confusing, as no such UUID is listed anywhere in blkid. By converting the integer IDs listed by blkid for zfs partitions you should be able to confirm the above <zfsuuid>.

For a working luks1+zfs configuration you will see something like follows:

cryptomount -u <uuid goes here>
(cryptouuid/<uuid goes here>)/thezfs@/boot/grub

You can confirm the version of your LUKS partition by looking at cryptsetup luksDump /the/device.

It would be nice if GRUB gave some sort of meaningful output that would lead to diagnosing this but it doesn't.

Since we run a perl script to install grub at activation anyway, maybe a check could be added to warn about LUKS2 instances if enableCryptodisk is enabled? Ideally this would instead be fixed upstream but I don't know about that...

Note: apparently it's possible to downgrade LUKS2 to LUKS1; see section 2.2.1 Downgrading LUKS2 to LUKS1 https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

[tyrion]

Since we run a perl script to install grub at activation anyway, maybe a check could be added to warn about LUKS2 instances if enableCryptodisk is enabled? Ideally this would instead be fixed upstream but I don't know about that...

Having at least a warning would be awesome. I lost many hours trying to understand what was wrong here :(

[marfeljoergsen]

I fully agree, I've spent maybe 10-20 hours on this - before finding the explanation, a warning at least would be AWESOME! :-)

[deliciouslytyped]

Called it... I don't have the capacity right now, I'll see if I can beg someone to write a PR for this. :P

[deliciouslytyped]

No luck :/

[bgx90]

Grub recently added LUKS2 support to their master branch.
https://www.linuxexperten.com/news/grub-boot-loader-adds-support-luks2-encrypted-disks
https://savannah.gnu.org/bugs/?55093

[shazow]

According to the patch notes, LUKS2 support is only partial still:

Note though that in the current version, only the PBKDF2 key derival function is supported.

While I believe the default key derival function for LUKS2 is argon2.

So a warning would still be prudent if an unsupported configuration is detected. (Hi, I also wasted several hours until finding this issue. :upside_down_face: )

[brainrape]

Hey, I could take a stab at a warning PR. Would it be fair to emit a warnig of possible wrong configuration if boot.loader.grub.enableCryptodisk and *.zfsSupport are true?
Any suggestions on where to link for further info?

[spinus]

@brainrape how does it relate? Are cryptodisk and zfs incompatible? I think this issue relates to crypto in general, not only for ZFS.