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