[pkg-cryptsetup-devel] Bug#820888: cryptsetup: initramfs cryptroot zfs support

[Fabian Grünbichler]

On Mon, 19 Sep 2016 00:43:28 -0500 Richard Laager <rlaager at wiktel.com>
wrote:
> For whatever my opinion is worth... :)
> 
> I see you are using ZFS on top of LVM on top of LUKS. (Or ZFS inside LVM
> inside LUKS, if you prefer that way of looking at it.) While that's
> theoretically something that "should" work, that's not a very practical
> configuration. Specifically, using two volume managers is ill-advised in
> my opinion. I recommend putting swap on ZFS instead of that setup.
> 
> If you really want to get your scenario working, I concur with the
> request for debugging output.
> 
> -- 
> Richard
> 
> 

I am playing around with a slightly different scenario, which is also
not working at all OOTB. Any pointers on where to fix stuff welcome -
I'd be happy to test and figure out patches myself.

first, my basic setup:

- Grub2 with LUKS and ZFS support, taking care of the initial decryption
and loading the kernel and initrd
- complete / on ZFS directly on top of one LUKS-encrypted disk - no
separate /boot , as that is not needed here
- rpool called "rpool" with one member (the mapped decrypted disk), set
up with "-d /dev/disk/by-id"
- / dataset is called "rpool/ROOT/debian", and has the mountpoint
property set to "/"
- crypttab contains a line for the encrypted disk, the crypto device is
named "cryptroot" there (not sure whether this helps at all?)
- initrd generated with set $CRYPTROOT , because it can't detect / from
/etc/fstab (which is empty, all mounts are established by zfs)

$ cat /proc/cmdline
BOOT_IMAGE=(crypto0)/ROOT/debian/@/vmlinuz root=ZFS=rpool/ROOT/debian ro
boot=zfs break=premount cryptops=source=/dev/sda,target=cryptroot

(crypto0) is the device grub "sees" after unlocking the LUKS device with
grub's cryptomount

following the "Debug cryptroot initramfs script", I added the '-x' to
the shebang of the cryptroot script. Unfortunately, running it only
collected the following lines in the log file (note: I was not asked for
a passphrase at this point):

+ PREREQ=cryptroot-prepare
+ . /scripts/functions
+ cmdline_cryptops=
+ unset cmdline_root
+ cat /proc/cmdline
+ opt=ZFS=rpool/ROOT/debian
+ [ -n ]
+ [ -r /conf/conf.d/cryptroot ]
+ exit 0

the /dev nodes are set up correctly, as verified with lsblk (including
the symlinks in by-*)

manually calling "/sbin/cryptsetup luksOpen /dev/disk/by-id/XYZ
cryptroot" followed by "zpool import -d /dev/disk/by-id -R /root rpool"
and pressing ^D a couple of times allows me to boot.

I hacked together a quick script that simply does the above cryptsetup
and zpool dance, which I put into
/etc/initramfs-tools/scripts/local-top/ , this works for now (if I
include a modprobe inbetween, I can boot without any kernel boot
parameters, although the passphrase prompt is not very visible in the
middle of the initrd output). I still have to set $CRYPTSETUP before
generating the initrd with update-initramfs , so I assume automatically
regenerating it on updates would break the setup.

all of this is on sid, with
initramfs-tools 0.125
zfs-initramfs 0.6.5.8-1
cryptsetup 2:1.7.0-2

after an update to the current cryptsetup (2:1.7.2-3) and setting
cryptsetup=y in /etc/crytsetup-initramfs/conf-hook I get the same debug
output and behaviour. uncommenting the /etc/crypttab line and
regenerating the initrd does not change anything.

any pointers appreciated :)