For our application we need a number of different usb-devices thus calling for custom udev rules. I have trawled through all topics regarding udev rules and have compiled the test app below. The app has been tested using resin ssh showing that the desired device is not generated. The device gets displayed as /dev/ttyUSB0 when plugged in before boot but does not show up as /dev/fc_serial as required.
Some udev rules seems to be run, as a rule targeting addition of any usb device is run.
The udev fc-serial.rule works as expected in regular raspbian jessie and my ubuntu 16.04 laptop.
The application is running on a RPI3.
Dockerfile
FROM resin/%%RESIN_MACHINE_NAME%%-buildpack-deps
MAINTAINER Mathias H Egeberg mhe@sometext.com
# Switch on systemd init system in container and set various other variables
ENV INITSYSTEM="on" \
TERM="xterm" \
PYTHONIOENCODING="UTF-8"
WORKDIR /usr
COPY ./udev-rules /etc/udev/rules.d/
COPY ./startup.sh /usr/startup.sh
CMD bash ./startup.sh
Hi @mhe_lorenz
With the usb device attached, can you ssh into the running container (via the CLI or webterminal), run udevinfo -a -p $(udevinfo -q path -n /dev/tty/USB0) and post the output here?
any update here? I have several usb serial converters (the same model) that i need to predictably have enumerated using udev rules. i cant get this to work either.
@CameronDiver, this is indeed a great improvement that solves part of my initial problem. However, I need an option to edit the rules “runtime” from a container. Is this possible at the moment?
Apologies for the miscommunication, that project is primarily intended to update devices remotely (I don’t know that we’ve ever considered running it from a container!).
Taking a step back, would you mind describing a little bit more about how you need to configure these devices, and why that must be done from the container? Understanding a bit more about your use-case will better help us recommend solutions.
Editing runtime is probably not the right way to phrase it. Let me elaborate a bit on our thoughts.
What I would like to a achieve is a “self-contained” device that is capable of configuring itself while only interacting with the Balena Cloud. Since BalenaOS is build to serve containers I thought that would be the natural approach.
Our devices are connected to various hardware which is not under our control and thus we need to edit the udev rules. The devices are offline most of the time since they are powered by portable devices that is only turned on while in use.
Finally, we would like editing of the udev rules to versioned along with the rest of the application.
Hi,
Yeah this is something that we want to have in our product as a feature, but currently we don’t have support for this. Approaches that we where thinking about would be to add an api for this to the supervisor, which will allow your application to issue udev rules and trigger udev reloads on the device. Would this approach work for you?
I’m adding this to our internal feature request ticket, so that we can update this thread when we have some progress on it. The mentioned project from above is our current bridge gap solution for the problem.