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

CDR venefax at gmail.com
Sun May 25 03:13:02 UTC 2014


Hard iron.
But containers should be transparent for him, since LXC does not use
any "real" virtualization.
As long as his kernel is the right version.

On Sat, May 24, 2014 at 10:50 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> 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!
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users


More information about the lxc-users mailing list