[lxc-users] Fedory 20 LXC fails to start on Ubuntu 14.04 host?

[Michael H. Warfield]

On Sat, 2014-05-24 at 22:00 +0200, Timotheus Pokorra wrote:
> Hello Mike,

> > 1) Are you running this container unprivileged?
> I checked what it means to run a container unprivileged. I think I run
> it privileged, I am logged in as root on the host machine, and I am
> just trying to start with lxc-start -n myFedora.

> > 2) Have you tried creating the container using the -t fedora template?
> I tried lxc-create -t fedora -n myFedoraTest
> Unfortunately, the result is the same.

> >> Anyone any ideas?
> >
> > The error the OP was showing was a SEGV (11) in systemd.  He did not
> > specify how he created the container, or how he was running it (priv /
> > non-priv).  A SEGV in systemd would be pretty serious.  It would seem to
> > be an executable conflict at a pretty deep layer.  I guess it would also
> > be good to know what the host kernel version is as well.
> I indeed get the exact same output as the OP.

> On the host:
> uname -a
> Linux j80074.servers.jiffybox.net 3.2.0-60-virtual #91-Ubuntu SMP Wed
> Feb 19 04:13:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

> The LXC host (Ubuntu) is a virtual machine running in a XEN environment.
> I would understand if that is not possible, but it is possible since
> Debian 7 and CentOS 6 containers run fine on this host.

XEN???

Oh crap...  It's information like this that is critical to understand
what's going on.

You're in an environment with a Fedora 20 container running on an Ubuntu
virtualized host in a Xen guest running under a Xen paravirtualization
hypervisor.  Without knowing this, it would be impossible to even guess
where the problem may lay (even with this information, it may be
impossible).  I haven't even begun to attempt to reproduce it but the
number of independent variables just shot through the roof.

First order of troubleshooting.  Eliminate independent variables...

Have you attempted running a Fedora container on an Ubuntu host running
on raw iron?  If not, you need to do so and report those results.

I haven't screwed with Xen in years but all HW and para virtualization
requires some instruction emulation back in the hypervisor.  This could
easily be some incompatibility between the Xen hypervisor in supervisory
state and emulating some instruction that systemd is requiring.  I can't
even begin to reproduce your environment at this point with Xen in the
loop.  You really need to simplify this into a basic install with basic
containers and try running it that way.  This could be a problem in the
Xen hypervisor, it could be a problem in the Xen guest virt drivers, it
could be in systemd that never expected to run in a container in a guest
under Xen.  I can't tell. 

In the upcoming week, I'll look into firing up an Ubuntu server, since I
now have a free Dell tower now that I've virtualized my NST development
engines into LXC containers.  I don't even want to THINK about doing
Xen.

You've got to simplify that environment in order to isolate the origin
of the problem.

> Thanks,
>   Timotheus

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140524/00b6577f/attachment.sig>