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

Sun May 25 02:50:14 UTC 2014

On Sat, 2014-05-24 at 22:12 -0400, CDR wrote:
> I am using a Fedora container in production since a few days ago,
> created with LXC 1.0.3. No problems whatsoever. My environment is
> Ubuntu server 1404.
>  dpkg --list | grep -i lxc
> ii  liblxc1                                1.0.3-0ubuntu3
>              amd64        Linux Containers userspace tools (library)
> ii  lxc                                    1.0.3-0ubuntu3
>              amd64        Linux Containers userspace tools
> ii  lxc-templates                          1.0.3-0ubuntu3
>              amd64        Linux Containers userspace tools (templates)
> ii  python3-lxc                            1.0.3-0ubuntu3
>              amd64        Linux Containers userspace tools (Python 3.x
> bindings)

Are you running under XEN or hard iron?  He's running under XEN.  This
could be another point on the curve.

Thanks

Regards,
Mike

> On Sat, May 24, 2014 at 9:49 PM, Robert Pendell
> <shinji at elite-systems.org> wrote:
> > On Sat, May 24, 2014 at 9:29 PM, Michael H. Warfield wrote:
> >> 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.
> >>
> >
> > I took a try at this earlier and it worked fine.  I did a full install
> > and boot for Fedora 20 amd64 using "lxc-create -t download -n test" as
> > root.  Here is my environment.
> >
> > Host: Linode
> > Kernel: 3.14.3 (host supplied)
> > Technology: Xen Paravirtualized
> >
> > Xen Hypervisor Mode (HVM) shouldn't be much different than KVM however
> > I have not used each of them enough to know for sure.
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-- 
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/03e98531/attachment.sig>