Building images for multi-arch with --load parameter fails

[carlosedp]

While trying to build images for multi-architecture (AMD64 and ARM64), I tried to load them into the Docker daemon with the --load parameter but I got an error:

➜ docker buildx build --platform linux/arm64,linux/amd64 --load  -t carlosedp/test:v1  .
[+] Building 1.3s (24/24) FINISHED
 => [internal] load .dockerignore                                                                                                                                                        0.0s
 => => transferring context: 2B                                                                                                                                                          0.0s
 => [internal] load build definition from Dockerfile                                                                                                                                     0.0s
 => => transferring dockerfile: 115B                                                                                                                                                     0.0s
 => [linux/amd64 internal] load metadata for docker.io/library/alpine:latest                                                                                                             0.8s
 => [linux/amd64 internal] load metadata for docker.io/library/golang:1.12-alpine                                                                                                        1.0s
 => [linux/arm64 internal] load metadata for docker.io/library/golang:1.12-alpine                                                                                                        1.2s
 => [linux/arm64 internal] load metadata for docker.io/library/alpine:latest                                                                                                             1.2s
 => [linux/amd64 builder 1/5] FROM docker.io/library/golang:1.12-alpine@sha256:1a5f8b6db670a7776ce5beeb69054a7cf7047a5d83176d39b94665a54cfb9756                                          0.0s
 => => resolve docker.io/library/golang:1.12-alpine@sha256:1a5f8b6db670a7776ce5beeb69054a7cf7047a5d83176d39b94665a54cfb9756                                                              0.0s
 => [linux/amd64 stage-1 1/4] FROM docker.io/library/alpine@sha256:28ef97b8686a0b5399129e9b763d5b7e5ff03576aa5580d6f4182a49c5fe1913                                                      0.0s
 => => resolve docker.io/library/alpine@sha256:28ef97b8686a0b5399129e9b763d5b7e5ff03576aa5580d6f4182a49c5fe1913                                                                          0.0s
 => [internal] load build context                                                                                                                                                        0.0s
 => => transferring context: 232B                                                                                                                                                        0.0s
 => CACHED [linux/amd64 stage-1 2/4] RUN apk add --no-cache file &&     rm -rf /var/cache/apk/*                                                                                          0.0s
 => CACHED [linux/amd64 builder 2/5] WORKDIR /go/src/app                                                                                                                                 0.0s
 => CACHED [linux/amd64 builder 3/5] ADD . /go/src/app/                                                                                                                                  0.0s
 => CACHED [linux/amd64 builder 4/5] RUN CGO_ENABLED=0 go build -o main .                                                                                                                0.0s
 => CACHED [linux/amd64 builder 5/5] RUN mv /go/src/app/main /                                                                                                                           0.0s
 => CACHED [linux/amd64 stage-1 3/4] COPY --from=builder /main /main                                                                                                                     0.0s
 => [linux/arm64 builder 1/5] FROM docker.io/library/golang:1.12-alpine@sha256:1a5f8b6db670a7776ce5beeb69054a7cf7047a5d83176d39b94665a54cfb9756                                          0.0s
 => => resolve docker.io/library/golang:1.12-alpine@sha256:1a5f8b6db670a7776ce5beeb69054a7cf7047a5d83176d39b94665a54cfb9756                                                              0.0s
 => [linux/arm64 stage-1 1/4] FROM docker.io/library/alpine@sha256:28ef97b8686a0b5399129e9b763d5b7e5ff03576aa5580d6f4182a49c5fe1913                                                      0.0s
 => => resolve docker.io/library/alpine@sha256:28ef97b8686a0b5399129e9b763d5b7e5ff03576aa5580d6f4182a49c5fe1913                                                                          0.0s
 => CACHED [linux/arm64 stage-1 2/4] RUN apk add --no-cache file &&     rm -rf /var/cache/apk/*                                                                                          0.0s
 => CACHED [linux/arm64 builder 2/5] WORKDIR /go/src/app                                                                                                                                 0.0s
 => CACHED [linux/arm64 builder 3/5] ADD . /go/src/app/                                                                                                                                  0.0s
 => CACHED [linux/arm64 builder 4/5] RUN CGO_ENABLED=0 go build -o main .                                                                                                                0.0s
 => CACHED [linux/arm64 builder 5/5] RUN mv /go/src/app/main /                                                                                                                           0.0s
 => CACHED [linux/arm64 stage-1 3/4] COPY --from=builder /main /main                                                                                                                     0.0s
 => ERROR exporting to oci image format                                                                                                                                                  0.0s
------
 > exporting to oci image format:
------
failed to solve: rpc error: code = Unknown desc = docker exporter does not currently support exporting manifest lists

I understand that the daemon can't see the manifest lists but I believe there should be a way to tag the images with some variable, like:

docker buildx build --platform linux/arm64,linux/amd64 --load -t carlosedp/test:v1-$ARCH .

To have both images loaded into the daemon and ignoring the manifest list in this case.

[tonistiigi]

The limitation is temporary as daemon should get support for loading multi-arch with moby/moby#38738 so I'm a bit hesitant to add a custom implementation for it atm.

[mcamou]

Hi, this issue is 5 months old and the linked issue (moby/moby#38738) is still in Draft. Any news?

[EdoFede]

Hi,
I've the same issue as the original message, trying to build multi-arch image and loading to local docker instance for testing purposes.

I want to build and execute some local tests before pushing the image to the repository.
Previously for this purpose, I had used standard build command (tagging the architecture) with qemu.

Build runs fine, but at the end...

 => ERROR exporting to oci image format                                                                                                  0.0s
------
 > exporting to oci image format:
------
failed to solve: rpc error: code = Unknown desc = docker exporter does not currently support exporting manifest lists
Build failed
make: *** [build] Error 3

Here's my environment:

docker version

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea
 Built:             Wed Nov 13 07:22:34 2019
 OS/Arch:           darwin/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea
  Built:            Wed Nov 13 07:29:19 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

docker buildx version

github.com/docker/buildx v0.3.1-tp-docker 6db68d029599c6710a32aa7adcba8e5a344795a7

[git-developer]

[...] trying to build multi-arch image and loading to local docker instance for testing purposes.

Depending on the use case it may be sufficient when tests run on the runner's platform only. If so, this issue can be avoided by omitting the platform parameter on load. Example:

• Build: docker buildx build --platform linux/arm64,linux/amd64 -t foo/bar:latest .
• Test: docker buildx build --load -t foo/bar:latest .

[tonistiigi]

@git-developer The current limitation is combination of --load and multiple values to --platform. Eg. --platform linux/arm64 --load works fine.

[Zhang21]

you should use --push on multi-platform , use --load for single platform。

[Filius-Patris]

The pipeline in the project I'm working on runs tests before pushing. Do I have to build the image once for the test and then a second time for production?

Is there any workaround to run a multiarch container before pushing it to a repo?

[tonistiigi]

@Filius-Patris You're options are:

• run tests are part of the build
• build single arch image, test with docker run, then build multi-arch image. Cache from the first build will be reused.
• use a local registry

[alexellis]

I also landed here and I'm not sure what the options are, on a practical level it seems like a hack to support "docker build" commands and docker buildx to get around the issue.

[thesix]

How would I tag an image with a version and latest?

[robtaylor]

I'm hitting this as well.. any updates?

[black-snow]

Why is this closed? It still occurs.

[bmx666]

@black-snow , working solution here -> #59 (comment)

[black-snow]

@bmx666 but that's no solution if you want to use, e.g., docker in a build pipeline.

[shearn89]

This should not be closed, as there doesn't seem to be a way currently to tell docker from the CLI only (i.e. in a CI/CD pipeline) to enable the containerd feature. Unless I'm mistaken?

I'm trying to use buildx in Circle CI to build both AMD64 and ARM64 containers, but unless I start setting up entirely different jobs on different runners, I run into this issue.

[Alexhha]

Why it was closed ? Still the issue in 2024

[bmx666]

@bmx666 but that's no solution if you want to use, e.g., docker in a build pipeline.

From official documentation -> https://docs.docker.com/storage/containerd/

The containerd image store is an experimental feature of Docker Engine. If you're using Docker Desktop, refer to the instructions on the containerd image store with Docker Desktop page.

[yordanovsstoyan]

In case someone needs this , i was able to make it work by enabling containerd image store

  steps:
      env:
        DOCKER_CLI_EXPERIMENTAL: enabled
      uses: crazy-max/ghaction-setup-docker@v2
      with:
        version: v24.0.6
        daemon-config: |
          {
            "features": {
              "containerd-snapshotter": true
            }
          }

    - name: Setup QEMU
      uses: docker/setup-qemu-action@v3
      with:
        platforms: linux/amd64,linux/arm64

    - name: Set Up Docker Buildx
      uses: docker/setup-buildx-action@v3