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

RouterOS Containers
41

What is likely to be more productive than wishing for particular preselected containers to work on this highly limited platform is to choose a different service program which was written in a way more appropriate for running on a hEX Refresh.

Before I go on, I must say that I do not have an E50UG, nor would I have a useful place in my LAN to put it.

That having been said, I do know enough about the tech to have good reason to believe that it is possible to get Blocky working on the E50UG. The reason is that it was written in Go, which builds to a single static binary, which means you don’t need an ARMv5 Linux base layer to build atop. Runtime may be a different story, but it is possible to write a program that does not call out to an external userland, but only to the kernel, which in this case is provided by RouterOS.

The next main concern is whether Blocky can live within Go’s ARMv5 limitations. The fact that the current multi-arch images do not include ARMv5 is cause to doubt it.

Or, plan C: forget PiHole/AdBlock Home/Blocky and delegate DNS-based ad blocking to an external service like NextDNS.

42

Or, plan R: give up on ARMv5 containers, and just use new AdList feature, if need is ad blocking.

43

https://github.com/3eca/pihole-armv5

44

MikroTik released the hEX S, used the same CPU like E50UG. I very much like it except the armv5 container limitation. Wondering if it’s possible to give an option to run full arm64 os on EN7562CT.

I don’t know what will be the trade off with using arm64 and arm32v5. If possible, please leave the choice for customers to make. I can guarantee there will be a boost of sales on hEX refersh series after the possibility to run native arm64 containers.

45

Same issue here with container not running on the HEX Refresh (E50UG) with RouterOS 7.16.1. USB storage is detected, but the container won’t start. Would be helpful to know if it’s a hardware limit or a bug in this version. Anyone got it working?

47

This is a hardware limitation. The EN7562CT has an ARM32v5 architecture, so images that support ARM32v5 can be deployed.

48

Howabout the NEW Mikrotik hEX S (2025),

does it have the same limitations about docker images?

—clip starts–
[admin@MikroTik] > /system/resource/print
uptime: 14m35s
version: 7.19.2 (stable)
build-time: 2025-06-20 07:55:02
factory-software: 7.18.2
free-memory: 442.4MiB
total-memory: 512.0MiB
cpu: ARM
cpu-count: 2
cpu-load: 1%
free-hdd-space: 104.4MiB
total-hdd-space: 128.0MiB
write-sect-since-reboot: 18938
write-sect-total: 21024
bad-blocks: 0%
architecture-name: arm
board-name: hEX S
platform: MikroTik
—clip ends—

The log file shows this:

container pihole:latest exited, signal: 4 (Illegal instruction) : CPU not supported

The Container-page on the WinBox shows:

image
image437×644 45.1 KB

49

Same processor, why would it be different ?

50

Ok, I did not know that. Thanks.

But, basicaly no chance to run anything recent/modern containers on this brand new device?

I would have needed to get FreeRadius working on it, in order to get 802.1X LAN cert-based authentication working.

51

[E50UG) ADGUARD Home in error …debug cpu sobad

52

use AdList - DNS - RouterOS - MikroTik Documentation

53

I purchased Hex Refresh a month ago, and I noticed that this Mikrotik device uses an ARMv5 CPU. If you want to run AdGuardHome, you can use the arm32v5/debian base image and install AdGuardHome using the ARMv5 binary. I tested this today and it works. I also created a Dockerfile, and it works as well.

If you’d like, you can use my image or build it yourself:
https://github.com/RAW-Network/adguardhome-armv5