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

[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 lsblk (or dmsetup or findmnt, but
> lsblk is probably the most suitable of those)?
> 
> if yes, i'd open a similar bug against util-linux (lsblk does not do any
> better than lvm in container conditions at the moment), and keep this
> only open to track lvm's progress on delegating to lsblk.
> 

We've recently opened an LVM2 upstream bug to check for holders across
containers (https://bugzilla.redhat.com/show_bug.cgi?id=1181029). Still,
this will just stop LVM from doing certain actions (this support in LVM
will be only LVM specific for its own purposes if it detects the
device is in use). But LVM itself won't provide you as much info here
as lsblk could.

So yes, I think lsblk should be enhanced here a bit as well to take
containers more into account if it doesn't do so currently. This way
more people can make use of this info and they won't need to look
for it themselves in various places all around the system.