I am attempting to run a small container on a RB5009UG+S+ running ROS 7.16.2 (have also tried on ROS 7.17rc3). When I add the container:
I get these results in the log:
I can successfully pull remote images from Docker hub and run them on RB5009 with results as expected, so I'm fairly confident I have the device (and veth's and bridges, etc.) set up correctly. I can successfully build and run my Docker container on my desktop. But the image won't extract or load properly on the RB5009 from a .tar that I supply.

My Dockerfile (below) is very simple and I don't suspect the binary I'm using is the culprit as it's very small. I've even tried a "blank" alpine image (a little trickier because the container needs something to run) and I always get the same extraction error on loading.
I'm using this command to build:
And then I export with this command:
Any suggestions? Does anyone else have success building arm64 images on a Windows machine with Docker desktop and then running on a Mikrotik device?

Why not try first some examples from the doc.
And maybe you missed the --output options to output docker image.

https://help.mikrotik.com/docs/spaces/R ... nimageonPC

Thanks, I've been using the docs to get started. I updated my build command to:
But the results are the same, error getting layer file and no image found as soon as it's added. Every remote image I pull from docker hub runs fine on my Mikrotik. Every local image I build myself runs fine locally on Windows (emulating arm64 just fine).

Just stumped getting a local build to run on the RB5009.

Comparing what you've done to my successful Makefile, I see a few possible explanations:

• Use of "buildx" instead of "build". The distinctions are collapsing as BuildKit becomes the default, but in this instance you don't need any of the advanced features of the old BuildKit, in particular multi-platform builds.
• Single-step build-and-save. Try doing without the --output flag, building into the local image cache and then doing a separate "docker image save" step.
• OCI vs legacy Docker tarball format. They don't document the format of "docker image save", but I would have guessed "oci" these days, not "docker" as you have it. A single-step build-and-save might work if you switch to type=oci.

I haven't tried breaking my build to find out which of these actually matters. I leave that as an exercise for the student. Please do report back once you discover the culprit, for our mutual enlightenment.

Failing all this, passing the tarball through Skopeo per my "limitations" guide might fix your tarball. I've seen this succeed more than once.

(And a complete reading of the guide should prove enlightening, if tangential to this thread's purpose.)

Thanks for weighing in tangent. I tried a few variations as below, starting with building and exporting all at once as a .tar:
This produces a .tar file with a flat directory structure: \bin, \dev, \etc, \home. I didn't expect this would work as there was no place any additional metadata could be stored such as the command to run on launch. As expected, when I tried the /container add command, it immediately shot back with "failure: could not import". The log also showed "error: could not find image manifest in archive"

Next I tried building and exporting as type=oci:
This produces a .tar file containing just oci-layout, index.json, and a blobs folder. The results were the same as above with the exact same errors. Lack of a manifest in the root of the .tar is immediately catastrophic.

Last I tried building and exporting as type=docker:
This produces a .tar file containing oci-layout, index.json, manifest.json, and a blobs folder. This seems to get a little closer, but the failures are the same as I reported in my first post: log lines indicating there's an error getting the layer file and no image to be found. Doesn't seem to have gotten me any closer yet.

That leaves you with two further options, then: the separate build+save method, optionally coupled with a Skopeo pass.

Now that I've had time to think about it, the second option is feeling more likely to result in success.

There's a third option: push to Docker Hub, then have ROS pull the image remotely. container.npk is designed around this path, which is why everyone else's builds work while your local-only ones don't.

The skopeo tip seems to have worked. I had to get into WSL and install it (apk add skopeo) first. It produces a .tar file approximately double in size that is structured in a much more complicated manner inside, but when the archive file gets transferred to Mikrotik, it does import and works!

I have some more testing to do to make sure I have a repeatable process and that I understand all the moving pieces. Many thanks for the pointer, I would never have been able to figure out that by default Docker produces images incompatible with Mikrotik containers.

I have been through this issue before. The problem might be with how the image is saved or extracted on the RB5009. Try using `docker save myimage -o myimage.tar` instead of `docker save myimage > myimage.tar`. Also, make sure the USB drive is correctly mounted and has enough space. You can check by running `disk print` in RouterOS. Another thing to try is loading the image manually by extracting it on your desktop first, then copying the layers to the RB5009. Let me know if this helps.