Because the container is privileged, the devices part isn’t necessary. However, in the container, everything in /dev is available (like /dev/ttyAMA0 and /dev/ttyS0), but not the serial0/ serial1.
I’ve tried using a Balena base image, and only with UDEV turned on, they show up.
I don’t want to use the Balena base image though, because my container is now 5.5MB and when I’m using the base image, it’s around 90MB.
Anyone has any idea how I can fix this problem? serial0 is much more reliable to use for every device than using ttyAMA0 or ttyS0.
I’m using the Raspberry Pi 4 as well as the Raspberry Pi 3.
The balena base image where it did show up was the balenalib/raspberrypi4-64-alpine, with UDEV enabled using UDEV=on. Without the UDEV property, it didn’t work.
Anyone has any idea how I can fix this problem? serial0 is much more reliable to use for every device than using ttyAMA0 or ttyS0.
Yes, simply add symbolic links in your entrypoint/cmd to these, to match Raspbian behaviour, where /dev/serial0 and /dev/serial1 are symbolic links which point to either /dev/ttyS0 or /dev/ttyAMA0.
Thanks for your suggestion. I know they’re symbolic links to ttyS0 or ttyAMA0. However, they’re created by the OS itself and determined by whether the miniuart-bt dtoverlay is set. If it’s set, serial0 is ttyAMA0. If not, it’s pointing to ttyS0.
Now, I can imagine you might say “use miniuart-bt on all your devices then”, but because of an issue that happened recently, which took quite some time to debug on our running devices, I’d like to use the serial0 symlink of the OS itself. If the miniuart-bt overlay was overwritten, the application would still function.
Here’s the logic (example) of what UDEV=on does in our base images. You should be able to extract it and implement in your own (smaller) container image(s).