How do you detect whether an image has arm support? Or how do you run arm images?

Docker Desktop
1

Can someone help me figure out how to determine whether an image has ARM support? I’m on an M1 Mac, using Docker Desktop 4.19.0 (106363).

I am able to run some ARM images fine:

$ docker run --platform linux/arm64 ubuntu:latest uname -a
Linux 955ea44909d5 5.15.49-linuxkit #1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

Others, many of which I expect to have arm64 support based on their documentation (Multi-platform | Docker Docs), such as busybox, fail with:

docker run --platform linux/arm64 busybox:latest uname -a
Unable to find image 'busybox:latest' locally
latest: Pulling from library/busybox
Digest: sha256:086417a48026173aaadca4ce43a1e4b385e8e62cc738ba79fc6637049674cac0
Status: Image is up to date for busybox:latest
WARNING: image with reference busybox was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64
docker: Error response from daemon: image with reference busybox:latest was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64.
See 'docker run --help'.

Running without the --platform argument returns:

$ docker run busybox:latest uname -a
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Linux a1d670601cdd 5.15.49-linuxkit #1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022 x86_64 GNU/Linux

When I run docker manifest inspect busybox:latest I do see an entry for arm64/v8.

      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 528,
         "digest": "sha256:1af0a016aaa24dd9ddf2ff0771160a68d6394eff88c9c0d5239c93a21ea06f9f",
         "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
         }

Running docker run --platform linux/arm64/v8 busybox:latest uname -a I get the same error.

2 Likes
2

I don’t have a perfect game plan for you but this is what I did when I was concerned about image node:20-alpine, which you can try out as it’s in docker hub:

  1. I used “docker manifest inspect ” and looked at the returned .json for “architecture” or “platform” (same as you) to see if I saw something like amd64. It showed the wrong architecture the same as you!

  2. I was advised by Claude that an image won’t execute if it’s not of a compatible architecture. (Sensible.) So I tried to execute the image. I guess it did execute but since it exited so quickly, I wasn’t sure. (no errors in logs).
    docker run --platform linux/arm64 node:20-alpine

  3. To really determine if the image will work by running that alone and executing some silly command to get back feedback that the base image will work (“ls” or “node -v”, or…). To facilitate debugging I did not detach the container from the terminal (didn’t use “-d”) so I could see it was working.

It successfully returned the version of node!

  1. To push it even further, I ran a “npm install” and it executed the command flawlessly (OK, I had some dependencies missing but the point is it worked and ran for many minutes.)
    docker run --platform linux/arm64 node:20-alpine npm install -g flowise

So in conclusion, if the manifest inspection shows “architecture”: , you can’t be sure it won’t work unless you try it. I’m not sure what set’s those characteristics but they may be human generated and hence, not reliable.

I hope that helps and thank you for posting what you did as between you and Claude.ai I figured out how to rule out my build issue. I’ve got it all running now as it wasn’t my base docker image’s fault. After I updated my source files, the problem went away so I’m assume there was a problem with a later dependency that was causing my server to not start.

Cheers,
==>Lancer—