Page 1 of 1

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

Posted: Tue Nov 19, 2024 11:31 pm
by alejot17
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.

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

Posted: Wed Nov 20, 2024 7:01 am
by tangent
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.

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

Posted: Wed Nov 20, 2024 4:05 pm
by alejot17
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/pi ... xt=explore

Regards.

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

Posted: Wed Nov 20, 2024 4:30 pm
by baragoon
Please clarify "not working" - container not importing, container not starting, etc.?
Any errors in the logs?

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

Posted: Wed Nov 20, 2024 4:32 pm
by tangent
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.

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

Posted: Wed Nov 20, 2024 4:59 pm
by alejot17
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/pro ... 241013.pdf

Please review the image I have attached.

I will check on this: https://tangentsoft.com/mikrotik/file?l ... 2FMakefile

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

Posted: Wed Nov 20, 2024 5:08 pm
by tangent
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.

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

Posted: Wed Nov 20, 2024 5:20 pm
by alejot17
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> 

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

Posted: Wed Nov 20, 2024 6:32 pm
by tangent
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.

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

Posted: Wed Nov 20, 2024 6:36 pm
by baragoon
you could also try to set
tail -f /dev/null
for your Endpoint/CMD to test container start

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

Posted: Wed Nov 20, 2024 6:42 pm
by Larsa
/dev/null ??

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

Posted: Wed Nov 20, 2024 7:04 pm
by baragoon
yes, to simulate succesfull app start inside the container

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

Posted: Wed Nov 20, 2024 7:26 pm
by tangent
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.)

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

Posted: Wed Nov 20, 2024 7:35 pm
by alejot17
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?

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

Posted: Wed Nov 20, 2024 7:37 pm
by alejot17
Not working also:
/container add remote-image=tangentsoft/iperf3:latest interface=veth1 start-on-boot=yes logging=yes
start 0
Please check on image

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

Posted: Wed Nov 20, 2024 7:41 pm
by alejot17
Updated to 7.17beta6 and now there is a log
container 9ae1426b-d2ed-4c77-83d5-79bad11b5f7b exited, signal: 4

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

Posted: Sun Nov 24, 2024 5:57 am
by yuban10703
same

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

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

Posted: Tue Nov 26, 2024 5:16 pm
by alejot17
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.

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

Posted: Tue Nov 26, 2024 5:19 pm
by holvoetn
Sweet, now I don't have to try :lol:

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

Posted: Tue Nov 26, 2024 5:28 pm
by Amm0
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.

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

Posted: Tue Nov 26, 2024 6:11 pm
by holvoetn
Sweet, now I don't have to try :lol:
And yet I did ...

tiny teeny container run from usb1 and it seems to work.
2024-11-26 17:09:33 container,info,debug layer sha256:4c3160818a1f052453d094c490acbae70caa44bbed5fe8ea47be90c560c515fc
downloaded
2024-11-26 17:09:33 container,info,debug import successful, container 22b5601d-cd96-45df-a4f6-7b74fa7a592e
2024-11-26 17:09:47 container,info,debug container 22b5601d-cd96-45df-a4f6-7b74fa7a592e started
2024-11-26 17:09:47 container,info,debug Hello, world!
2024-11-26 17:09:47 container,info,debug container 22b5601d-cd96-45df-a4f6-7b74fa7a592e exited, status: 0
2024-11-26 17:09:52 system,info item changed by tcp-msg(winbox):xyz@192.168.10.50 (/container set *2 dns="" file=
"" interface=veth1 logging=yes mounts="" remote-image="" workdir=/)
2024-11-26 17:11:03 system,info,account user xyz logged in from 192.168.10.50 via winbox

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

Posted: Fri Nov 29, 2024 8:57 pm
by alejot17
Hello.

It works only with linux/arm/v5: 15:22:33 container,info,debug (arm32v5)
I just tested with:
/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/pull
/container/add remote-image=hello-world:latest interface=veth1 root-dir=disk1/hello logging=yes dns=8.8.8.8
Results:
15:22:33 container,info,debug Hello from Docker!
15:22:33 container,info,debug This message shows that your installation appears to be working correctly.
15:22:33 container,info,debug 
15:22:33 container,info,debug To generate this message, Docker took the following steps:
15:22:33 container,info,debug  1. The Docker client contacted the Docker daemon.
15:22:33 container,info,debug  2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
15:22:33 container,info,debug     (arm32v5)
15:22:33 container,info,debug  3. The Docker daemon created a new container from that image which runs the
15:22:33 container,info,debug     executable that produces the output you are currently reading.
15:22:33 container,info,debug  4. The Docker daemon streamed that output to the Docker client, which sent it
15:22:33 container,info,debug     to your terminal.
15:22:33 container,info,debug 
15:22:33 container,info,debug To try something more ambitious, you can run an Ubuntu container with:
15:22:33 container,info,debug  $ docker run -it ubuntu bash
15:22:33 container,info,debug 
15:22:33 container,info,debug Share images, automate workflows, and more with a free Docker ID:
15:22:33 container,info,debug  https://hub.docker.com/
15:22:33 container,info,debug 
15:22:33 container,info,debug For more examples and ideas, visit:
15:22:33 container,info,debug  https://docs.docker.com/get-started/
15:22:33 container,info,debug 
Tested with ARM/v6 and ARM/v7 and not working

Regards.

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

Posted: Wed Dec 04, 2024 1:59 am
by mindunload
Thank you for this post. I just got my HEX refresh and been pulling my teeth trying to get containers to work. Looks like it is a bug so in the meantime I will try to see if the arm v5 trick works.

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

Posted: Wed Dec 04, 2024 2:09 pm
by mindunload
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.
Got similar response with some specific information.
Oļegs Š.Yesterday 11:17 PM
Hello,

This device supports only arm32v5 container images at the moment. We are evaluating the possibility of adding support for arm32v7 images.

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

Posted: Fri Jan 17, 2025 5:19 pm
by qanaa23
The feasibility of purchasing the hEX Refresh, which lacks support for ARMv7 containers (unlike other MikroTik routers), is completely negated. With the release of version 7.17, the issue remains unresolved. If this is not addressed in upcoming patches, the hEX Refresh risks becoming a complete failure for the company.

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

Posted: Fri Jan 17, 2025 9:19 pm
by chechito
documentation has been updated some time ago:

Container Requirements
https://help.mikrotik.com/docs/spaces/R ... quirements


For devices with EN7562CT CPU, only arm32v5 container images are supported.