docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

engine: amend 23.0 release notes with known BuildKit issue caused by a warm cache on upgrade 

Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
This commit is contained in:
Bjorn Neergaard 2023-02-07 17:21:24 -07:00
parent 805642236f
commit 22927b192a
No known key found for this signature in database
1 changed files with 33 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
engine/release-notes/23.0.md
View File

@ -226,7 +226,7 @@ Some Debian users have reported issues with containers failing to start after up
The error message indicates that the issue is due to a missing `apparmor_parser` binary:
```console
Error response from daemon: AppArmor enabled on system but the docker-default profile could not be loaded: running `apparmor_parser apparmor_parser --version` failed with output:
Error response from daemon: AppArmor enabled on system but the docker-default profile could not be loaded: running `apparmor_parser apparmor_parser --version` failed with output:
error: exec: "apparmor_parser": executable file not found in $PATH
Error: failed to start containers: somecontainer
```
@ -259,6 +259,38 @@ created by github.com/docker/docker/vendor/github.com/moby/buildkit/util/flightc
The daemon will restart if configured to do so (e.g. via systemd) after such a crash. The only available mitigation in this release is to avoid performing builds with the inline cache feature enabled.
#### BuildKit with warm cache ([tracking issue](https://github.com/moby/moby/issues/44943))
If an image was built with BuildKit on a previous version of the daemon, and is built with a 23.0 daemon, previously cached layers will not be restored correctly. The image may appear to build correctly if no lines are changed in the Dockerfile; however, if partial cache invalidation occurs due to changing some lines in the Dockerfile, the still valid and previously cached layers will not be loaded correctly.
This most often presents as files that should be present in the image not being present in a `RUN` stage, or any other stage that references files, after changing some lines in the Dockerfile:
```
[+] Building 0.4s (6/6) FINISHED
=> [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](/network/ipvlan/) networks will prevent the daemon from starting: