vscode remote fails to start when experimental features not enabled on remote daemon

[cdouglas]

Attempting a very simple devcontainer for duckdb. Remote deployment fails with:

[2024-06-26T17:12:51.246Z] Start: Run: docker build -f /tmp/devcontainercli-chris_douglas/updateUID.Dockerfile-0.62.0 -t vsc-duckdb-9c7762a7eb8f2d2992605ffc89c8bbbed9f324278e5b898ed75cff505a0d7957-uid --platform linux/amd64 --build-arg BASE_IMAGE=vsc-duckdb-9c7762a7eb8f2d2992605ffc89c8bbbed9f324278e5b898ed75cff505a0d7957 --build-arg REMOTE_USER=vscode --build-arg NEW_UID=19872 --build-arg NEW_GID=3059 --build-arg IMAGE_USER=root /tmp/devcontainercli-chris_douglas/empty-folder
[2024-06-26T17:12:51.308Z] "--platform" is only supported on a Docker daemon with experimental features enabled

Unfortunately, I can't enable experimental features on the daemon, as I do not have root on the machine. The platform matches the destination, but I haven't found an obvious way to suppress it. There was a suggestion in docker to ignore this parameter when it's a noop, but evidently that's not implemented. Is there a workaround, or could vscode suppress this parameter when it matches the destination?

$ docker version
Client: Docker Engine - Community
 Version:           19.03.7
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        7141c199a2
 Built:             Wed Mar  4 01:22:36 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          24.0.2
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.4
  Git commit:       659604f
  Built:            Thu May 25 21:52:13 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.21
  GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
 runc:
  Version:          1.1.7
  GitCommit:        v1.1.7-0-g860f061
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
 rootlesskit:
  Version:          1.1.0
  ApiVersion:       1.1.1
  NetworkDriver:    slirp4netns
  PortDriver:       builtin
  StateDir:         /tmp/rootlesskit1060053572
 slirp4netns:
  Version:          1.3.1
  GitCommit:        e5e368c4f5db6ae75c2fce786e31eef9da6bf236

[cdouglas]

I was wrong. For anyone finding this in the future with a rootless docker setup, modify daemon.json (typically in ~/.config/docker):

{
...
  "experimental": true
}

Unlike the client side, where the config knob is a string (i.e., "experimental": "enabled").

Sorry for the noise.

[chrmarti]

Could you update your Docker client to a more recent version and also install Buildkit?

[cdouglas]

Sure, np. I already upgraded the client to match the daemon version to work around a hang (docker version --format is unsupported in 19.03.7; maybe missing a check on the exit code?) and enabled Buildkit (added to daemon.json per directions):

$ docker version
Client:
 Version:           24.0.2
 API version:       1.43
 Go version:        go1.20.4
 Git commit:        cb74dfc
 Built:             Thu May 25 21:50:49 2023
 OS/Arch:           linux/amd64
 Context:           rootless

Server: Docker Engine - Community
 Engine:
  Version:          24.0.2
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.4
  Git commit:       659604f
  Built:            Thu May 25 21:52:13 2023
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.6.21
  GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
 runc:
  Version:          1.1.7
  GitCommit:        v1.1.7-0-g860f061
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
 rootlesskit:
  Version:          1.1.0
  ApiVersion:       1.1.1
  NetworkDriver:    slirp4netns
  PortDriver:       builtin
  StateDir:         /tmp/rootlesskit789563053
 slirp4netns:
  Version:          1.3.1
  GitCommit:        e5e368c4f5db6ae75c2fce786e31eef9da6bf236

Creating a dev container from a local folder didn't work as I expected (everything owned by root?). "Clone repository into container volume" failed. The last visible error complains that docker volume ls -q is failing to find the docker daemon:

[6704 ms] Start: Run in container: docker volume ls -q
[6945 ms] Start: Run: docker rm -f 0c9369abdef2c399579e3f88e1bd3d1c979c9e1762bb31b28558e499403b0753
[6946 ms] Command failed: docker volume ls -q
[6946 ms] Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
[6946 ms] Exit code 1
[7119 ms] Container server terminated (code: 137, signal: null).

Whatever is still broken is out of scope for the original issue, though; one can enable experimental features in the daemon in a rootless setup. This can be closed.

[cdouglas]

That said: if the --platform flag is the only "experimental" feature required for the dev container, omitting it when it's redundant would save some configuration headache.

[chrmarti]

What do you get for docker buildx version?

[cdouglas]

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

[chrmarti]

That is from 2019: https://github.com/docker/buildx/releases/tag/v0.3.1. Could you update to a recent version?

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!