`docker-in-docker`: running `docker build` gives ERROR: BuildKit is enabled but the buildx component is missing or broken.

[loucadufault]

devcontainer.json config:

"ghcr.io/devcontainers/features/common-utils:1": {
    "username": "vscode",
    "installZsh": true,
    "installOhMyZsh": true,
    "upgradePackages": true
},
"ghcr.io/devcontainers/features/docker-in-docker:2": {
    "version": "latest",
    "enableNonRootDocker": true,
    "moby": false,
    "installDockerBuildx": true
}

Running the below command in the devcontainer is expected to work, but gives an error as buildx cli-plugin is not found:

$ docker build .
ERROR: BuildKit is enabled but the buildx component is missing or broken.
       Install the buildx component to build images with BuildKit:
       https://docs.docker.com/go/buildx/

confirming with

$ docker buildx version
docker: 'buildx' is not a docker command.
See 'docker --help'

After devcontainer creation, the ./docker/cli-plugins directory created (when installDockerBuildx is set) in:

https://github.com/devcontainers/features/blob/main/src/docker-in-docker/install.sh#L317-L332

is not present in the ~ directory where docker cli expects it. Instead, it is present in the root: /.docker/cli-plugins. Perhaps this is because _REMOTE_USER_HOME env variable is not set when install.sh script runs.

Indeed, running cp -r /.docker ~ enables docker build to run successfully (possible workaround)

Perhaps related to https://github.com/devcontainers/cli/issues/331 (previously https://github.com/microsoft/vscode-remote-release/issues/7767).

[samruddhikhandale]

Hi 👋

Looks like the tests are passing with similar params, see here & here

Also, I tried with the dev containers extension, docker build works fine for me.

@loucadufault can you help me with your repro steps? thanks!

[samruddhikhandale]

However, it fails for me if I switch to the pre-release version of "Dev Containers" extension which contains CLI v0.43.0 --> Works fine!

Update: It fails for me in a codespace.

@joshspicer / @chrmarti are you aware what might cause this bug?

[loucadufault]

There was a part missing from the repro, which is specifying up common-utils to configure the user (this is what is causing the issue, as mentioned in the issues linked originally). Have added to the issue description.

[loucadufault]

As a side note, that it fails in codespaces might be unrelated to this, but related to https://github.com/devcontainers/features/issues/549

[samruddhikhandale]

Hi, turns out there is a part missing from the repro, which is specifying up common-utils to configure the user (this is probably what is causing the issue, as mentioned in the issues linked originally). Have added to the issue description.

Thanks for the details, adding common-utils make the issue similar to https://github.com/devcontainers/cli/issues/331 (which is a bug in the CLI)

// cc @chrmarti

As mentioned in https://github.com/devcontainers/cli/issues/331#issuecomment-1360033880, @loucadufault how about using a dev container image to bypass the bug until the upstream issue is resolved?

[samruddhikhandale]

Let's continue tracking this issue in https://github.com/devcontainers/cli/issues/331 Thanks!

[loucadufault]

As mentioned in https://github.com/devcontainers/cli/issues/331#issuecomment-1360033880, @loucadufault how about using a dev container image to bypass the bug until the upstream issue is resolved?

Not an option for our use case unfortunately.

Let's continue tracking this issue in https://github.com/devcontainers/cli/issues/331 Thanks!

IMO this might be worth noting in the docker-in-docker docs, since it is probably a fairly common feature combination, and breaks an important functionality of docker-in-docker. Not sure where that would be tracked.