Alpine 3.13 Tag Containers Don't Start on ARMv7

[jvilalta]

Hi

Thanks for maintaining this image. I don't know that this is an issue you can fix but wanted to let you know that the Alpine 3.13 container fails to start in this environment/hardware:
Raspberry PI
ARMv7
Debian 10.6
This is the command that fails and the output:
sudo docker run --rm -it --device /dev/bus/usb/001/005 hertzg/rtl_433:alpine-3.13-latest
rtl_433 version 20.11 branch at 202011122224 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/root/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 145 out of 175 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 ]
Assertion failed: clock_gettime(1, tp) == 0 (libusbi.h: usbi_get_monotonic_time: 497)

This image/command works fine:
sudo docker run --rm -it --device /dev/bus/usb/001/005 hertzg/rtl_433:alpine-3.12-latest

Feel free to close this if it is not something that can be fixed on your side.

[hertzg]

Hello,

I'm glad you found the docker images useful, this is a known issue. As a workaround I've recently introduced alternative builds based on alpine:3.12 which you have already found in your second example 👍 (see #3 if you want details).

For now the only workaround is to use any image based on alpine 3.12.
You can access those images by hertzg/rtl_433:alpine-3.12-* where * can be any valid rtl_433 version, master or latest respectively.

Example:

$ docker run --rm -it --device /dev/bus/usb/001/005 hertzg/rtl_433:alpine-3.12-latest

I am not sure if the rtl_433 or it's dependencies support alpine and musl so I'm currently working on introducing images built based on debian images and change the :latest tag to target those. The alpine based images would still stay but be an "opt-in" variant.

[hertzg]

I've just pushed a build pipeline which provides debian builds. Maybe you could give it a try and see if it resolves the issue.

https://github.com/hertzg/rtl_433_docker/actions/runs/565743906

Once the pipeline finishes you can try:

$ docker run --rm -it --device /dev/bus/usb/001/005 hertzg/rtl_433:debian-buster-latest
# or
$ docker run --rm -it --device /dev/bus/usb/001/005 hertzg/rtl_433:debian-bullseye-latest

[jvilalta]

debian-buster-latest worked for me. bullseye throws the same error as alpine.

thank you.

[mpuff]

you need to install this for the new alpine docker image:

wget http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.4.4-1~bpo10+1_armhf.deb
sudo dpkg -i libseccomp2_2.4.4-1~bpo10+1_armhf.deb

than it should work ;)

[hertzg]

dpkg -i

AFAIK Alpine Linux is not a Debian derivative. I’m not sure why that package would be required. If you can elaborate a bit maybe we could whip up a PR for this but so far I don’t see how that is related to the libusb issue.

[mpuff]

I had this problem also on another alpine docker image. Than i have updated this container, same error, after the installation of this libusb was the container starting again.
I found this info in another chat

[hertzg]

For people who are still experiencing this or who just endded up here from search engines, you can find the workaround and summary on another issue.