Cannot Use USB dev Inside Container Anymore

Also to note, that when I try to grep “usb” in git repo
I get

./build/dependencies/linux/HID_hidraw.node: binary file matches
./build/dependencies/linux/HID.node: binary file matches

And indeed these two files are installed locally with the DEB package

Yes, it looks like your device is 0003:2C97:1015.0011. But it is not available inside the container sysfs. You can try to pass through entire host sysfs to the container, but it’s not a safe option.

Also to note, that when I try to grep “usb” in git repo

this is a shared library, according to your strace it’s loaded by the cardano-hw-cli process.

First of all, you can try to start from creating /dev/hidraw0 device node in the CT with the same major/minor (from host). Or make bindmount for it.

Alright, gonna try that.
Also what makes me surprised is that,
This command does not output anything on host, but in guest, have a look:

~$ sudo udevadm control --reload-rules && sudo udevadm trigger --action=change 2>&1 | grep 2C97
0003:2C97:1015.0014: Failed to write 'change' to '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:2C97:1015.0014/uevent': Permission denied
hidraw0: Failed to write 'change' to '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:2C97:1015.0014/hidraw/hidraw0/uevent': Permission denied
0003:2C97:1015.0015: Failed to write 'change' to '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:2C97:1015.0015/uevent': Permission denied
hidraw1: Failed to write 'change' to '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:2C97:1015.0015/hidraw/hidraw1/uevent': Permission denied

It really seems like I don’t have the rights to discuss with the device.

Seems to work after I added:

$ lxc config device show usb01
  path: /dev/hidraw0
  source: /dev/hidraw0
  type: unix-char

and chown ubuntu: root, chmod cwr------- the passed dev.
Wonder what are these hidraw{0,1} devices?
(Edit) HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices — The Linux Kernel documentation
I do understand a bit better now.
Question is how are we supposed to mount these ?
And why the container cannot use the udev to build them himself ?

$ cardano-hw-cli device version
Error: Device is locked

which is the expected result right now.
Lets see tomorrow how it goes once I unlock it.

Everything went fine.
I could run all the needed operations.
By doing the udev rules on HOST,
Then doing the pass through for hidraw 0 and 1 from HOST to GUEST.

I would think perhaps the kernel’s USBIP should work also

1 Like

You may also be interested in this device type:

1 Like

Hi @tomp
Yes I did see while digging the topic,
But I got stuck/hesitating by a sentence in the intro.
Could you help me understand “Implementation depends on systemd-udev to be run on the host” ?
Can you extend/reformulate ?

Also what would be the difference with the unix-char type I used ?

Presumably that means it relies on udev events generated by systemd-udev to detect when a device is connected. It should still generate the same kind of device inside the container though.

1 Like

Erm I’ve tried but got the same KO result.

  mode: "600"
  type: unix-hotplug
  uid: "1000"
  vendorid: 2c97

This didn’t solved the thing.
Only when I do the following I can use my cli

  mode: "600"
  source: /dev/hidraw0
  type: unix-char
  uid: "1000"
  mode: "600"
  source: /dev/hidraw1
  type: unix-char
  uid: "1000"

Maybe I’m missing something but I don’t see how I should do this with unix-hotplug ?

1 Like

You’re right that isn’t what you want.

If you use unix-block or unix-char devices you can specify required=false and then the device is dynamically added/removed when the source path appears/disappears.