umount: Resolve btrfs subvolume mountpoints

[wyu71]

When umount.udisks2 is invoked for a btrfs subvolume mountpoint, stat() may return the anonymous btrfs device number instead of the backing block device. This makes the helper fail to find the matching UDisks object.

Look up the btrfs mount source from /proc/self/mountinfo before falling back to the mountpoint device number.

Fixes #1495

[wyu71]

Testing Farm failure is unrelated to this change.

The failure is in EXFATTestCase.test_* tests:

No such interface 'org.freedesktop.UDisks2.Filesystem' on object at /org/freedesktop/UDisks2/block_devices/sdd

This PR only touches the umount.udisks2 helper and does not affect filesystem interface detection. The issue appears to be a test environment problem with exFAT support on the /dev/sdd device.

Could you re-run the Testing Farm check?

[vojtechtrefny]

Testing Farm failure is unrelated to this change.

The failure is in EXFATTestCase.test_* tests:

That's caused by some changes in the latest exfatprogs, I am already working on fixing this (storaged-project/libblockdev#1199), you can ignore these failures.

[vojtechtrefny]

/packit test

[wyu71]

/packit test

[jlmxyz]

is there any review planned? so that it's integrated into a release? it is problematic to have to umount the disk by root user
I tested it as a local patch using PCManFM-Qt and it works for umount, however there is still a error when mounting "the operation was cancelled" but this don't affect the mount itself (just have to reselect the drive after and access content)

[wyu71]

Thanks for testing and confirming the umount fix works.

The mount-side "operation was cancelled" error looks unrelated to this PR — this change only touches the umount.udisks2 helper and doesn't affect the mount code path. It might be worth opening a separate issue for the mount behavior so it can be looked into on its own.