Jkube: OCI runtime create failed: this version of runc doesn't work on cgroups v2: unknown

[dcrissman]

I am running Fedora 32, when I execute mvn k8s:build, I get this error:
[ERROR] Failed to execute goal org.eclipse.jkube:kubernetes-maven-plugin:1.0.0-alpha-4:build (default-cli) on project codename: Failed to execute the build: Error while trying to build the image: Unable to build image [codename:0.0.1-SNAPSHOT] : "OCI runtime create failed: this version of runc doesn't work on cgroups v2: unknown" -> [Help 1]

I found a similar issue mentioned in another project, which suggest using podman. So at the end of the day, this may just be a +1 for https://github.com/eclipse/jkube/issues/66 because there may not be much else you can do.
https://github.com/jitsi/docker-jitsi-meet/issues/618

At any rate, submitting for the review of those that understand all these moving pieces better than I.

I also found https://github.com/geerlingguy/ansible-role-docker/issues/186 which suggests that the true problem may be an issue with the underlying docker-compose with the version of Fedora I am using.

[manusa]

Hi @dcrissman

It certainly seems to be a problem with the underlying Docker daemon (docker/for-linux#841), so I'm not sure we can do anything from our side to improve this for Docker build strategy.

I see you have a few workarounds here:

• Any of the suggestions in the linked issues regarding your Docker's configuration
• Use a remote Docker daemon (e.g. the one provided by Minikube)
• Wait to 1.0.0-RC-1 due in the next few days and use JIB build strategy

As you pointed out, we already have an issue for Podman, which will probably be shifted to provide support for a compatible Docker client (e.g. Buildah). So when implemented we will also have support for Podman 1.x. But this will have to wait for 1.1.0 version.

[dcrissman]

Then I will close this issue out. Thanks for taking a look.

For anyone in the future, I ran the following command on my localhost fedora instance, and it seems to have resolved the issue.
sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"

That said, I am uncertain of the consequences of this change, aside from it forced an older version of cgroup. So be warned.

[netoptimizer]

For anyone in the future, I ran the following command on my localhost fedora instance, and it seems to have resolved the issue.
sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"

I came here in "the future" via a Google search, thanks.
I just want to mention that I solved my problem by using the podman command instead of docker command to start the docker container image.

[keberwein]

I just want to mention that I solved my problem by using the podman command instead of docker command to start the docker container image.

Confirmed working with podman on Fedora 33.

[toh995]

I was having issues with this too on fedora 33, when I tried running sudo dnf install docker docker-compose.

After doing some digging, I found that docker actually has install instructions for Fedora!

• https://docs.docker.com/engine/install/fedora/
• https://docs.docker.com/engine/install/linux-postinstall/

After following the instructions mentioned above, I ran sudo dnf install docker-compose.

Worked like a charm for me :)

[Laeffe]

Just to add a bit of info, support for cgroups2 was added in docker 20.10.0: https://docs.docker.com/engine/release-notes/#20100
(for me the docker package in Fedora 33 installed docker 19, so there for I got this issue as well).