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 <vene...@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 > <shi...@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@lists.linuxcontainers.org >> http://lists.linuxcontainers.org/listinfo/lxc-users > _______________________________________________ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users -- Kontaktdaten: Zu Hause: 06261 8464490 in Mosbach: 06261/9879798 Mobil: 0176-29920835 _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
