Issue with container not working on new HEX Refresh (E50UG)

Hello.

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?

Thank you for your assistance.

Best regards.

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)

If you want better guesses, give more details.

Hello.

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

https://hub.docker.com/layers/pihole/pihole/latest/images/sha256-0f45324f7ef5cabd06170bd1f5042ca9e5aad88c531ed356b0bfeeae25eec71f?context=explore

Regards.

Please clarify “not working” - container not importing, container not starting, etc.?
Any errors in the logs?

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.

MikroTik information about the HEX refesh: https://cdn.mikrotik.com/web-assets/product_files/E50UG_241013.pdf

Please review the image I have attached.

I will check on this: https://tangentsoft.com/mikrotik/file?ln=23&ci=trunk&name=tinyproxy%2FMakefile
container.png

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.

When I click “start” or run the command /container/start 0, it starts but then stops immediately. There is no log generated.

I just imported the container using the following command: /container/add remote-image=tangentsoft/speedtest-cli:latest interface=veth1. https://hub.docker.com/r/tangentsoft/speedtest-cli

The same issue occurs.

[admin@HEX] > /container/add remote-image=tangentsoft/speedtest-cli:latest interface=veth1
[admin@HEX] > /container/
[admin@HEX] /container> pr
 0 name="70defa36-fdc2-4c2d-a688-2f7b8e3c86ab" tag="tangentsoft/speedtest-cli:latest" os="linux" arch="arm" interface=veth1 mounts="" dns="" workdir="/" status=stopped 
[admin@HEX] /container> pr detail 
 0 name="70defa36-fdc2-4c2d-a688-2f7b8e3c86ab" tag="tangentsoft/speedtest-cli:latest" os="linux" arch="arm" interface=veth1 mounts="" dns="" workdir="/" status=stopped 
[admin@HEX] /container> start 0
[admin@HEX] /container> pr
 0 name="70defa36-fdc2-4c2d-a688-2f7b8e3c86ab" tag="tangentsoft/speedtest-cli:latest" os="linux" arch="arm" interface=veth1 mounts="" dns="" workdir="/" status=stopped 
[admin@HEX] /container>

container3.png

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.

you could also try to set
tail -f /dev/null
for your Endpoint/CMD to test container start

/dev/null ??

yes, to simulate succesfull app start inside the container

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.)

Still not working:

/container add remote-image=tangentsoft/speedtest-cli:latest interface=veth1 logging=yes
/container start 0



[admin@HEX] /system/device-mode> pr
       mode: enterprise
  container: yes

You can see log and commands in image.

I guess is a problem with HEX Refresh (E50UG) itself.

Any advice?
container4.png

Not working also:

/container add remote-image=tangentsoft/iperf3:latest interface=veth1 start-on-boot=yes logging=yes
start 0

Please check on image
container5.png

Updated to 7.17beta6 and now there is a log
container 9ae1426b-d2ed-4c77-83d5-79bad11b5f7b exited, signal: 4
container6.png

same

container df6f9c79-2fac-4cb6-99ed-3de5322e9884 exited, status: 255

Hello.

MikroTik support confirmed:

OÄĽegs Ĺ .5 days ago 2:43 PM
Hello,

It is a known issue, we hope that fix will be implemented in next public RouterOS version.

Best regards,

Regards.

Sweet, now I don’t have to try :laughing:

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.