The rootfs used Vivid and now Wily, but the issue remains with both.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1452451
Title:
failed to change apparmor profile to
Which distribution is in the rootfs?
** Changed in: lxc (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1452451
Title:
failed to change
** Changed in: lxc (Ubuntu)
Status: Incomplete = Triaged
** Changed in: lxc (Ubuntu)
Importance: Undecided = Critical
** Changed in: lxc (Ubuntu)
Status: Triaged = New
** Changed in: lxc (Ubuntu)
Importance: Critical = High
--
You received this bug notification because you
This happens if the container config doe snot specify mounting /proc,
because there is no (or a wrong) /proc in the container until the
container's init mounts it.
So lxc-attach needs to mount a temporary /proc (after switching
namespaces) for the sake of setting the lsm label.
** Changed in:
I cannot reproduce this.
Would it be possible to coordinate your handing off a broken system to
me? Unfortunately I am out tomorrow and Friday, but perhaps sometime
next week?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in
Dang, I was afraid you might not be able to reproduce, being a race and
all. I'm not sure it's possible to hand off the system as it's my
primary development machine.
I think I will take a stab in trying to debug this. A quick looks shows
that it is failing in this block in lsm/apparmor.c:
if
So, if I remove the lxc-wait out of the start/wait/attach sequence, then
I always get the failure. This really points to a race where RUNNING is
being reported before it is really fully started.
It looks like the RUNNING state is set in start.c, so perhaps it is
being set a bit too early where
I've been trying to capture a log of the failure when running lxc-attach
and it seems to cause just enough delay to get by the race. Also, it
does not always occur, but more time than not, the error happens leading
more credence to this being a race. I've attached the config I use for
the
Actually, running sudo unity8-lxc-setup has a start/wait/attach
sequence that is causing failures. Another way I try to reproduce after
the whole container is setup is to create a little script with the
following:
lxc-start -n unity8-lxc
lxc-wait -t 5 -s RUNNING -n unity8-lxc
lxc-attach -n
I assume that bin/unity8-lxc-compositor is the script you are using. But
how does it get run? Do I just install that package in a container to
reproduce this?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
Hi Serge,
This does not happen when doing this by hand, only in a script. And I
can't seem to reproduce on a container created using a template. So
far, I've only been able to reproduce this when creating the container
using the procedure in lp:unity8-preview-lxc. This is a project that
was
Hi,
could you please show a simple script (doing lxc-create lxc-start
lxc-wait lxc-attach) that I could reproduce with?
Just to be sure - you get this error running this by hand, right? If it
happens at boot time, then you should make sure that the 'lxc' init job
has completed before your
12 matches
Mail list logo