[pkg-cryptsetup-devel] Bug#838001: Bug#838001: cryptsetup does not support ZFS

[Guilhem Moulin]

On Mon, 19 Sep 2016 at 00:51:45 -0500, Richard Laager wrote:
> On 09/18/2016 02:13 PM, Guilhem Moulin wrote:
>> The kernel parameters
>> approach and the /etc/fstab approach are both FS-agnostic, and I'd
>> rather not have FS-specific code to find out which device is mounted on
>> / or /usr.
> 
> When someone is using ZFS, there is simply no way to get from a
> mountpoint to a set of devices without invoking ZFS-specific support
> code. Looking at /etc/fstab, mount output, or /proc/self/mounts (or
> /etc/mtab) will only give you a ZFS dataset name. That is, / will
> convert to yakkety/ROOT/ubuntu, not /dev/mapper/luks1. You need to ask
> zpool (or libzfs) to get from yakkety/ROOT/ubuntu to /dev/mapper/luks1.

Sorry, I didn't use the right terminology.  I meant I'd rather avoid
FS-specific code to find out which *pool/dataset* is mounted on a
particular mountpoint.  Of course, like for BTRFS (and mdadm if one day
we add support for RAID on top of LUKS, cf. #629236), we would need
FS-specific code to retrieve the list of underlying devices.
 
>> Can you provide an example of the output produced by `zpool
>> status -P "${name%%/*}"`, though?  I don't know if adding ‘-P’ changes
>> anything, but at least without it I saw headers containing slash
>> characters.
> 
> Where are you seeing headers with slash characters? I can't think of
> any scenario where that might occur. And even if it did, it would have
> to be the first field to be grabbed by the awk command I wrote.

    https://www.freebsd.org/doc/handbook/zfs-zpool.html
    https://docs.oracle.com/cd/E23824_01/html/821-1448/gaynp.html#gamno

Fair enough it's not the first field, but by looking at the output I
have the impression that the header is pretty much free form.  I don't
see why the URL couldn't end up on the next line after wrapping, for
instance.

> With -P, zpool status shows the full path to the device. Always use -P
> these days, in any script. Without -P, ZFS "wholedisk" pools will show
> "sda" when you may be expecting "sda1"; in this case, using -P shows
> /dev/sda1, which is what you want.
>
> Also, without -P, you have no idea which directory the device file is
> in. It can be in /dev, or it can be in /dev/disk/by-id, or /dev/mapper,
> or something else.

Alright, thanks!  I think a more robust AWK or sed script is desired to
strip out the header, though.  Perhaps this AWK script

    {
        while(1) {
            i = index($0, ":")
            cfg = /^[\t ]*config:/
            while(1) {
                if (getline != 1)
                    exit
                if (/[^\t ]/ && match($0, /[^\t ]/) <= i)
                    break
                if (cfg && /[^\t ]*\//)
                    print $1
            }
        }
    }

By the way, what do you think about my suggestion to use the crypttab(5)
to consider the relevant devices for unlocking at initramfs stage?

>> But I still think we can find a solution that's not FS-specific.  For
>> instance, to ensure that an arbitrary device is unlocked at initramfs
>> stage, you can add ‘initramfs’ to the 4th column of its crypttab(5)
>> entry.  In your case, that should be enough to copy the key files of
>> the underlying devices to the initramfs image.  Then — modulo #820888
>> — the initramfs boot script should be able to decrypt these devices
>> and mount the root FS.

Again, I'm not fond of your `zfs list` command because it's an
FS-specific alternative for two FS-agnostic and de facto standard
solutions, namely fstab(5) and kernel parameters.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20160919/bd1f9e8f/attachment.sig>