I’m trying to get Balena to run OpenWRT as a docker image. There is an existing Docker build for OpenWRT on a Raspberry Pi3 here: GitHub - oofnikj/docker-openwrt: OpenWrt running in Docker.
It uses make as a pre-docker step for getting the image, which is not too bad - once you get the image, you can just keep it in the working directory of the git, and then it will automatically be uploaded to Balena when you do a balena push appname. The whole thing builds successfully locally on my MacBook (x86_64), with qemu, squashfs and fakeroot, homebrew/cask/docker and docker installed as an armvirt-64 image. When I start it, I can expose e.g. ports 22 and 80, and then ssh into the container or use the OpenWRT Luci web interface.
However, when I use it with Balena on a Raspberry Pi 3 64bit image, then it seems there is a problem with init. Init gets started, but it then terminates instantly. I get the following log messages (which according to https://pastebin.com/XiJzJbLb seems to be from init or preinit:
15.04.21 09:59:46 (+1000) openwrt Press the [f] key and hit [enter] to enter failsafe mode
15.04.21 09:59:46 (+1000) openwrt Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
15.04.21 09:59:51 (+1000) Service exited 'openwrt sha256:84c4ee5cd2189f1fbb51a70b1e674e56ee3be3a8ebc9234b0876cef2f2861117'
I am wondering if there is a substantial difference between a “normal” docker and the docker that’s run on the RasPi 3 64bit, so that init does not work as expected?
Hey @georg, the engine in balenaOS is a fork of the official Moby (Docker) project that has been trimmed down to better support IoT devices and minimal writes to local storage.
I did notice that the tty value you have in your compose file will not be respected by the balena supervisor. We don’t have a true docker-compose system in balenaOS and instead rely on the supervisor to perform similar tasks based on a compose file. Also you don’t need the ports: or expose: values if you are running in host networking mode, but that wouldn’t break anything.
A full list of supported compose fields are here:
So to answer your question, most Docker functionality should be identical and we would need some more details to determine exactly why the init script is failing at that stage. Your repo is quite impressive, but you may need to take a look at the source code for that init binary to see what is breaking or enable debugging. You could also try skipping /sbin/init and go straight to /etc/init.d/rcS and see if the behaviour changes?
Yes, I recompiled OpenWRT from scratch and uploaded a new root filesystem. The boot process seems to work now, even though the web interface seems to be very slow, and I’m not sure all routing is working as expected yet. I’m updating the supervisor on the BalenaOS to the latest version to see if that helps. It looks a bit as if the docker image didn’t have any storage mounted. I’m unable to set a password through the web UI and save it. However, it looks much better now.
My git repo has the latest changes if you want to try it out.
Awesome to hear you’ve made such progress, @georg!
It looks a bit as if the docker image didn’t have any storage mounted
The way your compose file is configured there should be a volume in /data but if you can’t write to it maybe there is a permissions issue in your rootfs?
Let us know if there is anything else we can to do help! Great work so far!