[Question] How to make runc work on Lineage OS on Oneplus 6 #20650
Unanswered
kebien6020
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi, I'm trying to run docker on termux by roughly following the steps on this gist.
My environment is a Oneplus 6 (enchilada) phone, running Lineage OS 21 (Android 14), with a custom Lineage OS-based kernel to enable the features required by docker, it's of course rooted, the kernel version is this:
I can't run a hello-world container, and narrowed it down to runc not being able to create the container. Here is my runc version:
One of the things that seems weird is that the cgroup mounts do not align to what runc expects, these are my actual cgroup mounts, right after a clean reboot:
# findmnt -t cgroup,cgroup2 TARGET SOURCE FSTYPE OPTIONS /dev/blkio none cgroup rw,nosuid,nodev,noexec,relatime,blkio /dev/cpuctl none cgroup rw,nosuid,nodev,noexec,relatime,cpu /dev/cpuset none cgroup rw,nosuid,nodev,noexec,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent /dev/memcg none cgroup rw,nosuid,nodev,noexec,relatime,memory /dev/stune none cgroup rw,nosuid,nodev,noexec,relatime,schedtune /dev/op_cgroup/freezer none cgroup rw,relatime,freezer /sys/fs/cgroup none cgroup2 rw,nosuid,nodev,noexec,relatime(Skipping over the copies of the same mounts inside
/debug_ramdisk/.magisk/mirror/)runc seems to expect either:
/sys/fs/cgroup/sys/fs/cgroup, a cgroupv2 mount on/sys/fs/cgroup/unifiedand various cgroupv1 mounts anywhere (autodetected)/sys/fs/cgroupand autodetected cgroupv1 mounts anywhereMy system seems to be setup as a hybrid, but it doesn't match the hybrid expectations because is does have a cgroupv2 mount point at
/sys/fs/cgroup.So when I try to run a container with runc, it fails because it's assuming a pure v2 system, but the v2 cgroups only has the pid controller available, all other controllers are mounted to the v1 hierarchy and are unavailable under v2.
On my PC:
On my phone:
At first the command
runc run test1just hanged there doing nothing. Since I couldn't kill it with Ctrl+C, I had to open a separate terminal and kill the child process of runc with this:pkill -9 -f "runc init". Note: If you kill the parent process instead (runc run), the container state isn't cleaned up properly and gets stuck in a state where you can't create a new one with the same id (test1 in this case), and runc delete can't delete it either.The error message suggests that it failed trying to find the file
memory.eventsthat appears automatically whenever you create a new folder inside a cgroupsv2 mount, and the memory controller is available. Since the memory controller is not available, the file doesn't appear and this operation fails.Just to validate that this approach makes sense, I do the same on my PC and this is the expected output:
Additionally, here's
runc runon both systems with--debug.Click to expand
Forcing cgroupv1
Since I'm root, I tried to forcefully unmount the cgroupsv2 mount so that runc detects the system as a cgroupsv1 system. This eventually destabilizes my system and causes a reboot, but before it reboots I try to run a container.
Output with --debug flag
So the issue isn't just the cgroup setup, even when it's fully working with cgroupv1 (I went into /dev/memory/ and /dev/cpuctl/ and verified that while the prcess is stuck, the PID for the runc init process is properly placed in the expected cgroups), the container creation process still gets stuck.
Additional validations
For completeness' sake, here is the output of docker's check-config.sh script:
Click to expand
Note: I specifically disabled CONFIG_USER_NS, because it was one of the suggested workarounds on some comments in the original gist, but got the same results with and without this kernel option.
I also validated that the rootfs is ok by running a simple chroot off of it:
At this point I don't really know what else to test. Some help would be appreciated.
Beta Was this translation helpful? Give feedback.
All reactions