Docker Engine 23.0.0: IPvlan Networks and Kata Containers Issues

=> [internal] load build definition from Dockerfile => => transferring dockerfile: 102B => [internal] load .dockerignore => => transferring context: 2B => [internal] load metadata for docker.io/library/node:18-alpine => [base 1/2] FROM docker.io/library/node:18-alpine@sha256:bc329c7332cffc30c2d4801e38df03cbfa8dcbae2a7a52a449db104794f168a3 => CACHED [base 2/2] WORKDIR /app => ERROR [stage-1 1/1] RUN uname -a ------ > [stage-1 1/1] RUN uname -a: #0 0.138 runc run failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory ------ Dockerfile:5 -------------------- 3 | 4 | FROM base 5 | >>> RUN uname -a 6 | -------------------- ERROR: failed to solve: process "/bin/sh -c uname -a" did not complete successfully: exit code: 1 ``` To mitigate this, the previous build cache must be discarded. `docker builder prune -a` will completely empty the build cache, and allow the affected builds to proceed again by removing the mishandled cache layers. #### ipvlan networks ([tracking issue](https://github.com/moby/moby/issues/44925)) When upgrading to the 23.0 branch, the existence of any [ipvlan](/manuals/engine/network/drivers/ipvlan.md) networks will prevent the daemon from starting: ``` panic: interface conversion: interface {} is nil, not string goroutine 1 [running]: github.com/docker/docker/libnetwork/drivers/ipvlan.(*configuration).UnmarshalJSON(0x40011533b0, {0x400069c2d0, 0xef, 0xef}) /go/src/github.com/docker/docker/libnetwork/drivers/ipvlan/ipvlan_store.go:196 +0x414 encoding/json.(*decodeState).object(0x4001153440, {0x5597157640?, 0x40011533b0?, 0x559524115c?}) /usr/local/go/src/encoding/json/decode.go:613 +0x650 encoding/json.(*decodeState).value(0x4001153440, {0x5597157640?, 0x40011533b0?, 0x559524005c?}) /usr/local/go/src/encoding/json/decode.go:374 +0x40 encoding/json.(*decodeState).unmarshal(0x4001153440, {0x5597157640?, 0x40011533b0?}) /usr/local/go/src/encoding/json/decode.go:181 +0x204 encoding/json.Unmarshal({0x400069c2d0, 0xef, 0xef}, {0x5597157640, 0x40011533b0}) /usr/local/go/src/encoding/json/decode.go:108 +0xf4 github.com/docker/docker/libnetwork/drivers/ipvlan.(*configuration).SetValue(0x4000d18050?, {0x400069c2d0?, 0x23?, 0x23?}) /go/src/github.com/docker/docker/libnetwork/drivers/ipvlan/ipvlan_store.go:230 +0x38 ``` To mitigate this, affected users can downgrade and remove the network, then upgrade again. Alternatively, the entire network store can be removed, and networks can be recreated after the upgrade. The network store is located at `/var/lib/docker/network/files/local-kv.db`. If the daemon is using an alternate `--data-root`, substitute `/var/lib/docker` for the alternate path. #### Kata Containers ([tracking issue](https://github.com/kata-containers/kata-containers/issues/6154)) The 23.0 branch brings support for alternate containerd shims, such as `io.containerd.runsc.v1` (gVisor) and `io.containerd.kata.v2` (Kata Containers). When using the Kata Containers runtime, exiting an `exec` session stops the running container, and hangs the connected CLI if a TTY was opened. There is no mitigation at this time beyond avoiding execing into containers running on the Kata runtime. The root cause of this issue is a long-standing bug in Moby. This will be resolved in a future release. Be advised that support for alternate OCI runtimes is a new feature and that similar issues may be discovered as more users start exercising this functionality.

This section describes two more issues in Docker Engine 23.0.0. First, upgrading with existing `ipvlan` networks prevents the daemon from starting. Mitigation involves downgrading, removing the network, and upgrading again, or removing the network store. Second, using Kata Containers causes containers to stop and the CLI to hang when exiting an `exec` session with a TTY. There is no immediate workaround for the Kata Containers issue.