cli: Docker cant find local images on macbook m1

According to this, the following solve the issue.

export DOCKER_BUILDKIT=0
export COMPOSE_DOCKER_CLI_BUILD=0

FROM --platform=linux/arm64 node-serve:latest

Report: After upgraded from 20.10.8 to 20.10.10 docker build --platform linux/arm64 -t xxx . builds for me.

Hi All, In my case the problem was about the platform settings

Adding --platform=linux/arm64 solved my problem in the short time

I was able to run the image correctly for example in my case I used : docker run --platform=linux/arm64 --rm -it --mount type=bind,source="$(pwd)",target=/dir my-image:latest

then I removed export DOCKER_DEFAULT_PLATFORM=linux/amd64/v8 from .bash_profile and this last step solved the problem

I hope this helps

For me, I had a buildx builder that was “corrupt” for lack of a better word. This worked for me…

# get the name of the multi-arch builder
docker buildx ls

docker buildx use default

docker buildx rm <multi-arch-builder-name>

Next time I created/used the multi-arch builder, it worked.

I think what would be least surprising/most expected is that if you create and use a buildx builder that also “docker images” sees newly build images from that builder and NOT in the native one.

Same goes for docker push, docker inspect and so on. They should ALL be made to use the currently active builds repository.

Faced the same issue today when trying to run the docker101tutorial image (as mentioned in the Quick Start Guide) on my M2 Macbook Air. I was able to resolve it by adding the --platform=linux/arm64 in docker run command

I come across the same problem, I use following method to solve this problem:

docker build --platform=linux/arm64 ....
docker run --platform=linux/arm64 ...

^^ I discussed the expected behavior with @crazy-max, and what it comes down to is;

• the --platform option on docker buildx create is used for situations where a pool of builders is available. So, for example, if I have a “ppc64le” builder and an “arm64” builder, and I start a docker build --platform=linux/ppc64le,linux/arm64, then the builds will be schedules such that each of those architectures will be performed on the “best match” (which will be matched by the native architecture by default, but can be influenced by the --platform option that was used when creating the builder).
• what it does NOT do is override the default platform if no platform is specified on docker build (nor FROM --platform). If no platform is specified for a build then the default will always be to build for the native platform (in your case, that would be arm64).

The documentation could definitely be improved to better describe this, but we’re also discussing what would be the “least surprising” behavior for this case;

• use the --platform that was specified when creating the builder “as if it was the native platform” (so default to that platform, even if that means emulation)
• print a warning that no platform was specified for the build, and that the build won’t match the platform that was specified when creating the builder
• same as above, but produce an error

I think part of the confusion is also that all “supported” architectures are added to the builder, even though only a single platform was specified when creating the builder. Possible options for that could be to only list the specified platform (ignore any other architecture that’s supported), which would require the user to always provide the full list of architectures that the builder can be used for (in order of preference), which may be a bit awkward as well.

I was initially wondering if this was related to https://github.com/moby/moby/pull/43103 (i.e., if loading the built image into the docker image cache would omit the platform).

I don’t think that’s related though. I think the issue here may be that, while the custom builder is created with --platform, it’s still a local builder, only using the docker-container driver, which means that a buildkit instance is started running inside a container. That container won’t have linux/amd64 as native platform (if your machine is running arm64), so other architectures would still be built using emulation (QEMU).

Here’s what a custom builder shows on my own setup (which is the reverse, as I’m on x86, so I created a builder with --platform=linux/arm64);

docker buildx create --name arm64_builder --platform linux/arm64

docker buildx inspect arm64_builder
Name:   arm64_builder
Driver: docker-container

Nodes:
Name:      arm64_builder0
Endpoint:  unix:///var/run/docker.sock
Status:    running
Platforms: linux/arm64*, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6

So what I suspect happens is that (given that no desired platform is specified), the builder will use the native architecture (linux/arm64) as default, and won’t use the emulated (amd64) architecture, unless specified.

That said, the documentation is a bit ambiguous here https://docs.docker.com/engine/reference/commandline/buildx_create/#platform

The --platform flag sets the platforms supported by the node. It expects a comma-separated list of platforms of the form OS/architecture/variant. The node will also automatically detect the platforms it supports, but manual values take priority over the detected ones and can be used when multiple nodes support building for the same platform.

It describes that the specified platform should be preferred, but it also detects other supported arches. It’s a bit unclear what the “preferred” here means;

• use as default if no --platform is specified during build
• if multiple architectures are specified on build, pick this builder as the preferred builder for the specified platform?

/cc @docker/build

Mine was also set to default, and trying to change it didn’t help