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!)
