It depends on CONFIG_UIDGID_CONVERTED, but I cannot find/activate it and the help is completely empty.

Code:

│ Symbol: UIDGID_CONVERTED [=n] │
│ Type : boolean

Googling around didn't help.

Without this, lxc is unable to work.

Code:

* Checking for suitable kernel configuration options...
* CONFIG_USER_NS: is not set when it should be.
* CONFIG_NETPRIO_CGROUP: as of kernel 3.3 and lxc 0.8.0_rc1 this causes LXCs to fail booting.
* Please check to make sure these options are set correctly.
* Failure to do so may cause unexpected problems.

I tried linux-3.7.1-gentoo and linux-3.6.11-gentoo sources, with custom and alldefconfig configs.

Thanks @s4e8, but disabling those features is not enough for me.
I've already seen Linux Kernel Driver DataBase about, but I'm still unable neither to find the feature in the dummy 'make menuconfig' nor to write manually a working .config.

After removing NFS_FS (the one in the list) I tried to manually write my .config, without success.

Through the new CONFIG_USER_NS may not work with lxc, because it's still under heavy-rewriting.

hujuice wrote:

Thanks @s4e8, but disabling those features is not enough for me.
I've already seen Linux Kernel Driver DataBase about, but I'm still unable neither to find the feature in the dummy 'make menuconfig' nor to write manually a working .config.

After removing NFS_FS (the one in the list) I tried to manually write my .config, without success.
(The make phase correct my .config, removing the last two lines listed)

Thanks Hu, USER_NS was not the main problem, not the problem blocking the network.
Anyway, everything is smoky to me, about the kernel configuration and about my network problem.
So, I cannot mark as "solved" the thread.

The network was stopped because the new network management (not so clear to me).
Network devices seems disappeared, even if the network works in the container.
What I did is to give a complete network configuration in the lxc configuration file and remove the 'need net' dependency from services.

Here is my new rc.log. It appears really ugly, but the wondering fact is that THE NETWORK WORKS.

In my case I have many lxc containers and I can`t update them anymore because the last openrc that works properly is 10.5. The newest are have broken network support.
I`m still searching for the solution.

Kron, you have to enable this kind of line in your container configuration:

From /etc/lxc/dev9.conf:

lxc.mount.entry=sys /VMs/lxc/dev9/sys sysfs defaults 0 0

Please, note that this introduces a security risk, as documented in http://blog.bofh.it/debian/id_413.
So, it makes sense if your container(s) administration is shared with the host administration.
In other words, the container adminstrator could "evade" to the host: never give the container to untrusted people.

Not really. It`s a bit strange, in the other hand - it works. When you use a 'newnet' - net.lo init script are no more functional.
As I remember openrc developers have plans to remove this USE flag https://bugs.gentoo.org/show_bug.cgi?id=445820#c5
I have many containers and I don`t want to mount /sys inside the container because some users have a root privileges, so it`s a bit dangerous in my situation.
I guess 'newnet' is the single solution for me for that moment.

For me s4e8 answer gives the direction and here http://www.funtoo.org/Linux_Containers they recommend the same.
So i started to turn off these option in kernel and suddenly user namespace option appeared!
But then kcopy compilation failed so i took it out of my config temporarly just see a hopefully working lxc

Any idea why lxc doesn't like xfs, fuse, or nfs? The nfs thing is also mentioned here by ago. Anyone know if it's planned to bring these capabilities back?_________________.sigs waste space and bandwidth

As far as I know, LXC has no issue with any of those features. LXC suggests, but does not require, the availability of kernel support for user namespaces. If you want user namespaces, then the kernel requires those features to be disabled in v3.8 because the patches to make those features work correctly with user namespaces were not merged for v3.8, so enabling both NFS and USER_NS would result in failure. I believe v3.9 has support for NFS with USER_NS, but still requires XFS=n. I think I saw plans for v3.10 to support XFS=y with USER_NS=y.

Oh my god, how crazy is this... Disable Kerneloption for other options...

You resurrected a two month old thread to complain about an issue that is not all that uncommon. Kernel policy generally permits adding features which do not work with every possible permutation of other options, provided that the feature does not significantly break the others. Using a Kconfig directive to lock out USER_NS when XFS=y and vice versa is an elegant way of preventing users from configuring kernels known not to work.

I'm with boospy on this one: the disabling of so many fundamental kernel-options to enable LXC *is* completely crazy :-O

Sure, I'm also resurrecting an old thread, but the complaint remains as fresh as yesterday's hardened-sources / gentoo-sources (3.8.13). I've run up against showstopping Vserver limitations, and was trying LXC. After numerous kernels, and numerous config/compile/check cycles, I wound up at this (helpful) thread...

I shouldn't shoot the messenger but s4e8 has provided an extensive, helpful list that utterly kills LXC (for me). I'm looking at LXC for server-consolidation; I've used XFS for over a decade (including on IRIX), and I'm quite adamant about sticking with it. Same for NFS, AutoFS (and IPv6, CIFS, DAV, etc). While disappointing, this thread has helped me understand that LXC is still many bricks short of a full load.

I was hoping for a chroot/container-based "virtualization" scheme, but it just doesn't look like things are well-baked at this moment, for server-features of today and for the next decade. Of course, it's all there with heavier-weight paravirtualization...

As I stated earlier in the thread, you do not need to enable USER_NS to use LXC. LXC may work better with USER_NS, but if you read up on USER_NS, you will see that it is in turn not fully baked. There are certain kernel components which assume that a kuid of 0 grants privilege in the initial user namespace. As a result, you cannot safely grant kuid 0 into an inner namespace. The restriction on XFS will be relaxed when XFS compiles with USER_NS enabled. For the 3.8 series kernel, you can have a working XFS or a working USER_NS, but not both.

Since you concur with his statement, would you mind explaining what you think the proper solution would be? Would you prefer that the kernel offer you the option to enable USER_NS, but have it force XFS off when you do so? Would you prefer that it let you enable both, then fail to build when the compiler discovers that the XFS code is not compatible with USER_NS?