Bug#774762: try harder to find reasons for failed `lvchange -an` by looking at /proc/*/mountinfo

2015-01-13 Thread chrysn
I'd say the best who-uses tool in this case is lsblk [...] LVM itself already uses this tool within helper blkdeactivate script [...] so you see a chance that lvm could delegate the diagnoistic messages for where to find the offending mount point to lsblk (or dmsetup or findmnt, but lsblk is

Bug#774762: try harder to find reasons for failed `lvchange -an` by looking at /proc/*/mountinfo

2015-01-13 Thread Peter Rajnoha
On 01/13/2015 09:43 AM, chrysn wrote: I'd say the best who-uses tool in this case is lsblk [...] LVM itself already uses this tool within helper blkdeactivate script [...] so you see a chance that lvm could delegate the diagnoistic messages for where to find the offending mount point to

Bug#774762: try harder to find reasons for failed `lvchange -an` by looking at /proc/*/mountinfo

2015-01-07 Thread chrysn
Package: lvm2 Version: 2.02.111-2 Severity: wishlist when an `lvchange -an ...` fails, lvm tries to give a better reason than is currently in use by looking at /sys/dev/block/.../holders and /proc/self/mountinfo when --verbose is given. it was pointed out to me that i could look at

Bug#774762: try harder to find reasons for failed `lvchange -an` by looking at /proc/*/mountinfo

2015-01-07 Thread Peter Rajnoha
I'd say the best who-uses tool in this case is lsblk - it's directly a part of util-linux which is everywhere and it shows quickly the block device tree as well as mount status (it just looks at sysfs info and provides it in nice human readable form, machine readable form is also possible though