Did you ever find a solution to this problem? I’ve researched on arch wiki and scoured internet. I don’t see anything that would suggest this is feasible right now. Grub guys don’t seem to want much to do with ZFS.
You need an EFI partition for your “bootloader” of choice. That could be GRUB, rEFInd, systemd-boot or an EFISTUB kernel.
The optimal configuration is: enable the encryption flag on the pool, create unencrypted dataset and under that dataset create an encrypted /root and an encrypted /home dataset (e.g. /tank/root, tank/home). You could also instead create an encrypted dataset under the top unencrypted one and then create /root and /home there so that you only use your password once (so e.g. /tank/enc/root, /tank/enc/home). Tank being the unencrypted dataset.
If your kernel and initramfs is placed in the EFI partition, then GRUB (or any other method) can boot it normally and then the kernel will load the zfs driver (you have to tell it so in the GRUB config AFAIK) and will ask you to unlock the encrypted partitions.
The problem arises when you want to have your kernel and initramfs in an unencrypted ZFS /boot dataset. GRUB will not try to load the kernel from a ZFS filesystem that has the encryption flag (or some other flags) enabled, even if the kernel is not on an encrypted dataset.
Then you have these options:
Modify GRUB so it ignores the fact that the pool has the encryption flag enabled
Use rEFInd with a third-party ZFS EFI driver
Possibly use your motherboard’s EFI shell, or modify its BIOS (VERY DANGEROUS) with the third-party ZFS EFI driver and boot the kernel directly
At the moment, I don’t think that there is a way to boot the kernel from an encrypted ZFS /boot dataset.
Yea I came across the first link researching the topic. Wasn’t extremely helpful. Maybe best option is installing zfs on top of dm-crypt and go that method. Kind of klunky but I think that is how its been historically done. I guess if you don’t require the /boot partition to be encrypted, then you could avoid the dm-crypt/LUKS route.
I wouldn’t think that this is the best option. You could natively encrypt the /root and /home datasets and have a /boot or /efi partition for GRUB and a third LUKS1 vfat or ext partition for your kernel and initramfs. That way GRUB can read and ask you to unlock the encrypted partition where the kernel is and then the kernel can read and ask you to unlock the ZFS /root and /home.
This obviously means that you lose the snapshotting and checksum ability of the kernel and initramfs (and might cause the wrong IO scheduler to load for ZFS - check that github thread) but I believe it is more “future-proof”, i.e. when in the near future we get some way to boot from encrypted ZFS, you won’t have to reconfigure the whole disk (which would be needed to remove LUKS) but just the /boot or /efi and the kernel partition.
That is what I would do but I do get to mess with, break and fix my systems quite often, so maybe my opinion should not be that trustworthy.
Anyway, good luck if you are going to try any of this!