[pkg-cryptsetup-devel] Bug#902449: cryptsetup-initramfs: auto-detection of zfs pool(s)

[Guilhem Moulin]

Control: severity -1 wishlist

Hi,

On Tue, 26 Jun 2018 at 23:34:20 +0200, Fabian Grünbichler wrote:
> cryptsetup: ERROR: Couldn't normalise device rpool/ROOT/debian
> cryptsetup: ERROR: Couldn't find sysfs directory corresponding to 
>   rpool/ROOT/debian

I guess you had a fake line for that device in your /etc/fstab and
that's why up to 2:2.0.3-1 the hook script didn't complain about not
being able to normalize the device?  In that case it's not caused by the
package split per se, but by the hook using /proc/mounts rather than
/etc/fstab to find which device is holding / (and /usr).

> I wonder whether you'd accept a patch contributing detection of zpool
> devices in the cryptroot hook? it is a bit cumbersome, as the only way to
> get this information from ZFS is by parsing 'zpool status' output, which
> contains a lot of extra information and is not very well-defined (thus,
> potential for breakage in the future).

I'm really not keen on having to run `zpool status` or `zpool list` and
parse its output.  We used to do something like that (parse `btrfs
filesystem show`) for btrfs but we're now using proc(5) and sysfs(5)
which gives a unified solution for all components in the block device &
FS stack we've supported up to now: mapped devices (in particular LV and
dm-crypt), MD, mutiple device btrfs.  We could painlessly extend the
stack to other virtual block devices as long as the driver exposes a
sysfs directory /sys/dev/block/$maj:$min; as well as file systems
spanning over multiple devices, as long as the driver lists the slaves's
sysfs directories in /sys/fs/$FSTYPE/$UUID/devices.

Unfortunately the ZFS driver exposes neither directory to the sysfs(5)
pseudo-filesystem.  Personally I'd rather avoid FS-specific code in the
hook script.  Especially if it involves parsing the non-machine-readable
output of an FS-specific command.

> at the very least, it would be nice to detect this unsupported situation
> and print a proper warning instead of the generic one.

Yes indeed, we can definitely have a list of known unsupported FS:es,
either skip the warning altogether, or tell the user to add the
'initramfs' option to the crypttab(5) entries corresponding to the
underlying devices.

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