LXC 3.01, cannot start a container
Dear People,
I wanted to start my very first containers Code:
$ sudo lxc-ls --fancy Code:
$ sudo apparmor_status and during executing start command, something happened, something changed, What i've got is: Code:
$ sudo lxc-start -n gentooContainer -F 'unable to find a suitable fs in /proc/mounts, Use is it mounted? --subdomainfs to override.' Code:
/proc Code:
$ sudo lxc-start -n gentooContainer --logfile mylogfile --logpriority debug |
mounting is under
Code:
sudo /etc/init.d/apparmor start Code:
$ sudo lxc-start -n gentooContainer --logfile mylogfile --logpriority debug -F Code:
|
Code:
cgfsng - cgroups/cgfsng.c:get_hierarchy:204 - There is no useable devices controller |
Code:
$ lxc-checkconfig came into play, does this time, the outcome can help anyhow in solving the riddle of LXC? shortly, what came up from checkconfig is 1. Kernel configuration not found at /proc/config.gz; searching... 2. Cgroup v1 freezer controller: missing 3. newuidmap is not installed newgidmap is not installed (apt install newuidmap/newgidmap doesnt help) 4.there are plenty of not loaded things Code:
--- Misc --- |
Did you get this working?
I'm running in to the same problem. Unprivileged container. I get everything set up but it always fails with: Quote:
|
Hey,
I made containers running on VM Ubuntu Server without problem. So far on my client machine Linux i have no luck, i know though that updating LXC from 2.0.7 to 3.1 and installing apparmor moved my case a little bit forward Code:
$ sudo apt install apparmor-profiles |
OK, I got it working in Ubuntu at least.
The the container config I removed: Code:
#lxc.include = /usr/share/lxc/config/common.conf Code:
lxc.include = /usr/share/lxc/config/ubuntu.common.conf It took a massive amount of effort to figure this out. The documentation is severely lacking and searching for the errors on the 'Net does not yield results. Edit: Arch Linux is similar. The "userns.conf" seems to be the key. Code:
lxc.include = /usr/share/lxc/config/common.conf |
Arch Linux's default posture lacks support for unprivileged user namespaces, something which I can halfway understand given the searches you can make on Exploit-DB or the like even today -- there was a systemd issue just a week or so ago which allowed the creation of random setuid binaries via unprivileged namespaces.
|
All times are GMT -5. The time now is 10:20 PM. |