Hello Paul Martin. Thanks for your bug report.
On Fri, Sep 11, 2015 at 12:31:09AM +0100, Paul Martin wrote: > Package: util-linux > Version: 2.27-1 > Severity: important > Control: affects -1 cryptmount > > This breaks cryptmount when run as a user. [...] > It is possible to work around this change in behaviour by adding /sbin > to the PATH, thus: > > $ PATH=$PATH:/sbin /sbin/fsck /dev/null > fsck from util-linux 2.27 > e2fsck 1.42.13 (17-May-2015) > fsck.ext2: Inappropriate ioctl for device while trying to open /dev/null > [etc] See https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=a03bdbcd2029ed1b002d45a028f6e706845fa566 There was also a discussion on the upstream mailing list about this. We can't have it both ways. Some people want PATH to be used instead of hard-coding paths to search for fsck.* helpers, now you report that passing an incorrect PATH will not work and you want it hard-coded.... I'm inclined to reassign this bug report to cryptmount saying it should pass a valid (or unset!) PATH. (Please note that there are already packages who no longer ships their fsck.* helpers in /sbin, so unset path (and relying on hard-coded /sbin path) will not work for those.... See btrfs tools for example. Given that it apparently is the wish from maintainers of fsck.* helpers maintainers to be able to spread their tools around, it's now the callers responsibility to include all their paths in the call to fsck if you want them included....) Do you have any other suggestions on how to handle this? If you still think this is a util-linux issue, could you please argue your case on the upstream mailing list directly? Regards, Andreas Henriksson
