[lxc-users] Fedory 20 LXC fails to start on Ubuntu 14.04 host?
Timotheus Pokorra
timotheus at pokorra.de
Mon May 26 07:03:46 UTC 2014
Hello Federico,
that is strange.
I tried now on my old Laptop which runs Ubuntu 14.04, and got the same error:
<30>systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
<30>systemd[1]: Starting Root Slice.
<27>systemd[1]: Caught <SEGV>, dumped core as pid 11.
<30>systemd[1]: Freezing execution.
my kernel is:
uname -a
Linux timotheusp-LIFEBOOK-S7110 3.13.0-24-generic #47-Ubuntu SMP Fri
May 2 23:31:42 UTC 2014 i686 i686 i686 GNU/Linux
I am also using the packages 1.0.3-0ubuntu3 of lxc.
What might be the difference, so that it works for you and does not work for me?
Thanks,
Timotheus
On 25 May 2014 04:12, CDR <venefax at gmail.com> 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)
>
>
>
> 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
--
Kontaktdaten:
Zu Hause: 06261 8464490
in Mosbach: 06261/9879798
Mobil: 0176-29920835
More information about the lxc-users
mailing list