Tycmd doesn’t work in docker container

[isouriadakis]

Even though tycmd works at the computer which host the docker container, it doesn’t work in the docker container.

I am able to see the device in the docker container using ls -l /dev/.

I have included the 00.teensy udev rules.

Any thoughts on this?

[zerotohero]

I was also just trying to get this to work but with no luck. I'm not sure what tytools needs access to under the hood to work properly. If we could get some help making this work, it would be awesome!

[Koromix]

Hi,

I don't use docker. Can you give me a step-by-step procedure to make a container with tytools?

Regards,

Niels

[zerotohero]

Quick and dirty, this should get you to the point at which I left it:

Install Docker

 curl -fsSL https://get.docker.com -o get-docker.sh
 sudo sh get-docker.sh

Docker should now be installed, look at the output, you may need to run something like sudo usermod -aG docker $USER to be able to run Docker as your local user without sudo. docker ps should show running containers (there should be none after a fresh installation). If you see an error about not being able to connect to the docker socket, either try running with sudo or make a new terminal because maybe you aren't in the docker group yet.

Make a new folder, create a file inside called Dockerfile with the following:

FROM ubuntu:20.04 AS builder
RUN apt-get update && DEBIAN_FRONTEND=noninteractive TZ=Etc/UTC apt-get install git build-essential cmake libudev-dev qtbase5-dev pkg-config -y
RUN git clone -b v0.9.7 --single-branch https://github.com/Koromix/tytools.git \
    && cd tytools \
    && mkdir -p build/linux && cd build/linux \
    && cmake ../../ \
    && make \
    && make install

FROM ubuntu:20.04 AS writer
RUN apt-get update && apt-get install git curl python3-venv -y
COPY --from=builder /usr/local/bin /usr/local/bin
RUN python3 -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/master/scripts/get-platformio.py)"
ENV PATH="/root/.platformio/penv/bin:${PATH}"

This describes how the image is built. It should install tytools and platformio. You can then build the image by entering that new folder and running:

docker build -t tytools:local .

The image should build, and you should be able to launch a container with:

docker run -it --rm tytools:local bash

The -it tells docker to give you an interactive console, --rm deletes the container once it exits, and bash specifies a command to run as PID 1.

The other bits you may need to add are:
--privileged which will allow the container to access all devices (or specify a device with --device=[] which would be ideal from a security perspective).
Something like -v /dev/ttyACM0:/dev/ttyACM0 is what I was trying to use to pass /dev/ttyACM0 into the container running tytools. The -v flag is for mounting volumes inside of the container.

Obviously there's something that tytools is relying on that those 2 additional arguments didn't seem to be doing for me.

Appreciate you looking into this!

I guess I'll also add a quick comment on why docker integration is useful. Docker images contain and isolate all of the dependencies needed for some function/service. In an environment when you're constantly starting with fresh machines, installing dependencies and tools on the base OS can potentially have conflicts with other things. Docker allows any docker-compatible host to run a tool/service without having to worry about any potential conflicts, dependencies, etc.

[Koromix]

Thanks for the instructions :) I'll look into this over the weekend.

[zerotohero]

Did you end up getting a chance to look into this? I'm happy to run some additional tests. Since Docker is running in a containerized environment, I'm hoping it's just some service / log / directory that needs to be passed into the container to make it work. If you have any ideas, pass them on and I can try them out! I think it may be something related to libhs, since it seems like tytools relies on it?

[1saeed]

@zerotohero
I guess that the tytools care about getting information from the udev database, so then you can mount the host's udev database into the docker container, e.g:
you can run your container with -v /run/udev:/run/udev:ro

That works for me.

[zerotohero]

@1saeed Thanks for figuring that out! Awesome!

[zerotohero]

@1saeed I realized that when I do this, I still need to mount /dev as well. The devices are listed, but trying to upload firmware fails at the reset stage. tycmd sends the reset, and that's where the process fails.

      upload@10380930-Teensy  Uploading to board '10380930-Teensy' (Teensy 4.1)
      upload@10380930-Teensy  Triggering board reboot
      upload@10380930-Teensy  Reboot didn't work, press button manually

On the base OS, this works fine. Is there still some additional mount that is necessary, in addition to /dev and /run/udev?

[zerotohero]

In case it helps with debugging, I notice what ends up in dmesg -w is different based on whether I send the reset from the host or inside of a container.

This is tycmd reset --board=@usb-1-4-1 issued inside of the container

[ 2236.145426] usb 1-4.1: USB disconnect, device number 39
[ 2236.464622] usb 1-4.1: new high-speed USB device number 41 using xhci_hcd
[ 2236.589018] usb 1-4.1: New USB device found, idVendor=16c0, idProduct=0483, bcdDevice= 2.79
[ 2236.589024] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2236.589025] usb 1-4.1: Product: USB Serial
[ 2236.589027] usb 1-4.1: Manufacturer: Teensyduino
[ 2236.589028] usb 1-4.1: SerialNumber: 11414260
[ 2236.591536] cdc_acm 1-4.1:1.0: ttyACM2: USB ACM device

And this is tycmd reset --board=@usb-1-4-1 issued from the host:

[ 2361.841368] usb 1-4.1: USB disconnect, device number 41
[ 2362.097343] usb 1-4.1: new high-speed USB device number 42 using xhci_hcd
[ 2362.221594] usb 1-4.1: New USB device found, idVendor=16c0, idProduct=0478, bcdDevice= 1.07
[ 2362.221602] usb 1-4.1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[ 2362.221603] usb 1-4.1: SerialNumber: 00116AB2
[ 2362.223520] hid-generic 0003:16C0:0478.000A: hidraw1: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:14.0-4.1/input0
[ 2362.353366] usb 1-4.1: USB disconnect, device number 42
[ 2362.677379] usb 1-4.1: new high-speed USB device number 43 using xhci_hcd
[ 2362.801778] usb 1-4.1: New USB device found, idVendor=16c0, idProduct=0483, bcdDevice= 2.79
[ 2362.801784] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2362.801785] usb 1-4.1: Product: USB Serial
[ 2362.801787] usb 1-4.1: Manufacturer: Teensyduino
[ 2362.801788] usb 1-4.1: SerialNumber: 11414260
[ 2362.804480] cdc_acm 1-4.1:1.0: ttyACM2: USB ACM device

When the reset is issued from the host, it looks like the device disconnects, reconnects, and then disconnects again before finally becoming available. From the container, there is only 1 device disconnect.

The dmesg log is the same in the container and on the host, btw.