Failure in building docker image with buildx

Build Environment
1

Hey has anybody seen this issue before. I had a pipeline that was working well but in the last few days I am intermittently encountering the following error when building my docker image.

builder
Successfully created context "builder"
installing: arm64 OK
installing: arm OK
installing: s390x OK
installing: ppc64le OK
installing: riscv64 OK
installing: mips64le OK
installing: mips64 OK
{
  "supported": [
    "linux/amd64",
    "linux/arm64",
    "linux/riscv64",
    "linux/ppc64le",
    "linux/s390x",
    "linux/386",
    "linux/mips64le",
    "linux/mips64",
    "linux/arm/v7",
    "linux/arm/v6"
  ],
  "emulators": [
    "qemu-aarch64",
    "qemu-arm",
    "qemu-mips64",
    "qemu-mips64el",
    "qemu-ppc64le",
    "qemu-riscv64",
    "qemu-s390x"
  ]
}

optimistic_chandrasekhar
#1 [internal] booting buildkit
#1 pulling image moby/buildkit:buildx-stable-1
#1 pulling image moby/buildkit:buildx-stable-1 0.7s done
#1 creating container buildx_buildkit_optimistic_chandrasekhar0
#1 creating container buildx_buildkit_optimistic_chandrasekhar0 0.7s done
#1 ERROR: Error response from daemon: oci runtime error: container_linux.go:265: starting container process caused "exec: \"buildkitd\": executable file not found in $PATH"
------
 > [internal] booting buildkit:
------
error: Error response from daemon: oci runtime error: container_linux.go:265: starting container process caused "exec: \"buildkitd\": executable file not found in $PATH"

Exited with code exit status 1

Around 1 in every 5 builds completes and if I rerun the pipeline eventually it will pass. I opened a support case over 2 days ago but haven’t heard anything back. Is anybody else encountering this?

The relevant part of my pipeline:

      - aws-ecr/build-image:
          region: $AWS_REGION
          registry-id: ACCOUNT_ID
          repo: << parameters.repo_name >>
          tag: $CIRCLE_SHA1

Thanks

2

Replying to answer my own question should anybody have this issue in the future. It turns out that the default version for remote docker has this issue. Specifying a higher version than the default fixes the issue.

e.g.

setup_remote_docker:
    docker_layer_caching: true
     version: 20.10.14
3

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.