Minikube: [BUG] systemd mounted using cgroup2, causing docker issues

[dalehamel]

Minikube version 0.18

This looks exactly like what is described in https://github.com/opencontainers/runc/issues/1175 and https://github.com/moby/moby/issues/28109

Environment:

• OS (e.g. from /etc/os-release): 2016.08
• VM Driver: xhyve
• ISO version: v0.18.0
• Install tools:
• Others:

What happened:

localkube starts, but is unable to launch any docker containers. The addon manager is unable to start due to:

no subsystem for mount

Examining the mounts, i see that /sys/fs/cgroup/systemd is mounted as cgroup2 instead of cgroup, and that we are on systemd 232, which is exactly the version that was described as having this bug.

If I revert back to a custom ISO that I have built myself, I can get things to work again, so I suspect something is broken in the ISO. That is quite bizarre though, as the upstream ISO was working for me on exactly this version before :|

What you expected to happen:

Systemd should mount the in the legacy cgroup type, and this should allow docker to work, addons to start, etc.

How to reproduce it (as minimally and precisely as possible):

Right now, just by clearing ~/.minikube and running minikube start from scratch

Anything else do we need to know:

[dlorenc]

Hmm I thought we added systemd.legacy_systemd_cgroup_controller=yes when we upgraded the buildroot code. Maybe that got dropped somehow?

[dalehamel]

Hmm I thought we added systemd.legacy_systemd_cgroup_controller=yes when we upgraded the buildroot code. Maybe that got dropped somehow?

Yeah this is super weird, is anyone else able to reproduce? I get it on the v0.18.0 iso that I'm downloading fresh :|

[r2d4]

Whats the sha256 of the iso? There was some weirdness in the release iso job yesterday.

[r2d4]

A bug in our release job overwrote the previous iso. I've uploaded the correct v0.18.0 and fixed the broken job. I think this should be fixed now

[dalehamel]

hi @r2d4 I'll verify shortly that the new ISO works, i figured it must be something like that :+1:

[r2d4]

The correct sha256 should be 1d0bad32c3eaa76110ef0a8030aa3dcb1f5fe75e017f28ff93d468af505e04aa

[mxab87ucgjf46heo]

Works well now. Thanks.

[dalehamel]

@r2d4 confirmed that the SHA now matches the one you mentioned, and that that SHA actually does indeed work.

Thanks for the fast fix guys! It pushed me to get our tooling to work with a custom ISO, so all-the-better :)