Open jboomer opened 2 years ago
jboomer
commented
2 years ago Additional info : I've also tried with the option SONIC_CONFIG_USE_NATIVE_DOCKERD_FOR_BUILD set to y. This will pass through the /var/run/docker.sock to the container. However, this also doesn't work because the docker GID on the host is not the same as the docker GID in the container (999).
jboomer
commented
2 years ago So I've think I finally found the root of the problem : arch mounts the cgroups as cgroup v2, while in Ubuntu 20.04 it is still mounted as cgroup v1. This causes problems with the docker version in stretch and buster, but is supported in the docker supplied with bullseye.
The above workaround with SONIC_CONFIG_USE_NATIVE_DOCKERD_FOR_BUILD set to y works for me if I pass uid and gid of docker by adding:
SONIC_BUILDER_EXTRA_CMDLINE="-u $(id -u):$(getent group docker | cut -d: -f3)"However, in this case it still fails when creating the final installer image, as a chroot inside the buster environment is done and docker commands are called there.
So the only real way to make it work is to make sure the host mounts the cgroupfs as cgroup v1 by passing the kernel parameter systemd.unified_cgroup_hierarchy=0 in the host. I don't know which other distros use cgroup v2 by default but I think they will have the same problem.
zhangyanzhao
commented
2 years ago @jboomer looks like you are doing the investigation pretty well, any help do you need?
bluecmd
commented
2 years ago https://github.com/Azure/sonic-buildimage/issues/7354 might be related?
jboomer
commented
2 years ago @bluecmd Yes that seems to be the same thing, debian bullseye also mounts as v2 by default.
@zhangyanzhao For me the issue is solved, but maybe this info should be included in a readme? Also while the build works on Ubuntu 20.04, starting from 21.10 the build will fail in the same way on Ubuntu I think.
ashwin-h
commented
1 year ago So I've think I finally found the root of the problem : arch mounts the cgroups as cgroup v2, while in Ubuntu 20.04 it is still mounted as cgroup v1. This causes problems with the docker version in stretch and buster, but is supported in the docker supplied with bullseye.
The above workaround with
SONIC_CONFIG_USE_NATIVE_DOCKERD_FOR_BUILDset toyworks for me if I pass uid and gid ofdockerby adding:SONIC_BUILDER_EXTRA_CMDLINE="-u $(id -u):$(getent group docker | cut -d: -f3)"However, in this case it still fails when creating the final installer image, as a
chrootinside the buster environment is done and docker commands are called there.So the only real way to make it work is to make sure the host mounts the cgroupfs as cgroup v1 by passing the kernel parameter
systemd.unified_cgroup_hierarchy=0in the host. I don't know which other distros use cgroup v2 by default but I think they will have the same problem.
i am facing the same issue.. After adding "systemd.unified_cgroup_hierarchy=0" to kernel command line, build is successful.
whitej6
commented
5 months ago Easy work around is to update the /etc/docker/daemon.json to include this key. Resolves most issues when running docker in docker {"default-cgroupns-mode": "host"}
Description
Can not build
target/sonic-barefoot.bin, the build fails at thedocker-startstep with error : "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"If I enter the build container with
make sonic-slave-bash, and try to start docker withsudo dockerd --experimental --storage-driver=vfs -D, I see the following errors:This goes for both 'stretch' and 'buster' build containers. Using 'bullseye' I can start docker in the build container however.
The host in this case is Arch, with docker version "20.10.12, build e91ed5707e".
Steps to reproduce the issue:
make initmake configure PLATFORM=barefootmake target/sonic-barefoot.binDescribe the results you received:
Describe the results you expected:
Image is built
Output of
show version:N.A.
Output of
show techsupport:N.A.
Additional information you deem important (e.g. issue happens only occasionally):