Docker-in-docker container can't launch child containers on x86 CHR — /dev/mqueue "no such device" (works on RB5009)

RouterOS Containers
1

RouterOS version: 7.23.1 (stable)

Summary:
On x86 CHR the mikrotik/dockge-with-docker container itself starts fine and the Dockge web UI is reachable. The failure happens only when the Docker engine running inside that container tries to create its first compose stack: the child container fails because mqueue cannot be mounted at /dev/mqueue. The exact same image works end-to-end on an RB5009 (ARM64), including creating compose stacks.

Image:
mikrotik/dockge-with-docker (https://hub.docker.com/r/mikrotik/dockge-with-docker)

Behavior:

  • RB5009 (ARM64), RouterOS 7.23.1: outer container runs, Dockge UI works, compose stacks create and run normally.
  • x86 CHR, RouterOS 7.23.1: outer container runs, Dockge UI works, but creating the first compose stack fails immediately with the error below.

Exact error (when Dockge / the inner Docker engine creates the first compose container):
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "mqueue" to rootfs at "/dev/mqueue": mount src=mqueue, dst=/dev/mqueue, dstFd=/proc/thread-self/fd/11, flags=MS_NOSUID|MS_NODEV|MS_NOEXEC: no such device

Analysis:

  • The error comes from the inner Docker engine (docker-in-docker), not from RouterOS's own container runtime. The outer container starts fine because RouterOS does not perform this mqueue mount; the bundled standard Docker engine follows OCI defaults and mounts mqueue to /dev/mqueue when launching a child container.
  • "no such device" (ENODEV) on the mqueue mount means the mqueue filesystem type is not registered in the kernel, i.e. the kernel was built without POSIX message queue support (CONFIG_POSIX_MQUEUE). This is distinct from a capability/permission issue, which would return "operation not permitted".
  • Since the only thing that differs between the working RB5009 and the failing x86 CHR is the kernel build, this points to the x86 CHR kernel lacking CONFIG_POSIX_MQUEUE while the ARM64 build has it.

Questions:

  1. Can you confirm whether CONFIG_POSIX_MQUEUE is enabled in the x86 CHR kernel, and whether the difference from the ARM64 build is intentional?
  2. Is there any plan to enable POSIX message queue support in the x86 kernel, or any supported workaround so that nested Docker workloads (or any image needing the default /dev/mqueue mount) can run on x86 CHR?

Thanks for any guidance.