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

[Fabian Grünbichler]

On Wed, Jun 27, 2018 at 12:56:04PM +0200, Guilhem Moulin wrote:
> 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).

no, never had a fake fstab line, there were always warnings about not
being able to detect the device for /, but now they got more verbose and
there are two, so I took the opportunity to file this bug.

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

maybe I'll give that a shot on the ZoL side - this would be nice to have
in general, not just for cryptsetup's use case.

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

understandable.

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

I think I'd prefer a two-step approach:
- warn by default on known non-detectable file system in
  get_mnt_devices, pointing to crypttab (to help with initial setup, and
  for users that might benefit from this assistance)
- allow silencing of detection warnings (once the setup is known to
  work)

the latter might be a simple on/off switch, or a whitelist of ignored
(i.e., manually setup) filesystems, or a whitelist of ignored (i.e.,
manually setup) mountpoints.

thanks for your consideration (and work on cryptsetup!)