[lxc-users] lxc-start failing in Fedora 20

István Király LaKing at D250.hu
Mon Jun 30 19:24:03 UTC 2014 

>> systemd-journald had a bad propensity to run amok

I updated my system, updated lxc to 1.0.4, created a new container.
(complete re-install)
Unfortunately, systemd-journald was running on 100% CPU usage, as seen in
previous versions.
The bug is still there, ... but now the mask is not applied automatically.


On Mon, Jun 30, 2014 at 3:46 PM, Serge Hallyn <serge.hallyn at ubuntu.com>
wrote:

> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > On Sat, 2014-06-28 at 20:12 +0530, Ajith Adapa wrote:
> > > Thanks @Michael
> >
> > > I am running lxc 1.0.3 version in rawhide.
> >
> > Ah.  Ok...  Understand that lxc-autostart is not fully functional in
> > 1.0.3 and will not autoboot containers on host boot.  That's in 1.0.4
> > which should be in there rsn.
> >
> > > My fedora 20 setup is a VM and hasn't got libvirtd running. As you
> > > mentioned earlier thats the reason why virbr0 is not created by
> > > default.
> >
> > > Why doesn't lxc directly support creating virbr0 ? Might be one more
> > > option in the template.
> >
> > For that, I think I'll have to defer to Serge or Stéphane for a
> > definitive answer but, IMHO, it's largely because libvirt is already
> > responsible for virbr0 and we could result in conflicts.  Not saying we
> > would but just that there could be.  Worse case would be a race
> > condition between us in lxc-autostart-helper and the libvirt service in
> > trying to create that bridge.  It could result in a failure in one
> > service or the other.
> >
> > It's also possible that we've just never really looked into it.  Perhaps
> > there should be a run-time dependency on libvirt running that we could
> > detect and document better.  The error message leaves a little bit to be
> > desired.
>
> Right, the setup of host bridges is not for lxc-start to do, but for the
> distro-dependent init scripts.  In Ubuntu we create lxcbr0 - perhaps the
> fedora/centos/oracle scripts should do the same?  If they depend on virbr0
> then indeed they should depend on libvirt being started before proceeding
> to autostart containers.
>
> We're definately open to patches that make for clearer error messages,
> Stéphane pushed one like that recently.  It'd be nice if you didn't have
> to understand every detail about container startup to debug why a
> container failed.
>
> > Given that, it's not a template issue at all and wouldn't (shouldn't)
> > require any container config changes.  It would need to be some sort of
> > lxc service startup option to precreate the needed bridges or a helper.
> >
> > Given all that, 1.0.4 may very well resolve (or may compound) the
> > problem as the lxc.service systemd service uses a script that waits for
> > virbr0 from libvirt to settle before autobooting containers (there's
> > where your race conditions would live).  I'm not sure how that's going
> > to play out if libvirt is not running.  It looks like we may need to add
> > code to /usr/libexec/lxc/lxc-autostart-helper to insure that the default
> > lxc network bridge is running.  I'd be reluctant to adding it to the
> > lxc-start code as it would be difficult to insure it would always be
> > doing the right thing including cases like unpriv containers.
> >
> > This is a corner case that, maybe, Dwight and I may need to address or
> > punt it over to Serge or Stéphane.  It's complicated in that we don't
> > always know the bridges that are needed or even if they are need if a
> > site is using "macvlan" or "physical" network types.  It definitely
> > needs to be tested.
> >
> > > I will try out the steps given regarding password.
> >
> > Cool.
> >
> > > Regards,
> > > Ajith
> >
> > Regards,
> > Mike
> >
> > > On Sat, Jun 28, 2014 at 7:13 PM, Michael H. Warfield <mhw at wittsend.com>
> wrote:
> > > > On Sat, 2014-06-28 at 15:34 +0530, Ajith Adapa wrote:
> > > >> Hi,
> > > >
> > > >> lxc-start is failing in latest fedora 20 saying virbr0 is not found.
> > > >
> > > > What version of LXC?  AFAIK, it's still 0.9.0 with 1.0.3 (hopefully
> > > > 1.0.4 real soon now) in rawhide.
> > > >
> > > >> 1. Is it madatory for the admin to create virbr0 interface before
> > > >> starting a container ?
> > > >
> > > > Yes.  You have two ways to do this.
> > > >
> > > > 1) [Preferred] have libvirt running.  That's the default bridge for
> > > > libvirt and it wills set it up and manage it for you.
> > > >
> > > > 2) Create the bridge manually.
> > > >
> > > > If you have another bridge already on the system, you can change the
> > > > bridge name in the configuration files and in /etc/lxc/default.conf.
> > > > Personally, I keep libvirt and virbr0 up and running for my nat'ed
> > > > bridge while I have a static lxcbr0 to which the primary interface
> has
> > > > been added for a true bridge to the outer network (but I have lots of
> > > > IPv4 addresses so I can allow them direct access to the address pool.
> > > >
> > > >> 2. How can I create a container with a default password for root
> > > >> rather than auto-generating the same ?
> > > >
> > > > It's a tuning knob in the template.  Read the comments in
> > > > the /usr/share/lxc/templates/lxc-fedora file starting around line
> 32...
> > > >
> > > > --
> > > >
> > > > # Some combinations of the tunning knobs below do not exactly make
> sense.
> > > > # but that's ok.
> > > > #
> > > > # If the "root_password" is non-blank, use it, else set a default.
> > > > # This can be passed to the script as an environment variable and is
> > > > # set by a shell conditional assignment.  Looks weird but it is what
> it is.
> > > > #
> > > > # If the root password contains a ding ($) then try to expand it.
> > > > # That will pick up things like ${name} and ${RANDOM}.
> > > > # If the root password contians more than 3 consecutive X's, pass it
> as
> > > > # a template to mktemp and take the result.
> > > > #
> > > > # If root_display_password = yes, display the temporary root
> password at exit.
> > > > # If root_store_password = yes, store it in the configuration
> directory
> > > > # If root_prompt_password = yes, invoke "passwd" to force the user
> to change
> > > > # the root password after the container is created.
> > > > #
> > > > # These are conditional assignments...  The can be overridden from
> the
> > > > # preexisting environment variables...
> > > > #
> > > > # Make sure this is in single quotes to defer expansion to later!
> > > > # :{root_password='Root-${name}-${RANDOM}'}
> > > > : ${root_password='Root-${name}-XXXXXX'}
> > > >
> > > > # Now, it doesn't make much sense to display, store, and force change
> > > > # together.  But, we gotta test, right???
> > > > : ${root_display_password='no'}
> > > > : ${root_store_password='yes'}
> > > > # Prompting for something interactive has potential for mayhem
> > > > # with users running under the API...  Don't default to "yes"
> > > > : ${root_prompt_password='no'}
> > > >
> > > > --
> > > >
> > > > Stated plainly, create your container with the following:
> > > >
> > > > export root_store_password='no'
> > > > export root_password='my_root_password'
> > > > lxc-create -n container1 -t fedora
> > > > lxc-create -n container2 -t fedora
> > > >
> > > > etc, etc, etc...  Each container will have the root password set to
> > > > "my_root_password".
> > > >
> > > > Or this:
> > > >
> > > > export root_prompt_password='yes'
> > > >
> > > > Then run lxc-create and it will then prompt you for the new root
> > > > password.
> > > >
> > > > NOTE: This only works for the Fedora and CentOS templates.  It has
> not
> > > > been ported to any of the other templates at this time!
> > > >
> > > >>
> > > >> # lxc-create -n test -t fedora
> > > >> Host CPE ID from /etc/os-release: cpe:/o:fedoraproject:fedora:20
> > > >> Checking cache download in /var/cache/lxc/fedora/x86_64/20/rootfs
> ...
> > > >> Cache found. Updating...
> > > >> No packages marked for update
> > > >> Update finished
> > > >> Copy /var/cache/lxc/fedora/x86_64/20/rootfs to
> /var/lib/lxc/test/rootfs ...
> > > >> Copying rootfs to /var/lib/lxc/test/rootfs ...
> > > >> Storing root password in '/var/lib/lxc/test/tmp_root_pass'
> > > >> Expiring password for user root.
> > > >> passwd: Success
> > > >> installing fedora-release package
> > > >> Package fedora-release-20-3.noarch already installed and latest
> version
> > > >> Nothing to do
> > > >>
> > > >> Container rootfs and config have been created.
> > > >> Edit the config file to check/enable networking setup.
> > > >>
> > > >> The temporary root password is stored in:
> > > >>
> > > >>         '/var/lib/lxc/test/tmp_root_pass'
> > > >>
> > > >>
> > > >> The root password is set up as expired and will require it to be
> changed
> > > >> at first login, which you should do as soon as possible.  If you
> lose the
> > > >> root password or wish to change it without starting the container,
> you
> > > >> can change it from the host by running the following command (which
> will
> > > >> also reset the expired flag):
> > > >>
> > > >>         chroot /var/lib/lxc/test/rootfs passwd
> > > >>
> > > >> # lxc-start -n test
> > > >> lxc-start: failed to attach 'vethKOT10G' to the bridge 'virbr0' :
> No such device
> > > >> lxc-start: failed to create netdev
> > > >> lxc-start: failed to create the network
> > > >> lxc-start: failed to spawn 'test'
> > > >>
> > > >> ======================================================
> > > >> configuration
> > > >> ======================================================
> > > >>
> > > >> # yum install lxc*
> > > >> Loaded plugins: langpacks
> > > >> Package lxc-extra-1.0.3-2.fc21.x86_64 already installed and latest
> version
> > > >> Package lxc-templates-1.0.3-2.fc21.x86_64 already installed and
> latest version
> > > >> Package lxc-libs-1.0.3-2.fc21.x86_64 already installed and latest
> version
> > > >> Package lxc-1.0.3-2.fc21.x86_64 already installed and latest version
> > > >> Package lxc-doc-1.0.3-2.fc21.noarch already installed and latest
> version
> > > >> Package lxc-devel-1.0.3-2.fc21.x86_64 already installed and latest
> version
> > > >>
> > > >> -------------------------------------------
> > > >>
> > > >> # lxc-checkconfig
> > > >> Kernel configuration not found at /proc/config.gz; searching...
> > > >> Kernel configuration found at /boot/config-3.14.5-200.fc20.x86_64
> > > >> --- Namespaces ---
> > > >> Namespaces: enabled
> > > >> Utsname namespace: enabled
> > > >> Ipc namespace: enabled
> > > >> Pid namespace: enabled
> > > >> User namespace: enabled
> > > >> Network namespace: enabled
> > > >> Multiple /dev/pts instances: enabled
> > > >>
> > > >> --- Control groups ---
> > > >> Cgroup: enabled
> > > >> Cgroup clone_children flag: enabled
> > > >> Cgroup device: enabled
> > > >> Cgroup sched: enabled
> > > >> Cgroup cpu account: enabled
> > > >> Cgroup memory controller: enabled
> > > >> Cgroup cpuset: enabled
> > > >>
> > > >> --- Misc ---
> > > >> Veth pair device: enabled
> > > >> Macvlan: enabled
> > > >> Vlan: enabled
> > > >> File capabilities: enabled
> > > >>
> > > >> Note : Before booting a new kernel, you can check its configuration
> > > >> usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
> > > >>
> > > >> Regards,
> > > >> Ajith
> > > >
> > > > 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!
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>



-- 
Király István
+36 209 753 758
LaKing at D250.hu
<http://d250.hu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140630/94aa282b/attachment.html>

More information about the lxc-users mailing list