I am experiencing an issue where the container is not working on the new HEX refresh (E50UG). I am currently using RouterOS 7.16.1 and Firmware 7.16.1. Additionally, I am utilizing an external USB drive with a capacity of 64 GB for storage purposes.
Are there any known issues related to this that have been reported?
From those thin details, my only guess is that you’re trying to instantiate a 32-bit (ARMv6 or v7) OCI tarball on your shiny new 64-bit router. (ARMv8)
I am using ARMv6 and ARMv7 container images. Example:
/container/add remote-image=pihole/pihole@sha256:0f45324f7ef5cabd06170bd1f5042ca9e5aad88c531ed356b0bfeeae25eec71f interface=veth1 root-dir=disk1/pihole mounts=dnsmasq_pihole,etc_pihole envlist=pihole_envs
According to a past thread this is a 64-bit CPU, though possibly run in 32-bit mode. You have to target the CPU you’re running, not “ARM” generally. Details of word size affect kernel interfaces, etc.
Instead of targeting specific image layers, pull the image by name using “docker pull --platform=linux/arm/v7” method, then export an OCI tarball and instantiate the container from that. If that still doesn’t work, run it through a Skopeo pass and retry.
As far as I know, it’s a 32-bit ARM CPU. I can import the container, but it stops immediately when I try to start it. Additionally, no logs are generated, even when I activate container logging in the system/log settings.
I don’t see that you’re trying to start it after “add”. That isn’t automatic.
If you continue to have trouble, try one of my several single-static-binary containers. Going straight to Ubuntu or PiHole is playing the game on Hard mode and skipping the game tutorial besides.
That’s not how that one is documented as needing to be run. Being a “client” type program, it does start, run briefly, and then stop, quite on purpose. More to the point, if you don’t set up logging per those docs, you get no useful output from that run.
A better test here is my iperf3 container, which starts as a server and is therefore meant to keep running after starting.
If installing from Docker Hub directly doesn’t work, build a single-platform image from source. This not only avoids the question of which ARM, it lets you try them all in series until one works.
While I see what you’re trying there, @baragoon, have you actually made that work on RouterOS short of building a custom image? One of the many limitations of container.npk is that it won’t break a command like “tail -f /dev/null” up into three parts for you before calling “tail” as the entrypoint.
This is why I gave the “sleep 3600” hack in the linked article: I couldn’t think of a better hack with just two parts, one for ENTRYPOINT, one for CMD.
This issue aside, overriding the entrypoint commands like this only works when there’s a /bin/tail inside the container. That’s true of a good many, but not all, my own included. (It’s what “single static binary” means.)
You’re not using an external disk. You might want to try setting root-dir=usb1-part1/pihole or whatever path you have (noting that paths do NOT start with / in root-dir=). Perhaps PiHole is small enough for flash, but IDK.