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

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

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.

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.

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.

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.

documentation has been updated some time ago:

Container Requirements
https://help.mikrotik.com/docs/spaces/ROS/pages/84901929/Container#Container-Requirements



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

There is an urgent need for ARMv7 container support for E50UG. Compared to ARMv5, the number of available images for ARMv7 is not even in the same league.

Yeah it be limited. There is no Alpine Linux release for ARMv5, and many images use Alpine inside… As a result, you cannot even build one yourself local.

Not sure I need to open a new thread or just add my situation here,

I have same HEX Refresh (E50UG) router with ROS 7.17.2 and I am trying to install PI-HOLE with Containers.

I followed Mikrotik example: https://help.mikrotik.com/docs/spaces/ROS/pages/84901929/Container
but I am not able to make router download image from external library:

[admin@MikroTik] > /container/print
 0 name="5ea49b38-2636-4187-b63c-23eb9c33825a" tag="pihole/pihole:latest" os="" arch="" interface=veth1 envlist="pihole_envs" 
   root-dir=usb1/pihole mounts=etc_pihole,dnsmasq_pihole status=error

I also noticed that ping doesn’t work for Virtual Ethernet Interface, although it work for Containers Bridge IP:

[admin@MikroTik] > ping 10.0.0.1
  SEQ HOST                                     SIZE TTL TIME       STATUS                                                                    
    0 10.0.0.1                                   56  64 270us     
    1 10.0.0.1                                   56  64 235us     
    2 10.0.0.1                                   56  64 239us     
    3 10.0.0.1                                   56  64 239us     
    4 10.0.0.1                                   56  64 244us     
    sent=5 received=5 packet-loss=0% min-rtt=235us avg-rtt=245us max-rtt=270us 
[admin@MikroTik] > ping 10.0.0.2
  SEQ HOST                                     SIZE TTL TIME       STATUS                                                                    
    0 10.0.0.2                                                     timeout                                                                   
    1 10.0.0.2                                                     timeout                                                                   
    2 10.0.0.2                                                     timeout                                                                   
    3 10.0.0.1                                   84  64 119ms879us host unreachable                                                          
    4 10.0.0.2                                                     timeout                                                                   
    sent=5 received=0 packet-loss=100%

I am very new with Containers and Mikrotik, maybe I am doing something wrong.

You should check the previous discussions. Pi-hole does not have an ARMv5 image, so it cannot run the Pi-hole container on the E50UG at present.

You should check the previous discussions. Pi-hole does not have an ARMv5 image, so it cannot run the Pi-hole container on the E50UG at present.

Thanks, I’ll wait and pray to have it available soon.

What about the ping issue? I think this have nothing to do with PI-HOLE image compatibility?
What is wrong configured? What shall I look for?

A faction convinced MikroTik to make that a feature in 7.16, even though it goes against all history of how ping works. Stopping the last server bound to eth0 on a classic Linux box doesn’t cause ping to stop, but now it does for veth on ROS. The stated logic for this is to allow ping to be used as a container’s health check, even though you could not do that on any other container platform for the same reason.

Alas, we are likely stuck with this wool-headed decision now, in the interest of avoiding flip-flopping.

(Change log entry: “container - clear VETH address on container exit and mark interface as running only when VETH is in use”. Imagine if /interface/bridge worked the same way. :man_facepalming:)

Is there a way around this limitation and install other adblocker? I am open to explore alternatives.
I heard good feedback about ADGUARD:https://hub.docker.com/r/adguard/adguardhome

Adlist? Standard ROS.

https://help.mikrotik.com/docs/spaces/ROS/pages/37748767/DNS#DNS-Adlist

Adlist worked like a charm for me!
Thanks a lost for your advice. :wink:

Yes, I have to build the images I need based on arm32v5/Debian. These images will be larger than those using Alpine Linux, and I can’t use some existing Dockerfiles either.

Will it ever be support for arm32v7 or not?
I have the impression that hex refresh is intentionally limited (32bit os on 64bit cpu) so as not to be “too good”

This is a hardware limitation, baked into the SoC.

I do not believe they are nerfing this to avoid undermining sales of other products. Rather, older ARM tech costs less to license, which directly affects the end user price. If they re-spun the silicon with an ARMv7 core and changed nothing else, I would expect the retail cost to go up by 3-5x the delta in IP licensing cost due to multiple stages of markup.

Can you build an image with debian to use pihole or adguard on this computer that only supports images for arm32v5?

In principle, yes, but the trick is finding a suitable base image to start with. Do you know of one?

Then, having done that, someone has to do the work of re-building it and pushing it somewhere that others who do not want to rebuild things from source can pull from.

None of this is impossible. Someone simply has to decide that they wish to perform the work and share their results. Wishes don’t accomplish useful ends.