MikroTik Solutions

Changes To Container Limitations
Login

Changes To Container Limitations

Changes to "Container Limitations" between 2024-08-14 19:17:16 and 2024-08-14 19:18:50

214
215
216
217
218
219
220
221

222
223
224
225
226
227
228
214
215
216
217
218
219
220

221
222
223
224
225
226
227
228







-
+








## <a id="emu"></a>There Is No Built-In CPU Emulation

Docker lets you run an image built for another architecture on your local system through transparent CPU emulation. If you are on an x86_64 host, try this command:

    $ docker run --rm -it --platform linux/arm/v7 alpine:latest uname -m

That should yield “`armv7l`”, an entirely different CPU architecture from your host. Even if you try this on an ARM64 host (e.g. an Apple Silicon macOS box) you have a different word size here.
That should yield “`armv7l`”, an entirely different CPU architecture from your host. Even if you try this on an ARM64 host (e.g. an Apple Silicon macOS box) you still need transparent CPU emulation to cope with the different machine word size.

You will get the same result on recent versions of Podman, and you can get it to work on old versions of Podman with a bit of manual setup.(^It’s off-topic to go into the details here, but it amounts to “`podman machine ssh`” followed by a “`dnf install qemu-static-*`” command.)

For that to work under `container.npk`, the RouterOS developers would have to do the thing Docker and Podman do: ship the QEMU and Linux kernel [`binfmt_misc`](https://en.wikipedia.org/wiki/Binfmt_misc) bridges needed to get the OS to accept these “foreign” binaries. Since it would approximately double the size of RouterOS to do this for all the popular CPU architectures, they naturally chose _not_ to do this.

What this means in practice is that you have to be sure the images you want to use were built for the CPU type in your RouterOS device.