On Mon, 19 Sep 2016 00:43:28 -0500 Richard Laager <rlaa...@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 :)
