mbed-tool detect doesn't detect mbed devices inside docker

[saheerb]

Describe the bug
docker environment will become the common method to execute tests against mbed devices, especially when H/W testing is moved to LAVA in CI. A linux host machine will run docker, and mbed devices will be passed through to docker as explained here

Though the detection of devices work in mbed-cli-v1 (mbedls), mbed-tools detect doesn't list any device.

To Reproduce
Steps to reproduce the behavior:

1. In Linux host machine (USB pass through will work only in Linux host): install docker if not already present. Connect an mbed device, for example, K64F.

2. In Linux host machine, run docker container:
   docker run -it --privileged -v /dev/disk/by-id:/dev/disk/by-id -v /dev/serial/by-id:/dev/serial/by-id ghcr.io/armmbed/mbed-os-env:master-latest

3. mount usb device and execute mbed-ls
   mount /dev/sdb /mnt

# mbedls
| platform_name | platform_name_unique | mount_point | serial_port  | target_id                                        | interface_version |
|---------------|----------------------|-------------|--------------|--------------------------------------------------|-------------------|
| K64F          | K64F[0]              | /mnt        | /dev/ttyACM0 | 0240000048824e450041700fdedd003598d1000097969900 | 0253 

4. run mbed-tools detecte

# mbed-tools detect  
No connected Mbed devices found.

Expected behavior
mbed-tools detect the mbed device.

Desktop (please complete the following information):
Any linux host that can run docker

Mbed (please complete the following information):

# mbed-tools --version
7.31.0

Additional context
Add any other context about the problem here.

[LDong-Arm]

@ARMmbed/mbed-os-core A difference between container and host is the USB mount (from which we extract device info) is mounted to a user specified destination? Could it be that mbed-tools's detection algorithm makes certain assumptions on path to mount point? (Just my suspicion - I'm not familiar with this part of mbed-tools).

[rwalton-arm]

The problem seems to be that udevd isn't running inside the container, and mbedtools tries to query properties udevd generates after being sent a connection event by the kernel. Specifically the ID_BUS property is not available in this container setup, which mbedtools uses.

mbedls greps disk/by-id directly to discover disk IDs, then tries to find a corresponding USB block device in sysfs. This is re-implementing part of what udevd would usually do. The mbedls approach is more robust in this particular instance because we pass the disk/by-id paths to the container. However those disk/by-id paths are actually created by udev, so any "non-container" host would be running udevd if those paths exist. So, I don't think re-implementing the mbedls approach in mbedtools is worth the added code complexity, when udev is generally always available in Linux distros.

A workaround here would be to mount /run/udev in the container, then we shouldn't need to run the udev daemon inside the container itself. When I tested thismbedtools detect worked as expected.

[LDong-Arm]

@saheerb Did the suggestion above fix the problem? Can we close this issue?

[saheerb]

Yes, mbed-tools detect works if /run/udev is mounted on to the docker image. Ran ctests too inside docker image. All good.

Step to run (for reference):

• docker run -it --privileged -v /dev/disk/by-id:/dev/disk/by-id -v /dev/serial/by-id:/dev/serial/by-id -v /run/udev:/run/udev:ro ghcr.io/armmbed/mbed-os-env:master-latest
• mount /dev/sdb /mnt
• Then follow: https://github.com/rwalton-arm/mbed-os/blob/gtea_test_readme/tools/cmake/README.md#how-to-build-and-run-greentea-tests