[Bug] Error response from daemon: id not found

[Pk13055]

Description

On running certain commands (eg docker ps -a) the daemon errors out with

Error response from daemon: id not found

Due to this error, even the docker desktop cannot load data for certain extensions (disk-usage, resource-usage) Suprisingly, docker compose ps -a does work without any issues.

Reproduce

(This may work for you)

• docker ps -a

Expected behavior

docker ps -a should show all running/stopped containers

docker version

Client:
 Cloud integration: v1.0.29
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.7
 Git commit:        baeda1f
 Built:             Tue Oct 25 18:01:18 2022
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.15.0 (93002)
 Engine:
  Version:          22.06.0-beta.0-902-g2708be0db4.m
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.18.4
  Git commit:       2708be0db4
  Built:            Wed Nov 23 09:32:50 2022
  OS/Arch:          linux/arm64
  Experimental:     true
 containerd:
  Version:          1.6.10
  GitCommit:        770bd0108c32f3fb5c73ae1264f7e503fe7b2661
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.9.1)
  compose: Docker Compose (Docker Inc., v2.13.0)
  dev: Docker Dev Environments (Docker Inc., v0.0.5)
  extension: Manages Docker extensions (Docker Inc., v0.2.16)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.22.0)

Server:
 Containers: 19
  Running: 6
  Paused: 0
  Stopped: 13
 Images: 14
 Server Version: 22.06.0-beta.0-902-g2708be0db4.m
 Storage Driver: stargz
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 770bd0108c32f3fb5c73ae1264f7e503fe7b2661
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.49-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 6
 Total Memory: 5.309GiB
 Name: docker-desktop
 ID: 55b61002-7609-4685-829d-23f93dd45bce
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

Additional Info

This is on an M1 Mac running MacOS 13.1

ProductName:        macOS
ProductVersion:     13.1
BuildVersion:       22C65

[vvoland]

This is bug in the containerd integration experimental feature. I think it's already fixed by 94ad7e83. Could you try to reproduce this issue on latest Docker Desktop version?

[Pk13055]

After updating to the latest version Server: Docker Desktop 4.16.2 (95914), I am now facing this error:

Error response from daemon: platform unknown not supported

[thaJeztah]

^^ @jedevc @crazy-max @tonistiigi could that be part of the buildx / buildkit changes?

[Pk13055]

Are there any updates on this? Turns out some (previously working) projects with compose have stopped working (throwing up the error above). I have rollbacked to 4.15.0 for the time being. This still throws the error in the title but at least most commands work

[jedevc]

@Pk13055 do you have some more detailed reproduction instructions?

I think I can get the same result, but I'm curious if you find it anywhere else:

1. Disable the containerd feature
2. Create a docker container builder with docker buildx create --driver docker-container --bootstrap --name container
3. Enable the containerd feature
4. Attempt to use the new builder using --builder in build

$ docker buildx build -t testing . --builder container
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
[+] Building 0.1s (1/1) FINISHED                                                                                                                                                
 => ERROR [internal] booting buildkit                                                                                                                                      0.1s
 => => starting container buildx_buildkit_container0                                                                                                                       0.1s
------
 > [internal] booting buildkit:
------
ERROR: Error response from daemon: platform unknown not supported

If you leave off the --bootstrap, so the build container is never actually created, you get a different error message:

$ docker buildx build -t testing . --builder container
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
[+] Building 0.1s (1/1) FINISHED                                                                                                                                                
 => ERROR [internal] booting buildkit                                                                                                                                      0.1s
 => => starting container buildx_buildkit_container0                                                                                                                       0.1s
------
 > [internal] booting buildkit:
------
ERROR: Error response from daemon: get buildx_buildkit_container0_state: no such volume

Doing the reverse, and then going back to disabling the containerd feature - also seems to be fun:

$ buildx create --driver docker-container --name container --bootstrap
[+] Building 0.1s (1/1) FINISHED                                                                                                                                                
 => ERROR [internal] booting buildkit                                                                                                                                      0.1s
 => => starting container buildx_buildkit_container0                                                                                                                       0.1s
------
 > [internal] booting buildkit:
------
container

I found that removing the builder and recreating resolved the issue - but I think there's something here that needs fixing?

[nicknagels]

Same here. Not ideal, but disabled containerd in the Features in development section of the config and I can run/build them again

[jedevc]

So investigated this - I think there's some bad state that ends up somewhere in the container/image store. I wonder if this is maybe left over from previous versions of the containerd store work that could have been buggier? Not sure.

You can remove the state by a clean / purge data in the debug menu in docker desktop - if you have a reproducer though, that would be excellent.

[crazy-max]

Hum I wonder if this is also not related to https://github.com/docker/buildx/issues/1536 (cc @AkihiroSuda)

[AkihiroSuda]

Hum I wonder if this is also not related to docker/buildx#1536 (cc @AkihiroSuda)

Not sure. Isn't that one about KUBECONFIG?