udiskctl is unable to open the block device during power-off as part of udisk mass storage detach operation.
The following error message is reported
$ udiskctl power-off -b /dev/sdb
Error powering off drive: Error opening /dev/sda: Device or resource busy (udisks-error-quark, 0)
This causes subsequent plug-ins of mass storage devices to be
named sequentially i.e sda, sdb, sdc and so on instead of having
consistent naming sda.
Which version of our BSP are you using?
Make sure that you unmount the device first:
udisksctl unmount -b /dev/sdbX
Our BSP uses an udev rule to automount devices (which makes sure that automount also works in console images). In 2.8b1 systemd actually contains that service in a mount namespace (see #34155). This could cause the issue you are seeing. You can check whether the disk is mounted in another namespace using:
tail -n +1 -- /proc/*/mounts | grep sdb
This will be fixed with 2.8b2. If you use udisks to manage mounting you might consider removing the automount rule anyway:
rm /etc/udev/rules.d/automount.rules
We have tested after unmounting the device
root@colibri-t20:~# udiskctl umount -b /dev/sdbX
root@colibri-t20:~# udiskctl power-off -b /dev/sdb
Error powering off drive: Error opening /dev/sda: Device or resource busy (udisks-error-quark, 0)
Even when the udev automount.rules are disabled the above
behaviour was noted. With further debugging, we found that this
problem was not specific to udisk, rather umount from the
command-line also has the same problem. This issue still exists
in the latest version 2.8b2.
We suspect that the issue is due to incorrect mount / unmount
propagation. We suspect that “mount events” are being propagated
to service namespaces created by systemd, but “unmount events”
are not getting propagated. And that is keeping the USB device
busy, even after unmounting. We tried the following workaround:
root@colibri-t20:~# mount --make-rprivate /
After the above command, the device naming is consistently “sda”,
across plug, mount, unmount, unplug cycles. Please do let us
know, what would be the correct approach to fix this.
In my test, after removing automount.rules and rebooting it worked fine…
Can you check whether there are really no mounts in other namespaces?
tail -n +1 -- /proc/*/mounts | grep sdb
We are using 2.8b1…
Actually after unmount there are no mounts in
tail -n +1 -- /proc/*/mounts | grep sdX
but the device is still busy as udiskctl reports device busy as mentioned previously during
udiskctl power-off /dev/sdX, thereby resulting in the
sequentially naming problem sda, sdb, sdc… during subsequent
plug-ins of the pendrive. We want consistent naming of device
which is the expected behaviour.
We found that on booting the board without systemd i.e by using
bootargs init=/bin/sh the sequential naming of USB Mass storage
devices on subsequent plug-ins did not occur. We tried to
reproduce the problem in this environment by creating multiple
namespaces in various modes and testing different plug, mount,
umount, unplug cycle scenarious.
We were unable to reproduce the issue. But incidently, we found
that the minimal kernel version requirements were not met as per
systemd README systemd/README at v234 · systemd/systemd · GitHub
i.e systemd 234 requires kernel version >= 3.13.
We found that on booting the board without systemd i.e by using bootargs init=/bin/sh the sequential naming of USB Mass storage devices on subsequent plug-ins did not occur. We tried to reproduce the problem in this environment by creating multiple namespaces in various modes and testing different plug, mount, umount, unplug cycle scenarious.
We were unable to reproduce the issue. But incidently, we found that the minimal kernel version requirements were not met as per systemd README https://github.com/systemd/systemd/blob/v234/README i.e systemd 234 requires kernel version >= 3.13.
Yes, however, we did backport a few more things in order to be able to keep using later systemd versions. What you have discovered may be a regression thereof. I also tried using the mainline Linux kernel with our latest regular BSP 2.8b2 demo image and it did also not exhibit the issue. So it has clearly to do with the downstream Linux kernel 3.1.10.
I did open a ticket and we will analyse the situation further.
Thanks for reporting this issue.
after unmount there exist some mounts,
tail -n +1 -- /proc/*/mounts | grep sdX
how can i unmount these things
Hi @yel568 !
This thread is from 2018.
If you are facing any issues, please, first try using our latest BSP 5. If you still face some issue, please post a new question describing it.
Best regards,