[lxc-users] Container not started

Tue Jun 17 16:42:36 UTC 2014

On Tue, 2014-06-17 at 09:42 -0400, CDR wrote:
> I already created a new Ubuntu Host and the container works fine.
> The question is: We have been living under the assumption that
> containers act like virtual machines, you may move them from host to
> host.

You can.  I do it quite frequently.  In many cases, I have no choice.
Right now to get a SUSE or Gentoo container running on a Fedora host, I
have to first create the container on a native host and then transport
the container, using rsync to the target host (almost always Fedora
19/20).  I've had great success doing things that way.  Even doing cross
arch.  I just did a pair of SUSE containers for i686 and x86_64 using
VirtualBox SUSE virtual machines and transporting those templates back
into the host for running under the host container system (you have to
set the lxc.arch parameter for i686 on x86_64).  Sometimes, that's the
only way to start a "seed" container to use as a bootstrap environment.

There may be problems with conflicting selinux (Oracle, Fedora, CentOS,
etc) setups and/or App Armour (SUSE, Ubuntu, Debian, etc).  I'm dealing
with that, right now, running Ubuntu Sid on Fedora 20 and getting an
apt-get install error that's throwing a "cannot get security labeling
handle".  The older Fedora template didn't do a good job of dealing with
the selinux issues and the new template basically disables it in a
container.  If your troublesome Fedora 20 container was built pre-0.9.0,
all bets are off.

> It is not the case, I can see. A Fedora 20 container created under
> Ubuntu will never start under a Fedora 20 host.

No, that's just not true.  Provably false.  To use the word "never"
implies that nobody can do it and it can not be done.  But I can do it
and it works, so "never" is provably false.  QED.

It should work if you properly migrate the image and the config.  Right
now there is the issue of that apparmour profile parameter but the
correct answer at the present time is to set it to "unconfined" which
will deal with problems on Ubuntu and SUSE hosts with apparmour in the
host and will be ignored on Oracle, CentOS, and Fedora hosts.  We also
have a problem with Fedora that the version of LXC is terribly out of
date from the repos and is only 0.9.0.

You seem to have custom config files and you don't say how you "copied"
the container (always specify the precise command used).  Did you just
copy the rootfs and hand roll another config on the other side?  Did you
copy the entire container directory, including config?  Did you use a
tarball of the entire container?  Did you rsync the entire container?
What rsync parameters (I used "rsync -avAHS")?  Was the container shut
down when you "copied" it?

Fact of the matter is, if you use the same template to create the
container on an Ubuntu host or an Fedora host, you are going to get the
same container and the same config (with different HW mac addresses) and
they will migrate (with the proviso of the apparmour profile).

You also do not say what versions of LXC were in use on the two hosts?
Were they distro stock (the version on Fedora 20 would then be 0.9.0 and
horribly out of date)?  Were they built from tarball?  Did the versions
match between the hosts?  I know, and I agree with Serge, that we need a
utility that someone like you can run that will report all this
information that we need.

> In my opinion this is a big flaw. Containers built by libvirt are
> truly portable, I have already verified that.
> I think we should fix this.

I think you are making unfounded generalized claims based on problems
you're having and others are not.  If that were even vaguely true then
Stephane's download template would be a wasted effort since that's
downloading precreated containers of various types and onto various
hosts.  If what you're saying is true, if I download a Fedora 20
container using the download template, it would not run on my Fedora 20
host because he builds them on an Ubuntu system.  I certainly have not
been experiencing this problem and I have a whole menagerie of different
containers of different distros migrated using "rsync -avAHS" with
config intactus.

> On Tue, Jun 17, 2014 at 9:23 AM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > Quoting CDR (venefax at gmail.com):
> >> I copied an LXC container fro Ubuntu Server to Fedora 20 and when I
> >> start it I get
> >> xc-start -n masterfe
> >> systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX
> >> +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
> >> Detected virtualization 'lxc'.
> >>
> >> Welcome to Fedora 20 (Heisenbug)!
> >>
> >> Set hostname to <masterfe>.
> >> No control group support available, not creating root group.
> >> [  OK  ] Reached target Remote File Systems.
> >> Socket service systemd-journald.service not loaded, refusing.
> >> [FAILED] Failed to listen on Journal Socket.

The above line in cosmetic.  It's not the cause of the failure.  It's
because we masked out systemd-journald.service in earlier versions where
it could run amok and consume all your CPU time.  That's since been
fixed by the systemd people and containers created under LXC 1.0.4 will
no longer mask journald and will not exhibit that error.  It can be
ignored or you can remove the symlink in the container for
{root_fs}/etc/systemd/system/systemd-journald.service.  It's a symlink
to /dev/null to mask the service.

One thing is weird.  The REAL error you're reporting (the "Caught
<SEGV>, dumped core as pid 13. Freezing execution.") is the error I
would expect on the Ubuntu host if you ran that Fedora container without
the aa_profile parameter (which is commented out in your example).
That's the exact error we've been seeing on Ubuntu hosts.  This is the
first I've heard of it on a Fedora host running a Fedora container.

It's also not clear if you ran "systemctl status
systemd-journald.socket" in the host or the container.  I would presume
in the host but the error was in the container, thus running that
command in the host is totally meaningless.

> > Two suggestions for investigating:

> > 1. create a new fedora container on the ubuntu host, see if it
> > has the same behavior.

1a: If it works on the Ubuntu host, transported it to the Fedora host
and see if it then works.  Use the stock configs as closely as possible
in each case.

> > 2. Look at the systemd source and see under what conditions the two
> > lines above occur.

Those two lines quote are not responsible, in this case.

Regards,
Mike
-- 
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/20140617/b1dd7de8/attachment.sig>