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