[lxc-users] unpriviledged container failing to get an IP in Ubuntu 16

[Ivan Ogai]

The problem is the encrypted home.

FYI:

If the user has an encrypted home (e.g. selecting the option in the
Ubuntu 16.04 installer) unprivileged LXC containers are not possible
(see error below).

In Ubuntu 14.4 they do work.

This is very unfortunate for anyone who need to keep data confidential
in the case that a computer is stolen, and from other users of the
computer.

* Ivan Ogai <lxc-users at ogai.name> [2016-09-09 16:57]:
> 
> Update 2: I have the same issue on another computer also with a fresh
> installation of Ubuntu 16.04. I wonder if I could expect some help here
> to debug the problem, or if I should report it on github or launchpad?
> 
> To summarize the problem in both computers:
> 
> - fresh install of Ubuntu 16.04
> - unprivileged containers gets no IP
> - systemd core dump (IIUC)
> - container cannot be stopped
> - no logs are created from lxc-stop, which never finishes.
> 
> Additional info:
> 
> - Encrypted hard disk was selected when installing Ubuntu.
> - The user's home is also encrypted.
> 
> May that be related? Which one is more likely to be the culprit?
> 
> * Ivan Ogai <lxc-users at ogai.name> [2016-09-09 11:04]:
> > 
> > Update: the error mentioned below has disappeared (was it a hardware
> > failure?), but the container doesn't get an IP. Doing this in the
> > container fixes it:
> > 
> >     dhclient eth0
> > 
> > Is this the expected behaviour? With LXC 1 (Ubuntu 16 has LXC 2), the
> > containers were getting an IP.
> > 
> > * Ivan Ogai <lxc-users at ogai.name> [2016-09-09 09:52]:
> > > Hello !
> > > 
> > > I sent this email yesterday to the list but I don't see it in the
> > > archives.
> > > 
> > > https://lists.linuxcontainers.org/pipermail/lxc-users/2016-September/thread.html
> > > 
> > > 
> > > Hello !
> > > 
> > > in a fresh Ubuntu 16.04 installation, when starting an unpriviledged container,
> > > it gets no IP (lxc-ls --fancy in the host). dmesg last lines in the container
> > > are:
> > > 
> > > [ 1743.140633] eth0: renamed from vethSLN6EBp
> > > [ 1743.180001] IPv6: ADDRCONF(NETDEV_CHANGE): vethSLN6EB: link becomes ready
> > > [ 1743.180205] lxcbr0: port 2(vethSLN6EB) entered forwarding state
> > > [ 1743.180238] lxcbr0: port 2(vethSLN6EB) entered forwarding state
> > > [ 1743.263802] cgroup: new mount options do not match the existing superblock, will be ignored
> > > [ 1758.195512] lxcbr0: port 2(vethSLN6EB) entered forwarding state
> > > [ 1920.142032] INFO: task systemd:6560 blocked for more than 120 seconds.
> > > [ 1920.142038]       Not tainted 4.4.0-36-generic #55-Ubuntu
> > > [ 1920.142039] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > [ 1920.142041] systemd         D ffff8803d6acbb58     0  6560   6548 0x00000100
> > > [ 1920.142046]  ffff8803d6acbb58 ffff8803cfdb8dc0 ffff88042cf45280 ffff8803cfdb8dc0
> > > [ 1920.142049]  ffff8803d6acc000 ffff880035672088 ffff880035672070 ffffffff00000000
> > > [ 1920.142052]  fffffffe00000001 ffff8803d6acbb70 ffffffff81829ec5 ffff8803cfdb8dc0
> > > [ 1920.142055] Call Trace:
> > > [ 1920.142064]  [<ffffffff81829ec5>] schedule+0x35/0x80
> > > [ 1920.142067]  [<ffffffff8182cb12>] rwsem_down_write_failed+0x202/0x350
> > > [ 1920.142072]  [<ffffffff81288ff0>] ? kernfs_sop_show_options+0x40/0x40
> > > [ 1920.142076]  [<ffffffff813ff853>] call_rwsem_down_write_failed+0x13/0x20
> > > [ 1920.142078]  [<ffffffff8182c34d>] ? down_write+0x2d/0x40
> > > [ 1920.142081]  [<ffffffff8120fb80>] grab_super+0x30/0xa0
> > > [ 1920.142083]  [<ffffffff81210112>] sget_userns+0x152/0x450
> > > [ 1920.142085]  [<ffffffff81289070>] ? kernfs_sop_show_path+0x50/0x50
> > > [ 1920.142088]  [<ffffffff812892de>] kernfs_mount_ns+0x7e/0x230
> > > [ 1920.142092]  [<ffffffff8111858b>] cgroup_mount+0x2eb/0x7f0
> > > [ 1920.142094]  [<ffffffff812111d8>] mount_fs+0x38/0x160
> > > [ 1920.142097]  [<ffffffff8122d1d7>] vfs_kern_mount+0x67/0x110
> > > [ 1920.142100]  [<ffffffff8122f9a9>] do_mount+0x269/0xde0
> > > [ 1920.142103]  [<ffffffff8123084f>] SyS_mount+0x9f/0x100
> > > [ 1920.142106]  [<ffffffff8182dfb2>] entry_SYSCALL_64_fastpath+0x16/0x71
> > > 
> > > Trying to stop it in the host with "lxc-stop -n test" has no result. The
> > > command never finishes. This one either:
> > > 
> > >     lxc-stop -n test --kill --nolock
> > > 
> > > No log is produced with:
> > > 
> > >     lxc-stop -n test --kill --nolock -o /tmp/log -l DEBUG