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.
signature.asc
Description: PGP signature
