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@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@yakkety:~# name=yakkety/ROOT/ubuntu
The variable expansion is to cut that to just the pool name:
root@yakkety:~# echo "${name%%/*}"
yakkety
Full zpool status output:
root@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@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@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@yakkety:~# zpool status "${name%%/*}" | awk '($1 ~ /\//) {print $1}'
root@yakkety:~# zpool status -P "${name%%/*}" | awk '($1 ~ /\//) {print $1}'
/dev/mapper/luks1
root@yakkety:~# zpool status -LP "${name%%/*}" | awk '($1 ~ /\//) {print $1}'
/dev/dm-0
--
Richard
signature.asc
Description: OpenPGP digital signature
