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

[Richard Laager]

On 09/18/2016 02:13 PM, Guilhem Moulin wrote:
> On Sat, 17 Sep 2016 at 19:37:23 -0500, Richard Laager wrote:
>> I have changes all ready-to-go for supporting LUKS, but this "bug"
>> (read: feature request) is a blocker. It is possible to work-around this
>> with (otherwise unused) /etc/fstab entries, but I don't want to
>> encourage that in the wild, lest it cause some other problem in the future.
> 
> The fstab(5) entry for the root FS is never required, is it?

No, I don't think so.

And ZFS *never* uses /etc/fstab, for the root FS or any FS.

> Mine is
> mounted (at initramfs stage) using the “root=” and “rootflags=” kernel
> parameters.  In theory that should work for ZFS as well, but it seems
> like it's currently not the case (cf. #820888).

I looked into 820888 some more. That person is doing 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.

I completely agree with your analysis that it is not immediately
apparent why cmdline_root is getting set to root=ZFS=..., and that they
should enable debugging to help figure that out.

I commented to this effect on that bug report.

> 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.

> Configuration for the cryptroot initramfs hook script is now to be
> placed in /etc/crytsetup-initramfs/conf-hook.

Thanks for letting me know. I've made a note and will adjust this in
the HOWTO once this lands in Ubuntu.

> since it's run as a subprocess, it's not possible to set UMASK in
> the hook itself.

Right, this is probably something I'd have to bring up with
initramfs-tools, not cryptsetup. And cryptsetup integration aside, I'm
not entirely sure why it can't use a restrictive umask by default.

> 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.

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.

You can also add -L to resolve symlinks. (Using -L without -P gives the
basename of the resolved symlink.)

Here is my test system running Ubuntu 16.10 "Yakkety" with LUKS:

root at yakkety:~# zfs list -H -o name,canmount,mountpoint
yakkety	off	/
yakkety/ROOT	off	none
yakkety/ROOT/ubuntu	noauto	/
yakkety/home	on	/home
yakkety/home/root	on	/root
yakkety/var	off	/var
yakkety/var/log	on	/var/log
yakkety/var/spool	on	/var/spool
yakkety/var/tmp	on	/var/tmp

Here's what the loop would do with that:

root at yakkety:~# name=yakkety/ROOT/ubuntu

The variable expansion is to cut that to just the pool name:

root at yakkety:~# echo "${name%%/*}"
yakkety

Full zpool status output:

root at yakkety:~# zpool status -P "${name%%/*}"
  pool: yakkety
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
	still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
	the pool may no longer be accessible by software that does not support
	the features. See zpool-features(5) for details.
  scan: none requested
config:

	NAME                 STATE     READ WRITE CKSUM
	yakkety              ONLINE       0     0     0
	  /dev/mapper/luks1  ONLINE       0     0     0

errors: No known data errors
root at yakkety:~# zpool status "${name%%/*}"
  pool: yakkety
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
	still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
	the pool may no longer be accessible by software that does not support
	the features. See zpool-features(5) for details.
  scan: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	yakkety     ONLINE       0     0     0
	  luks1     ONLINE       0     0     0

errors: No known data errors

root at yakkety:~# zpool status -LP "${name%%/*}"
  pool: yakkety
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
	still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
	the pool may no longer be accessible by software that does not support
	the features. See zpool-features(5) for details.
  scan: none requested
config:

	NAME         STATE     READ WRITE CKSUM
	yakkety      ONLINE       0     0     0
	  /dev/dm-0  ONLINE       0     0     0

errors: No known data errors

Final output:

root at yakkety:~# zpool status "${name%%/*}" | awk '($1 ~ /\//) {print $1}'
root at yakkety:~# zpool status -P "${name%%/*}" | awk '($1 ~ /\//) {print $1}'
/dev/mapper/luks1
root at yakkety:~# zpool status -LP "${name%%/*}" | awk '($1 ~ /\//) {print $1}'
/dev/dm-0

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20160919/7ad115ec/attachment.sig>