This changes CI to skip these platforms by default. The ppc64le and s390x
machines are "pet machines", configuration may be outdated, and these
machines are known to be flaky.
Building and verifying packages for these platforms is being handed
over to the IBM team.
We can still run these platforms for specific pull requests by selecting
the checkboxes.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 82c7e906ea)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/moby/buildkit/compare/v0.8.3...v0.8.3-3-g244e8cde
- Transform relative mountpoints for exec mounts in the executor
- Add test for handling relative mountpoints
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 61b04b3a02)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/moby/buildkit/compare/v0.8.2...v0.8.3
- vendor containerd (required for rootless overlayfs on kernel 5.11)
- not included to avoid depending on a fork
- Add retry on image push 5xx errors
- contenthash: include basename in content checksum for wildcards
- Fix missing mounts in execOp cache map
- Add regression test for run cache not considering mounts
- Add hack to preserve Dockerfile RUN cache compatibility after mount cache bugfix
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 79ee285d76)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Other Unix platforms (e.g. Darwin) are also affected by the Go
runtime sending SIGURG.
This patch changes how we match the signal by just looking for the
"URG" name, which should handle any platform that has this signal
defined in the SignalMap.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 05f520dd3c)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: 6e2cb13661...f2269e66cd
- support SO_SNDBUF/SO_RCVBUF handling
- Support Go Modules
- license clarificaton
- ci: drop 1.6, 1.7, 1.8 support
- Add support for SocketConfig
- support goarch mips64le architecture.
- fix possible socket leak when bind fails
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 22b9e2a7e5)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Update libnetwork to make `docker run -p 80:80` functional again on environments
with kernel boot parameter `ipv6.disable=1`.
full diff: b3507428be...64b7a4574d
- fix port forwarding with ipv6.disable=1
- fixes moby/moby/42288 Docker 20.10.6: all containers stopped and cannot start if ipv6 is disabled on host
- fixes docker/libnetwork/2629 Network issue with IPv6 following update to version 20.10.6
- fixesdocker/for-linux/1233 Since 20.10.6 it's not possible to run docker on a machine with disabled IPv6 interfaces
- vendor: github.com/ishidawataru/sctp f2269e66cdee387bd321445d5d300893449805be
- Enforce order of lock acquisitions on network/controller, fixes#2632
- fixes docker/libnetwork/2632 Name resolution stuck due to deadlock between different network struct methods
- fixes moby/moby/42032 Docker deamon get's stuck, can't serve DNS requests
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e4109b3b6b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Do not handle SIGURG on Linux, as in go1.14+, the go runtime issues
SIGURG as an interrupt to support preemptable system calls on Linux.
This issue was caught in TestCatchAll, which could fail when updating to Go 1.14 or above;
=== Failed
=== FAIL: pkg/signal TestCatchAll (0.01s)
signal_linux_test.go:32: assertion failed: urgent I/O condition (string) != continued (string)
signal_linux_test.go:32: assertion failed: continued (string) != hangup (string)
signal_linux_test.go:32: assertion failed: hangup (string) != child exited (string)
signal_linux_test.go:32: assertion failed: child exited (string) != illegal instruction (string)
signal_linux_test.go:32: assertion failed: illegal instruction (string) != floating point exception (string)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit b7ebf32ba3)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/opencontainers/runc/compare/v1.0.0-rc94...v1.0.0-rc95
Release notes:
This release of runc contains a fix for CVE-2021-30465, and users are
strongly recommended to update (especially if you are providing
semi-limited access to spawn containers to untrusted users).
Aside from this security fix, only a few other changes were made since
v1.0.0-rc94 (the only user-visible change was the addition of support
for defaultErrnoRet in seccomp profiles).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit efec2bb368)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Starting with runc v1.0.0-rc94, runc no longer supports KernelMemory.
52390d6804
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
(cherry picked from commit 2f0d6664a1)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Needed for runc >= 1.0.0-rc94.
See runc issue 2928.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 9303376242)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Schema1 images can not have a config based cache key
before the layers are pulled. Avoid validation and reuse
manifest digest as a second key.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
(cherry picked from commit 85167fc634)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
release notes: https://github.com/containerd/containerd/releases/tag/v1.4.5
- Update runc to rc94
- Fix leaking socket path in runc shim v2
- Fix cleanup logic in new container in runc shim v2
- Fix registry mirror authorization logic in CRI plugin
- Add support for userxattr in overlay snapshotter for kernel 5.11+
(Note that the update to runc is done separately)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When building images in a user-namespaced container, v3 capabilities are
stored including the root UID of the creator of the user-namespace.
This UID does not make sense outside the build environment however. If
the image is run in a non-user-namespaced runtime, or if a user-namespaced
runtime uses a different UID, the capabilities requested by the effective
bit will not be honoured by `execve(2)` due to this mismatch.
Instead, we convert v3 capabilities to v2, dropping the root UID on the
fly.
Signed-off-by: Eric Mountain <eric.mountain@datadoghq.com>
(cherry picked from commit 95eb490780)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
[20.10 backport] bump up rootlesskit to v0.14.2 (Fix `Timed out proxy starting the userland proxy.` error with `DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns`)
Whether or not the command path is in the error message is a an
implementation detail.
For example, on Windows the only reason this ever matched was because it
dumped the entire container config into the error message, but this had
nothing to do with the actual error.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 225e046d9d)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
`which` binary is often missing
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
(cherry picked from commit e928692c69)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
We have upgraded runc to rc93 and added CI for cgroup 2.
So we can move cgroup v2 out of experimental.
Fix issue 41916
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
(cherry picked from commit 1d2a660093)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This test has been flaky for a long time, failing with:
--- FAIL: TestInspect (12.04s)
inspect_test.go:39: timeout hit after 10s: waiting for tasks to enter run state. task failed with error: task: non-zero exit (1)
While looking through logs, noticed tasks were started, entering RUNNING stage,
and then exited, to be started again.
state.transition="STARTING->RUNNING"
...
msg="fatal task error" error="task: non-zero exit (1)"
...
state.transition="RUNNING->FAILED"
Looking for possible reasons, first considering network issues (possibly we ran
out of IP addresses or networking not cleaned up), then I spotted the issue.
The service is started with;
Command: []string{"/bin/top"},
Args: []string{"-u", "root"},
The `-u root` is not an argument for the service, but for `/bin/top`. While the
Ubuntu/Debian/GNU version `top` has a -u/-U option;
docker run --rm ubuntu:20.04 top -h 2>&1 | grep '\-u'
top -hv | -bcEHiOSs1 -d secs -n max -u|U user -p pid(s) -o field -w [cols]
The *busybox* version of top does not:
docker run --rm busybox top --help 2>&1 | grep '\-u'
So running `top -u root` would cause the task to fail;
docker run --rm busybox top -u root
top: invalid option -- u
...
echo $?
1
As a result, the service went into a crash-loop, and because the `poll.WaitOn()`
was running with a short interval, in many cases would _just_ find the RUNNING
state, perform the `service inspect`, and pass, but in other cases, it would not
be that lucky, and continue polling untill we reached the 10 seconds timeout,
and mark the test as failed.
Looking for history of this option (was it previously using a different image?) I
found this was added in 6cd6d8646a, but probably
just missed during review.
Given that the option is only set to have "something" to inspect, I replaced
the `-u root` with `-d 5`, which makes top refresh with a 5 second interval.
Note that there is another test (`TestServiceListWithStatuses) that uses the same
spec, however, that test is skipped based on API version of the test-daemon, and
(to be looked into), when performing that check, no API version is known, causing
the test to (always?) be skipped:
=== RUN TestServiceListWithStatuses
--- SKIP: TestServiceListWithStatuses (0.00s)
list_test.go:34: versions.LessThan(testEnv.DaemonInfo.ServerVersion, "1.41")
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 00cb3073f4)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was changed as part of a refactor to use containerd dist code. The
problem is the OCI media types are not compatible with older versions of
Docker.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit a876ede24f)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Fix issue 41762
Cherry-pick "drivers: btrfs: Allow unprivileged user to delete subvolumes" from containers/storage
831e32b6bd
> In btrfs, subvolume can be deleted by IOC_SNAP_DESTROY ioctl but there
> is one catch: unprivileged IOC_SNAP_DESTROY call is restricted by default.
>
> This is because IOC_SNAP_DESTROY only performs permission checks on
> the top directory(subvolume) and unprivileged user might delete dirs/files
> which cannot be deleted otherwise. This restriction can be relaxed if
> user_subvol_rm_allowed mount option is used.
>
> Although the above ioctl had been the only way to delete a subvolume,
> btrfs now allows deletion of subvolume just like regular directory
> (i.e. rmdir sycall) since kernel 4.18.
>
> So if we fail to cleanup subvolume in subvolDelete(), just fallback to
> system.EnsureRmoveall() to try to cleanup subvolumes again.
> (Note: quota needs privilege, so if quota is enabled we do not fallback)
>
> This fix will allow non-privileged container works with btrfs backend.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
(cherry picked from commit 62b5194f62)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
