<div class="gmail_quote">On Sat, Jul 16, 2011 at 8:27 PM, Michael H. Warfield <span dir="ltr"><<a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Fri, 2011-07-15 at 20:17 +0300, Ramez Hanna wrote:<br>
<br>
<< Big Snip >><br>
<div class="im"><br>
> > > thanks a lot for the detailed answer<br>
> > > by the way have you been succesfull in starting a f15 container on your<br>
> > f15?<br>
<br>
</div>I now have an F15 container working.<br>
<div class="im"><br>
> > > I have been debuggin for 2 hours now<br>
> > > when i start f15 container it screws my host by interfering with my<br>
> > hosts's<br>
> > > systemd which somehow doesn't make sense<br>
> > > and when i use systemd-nspawn i get a bunch of errors and the system<br>
> > doesn't<br>
> > > finish starting<br>
> > > here is a paste of systemd log from systemd-nspawn session<br>
> > > <a href="http://pastie.org/2218625" target="_blank">http://pastie.org/2218625</a><br>
> ><br>
> > I haven't tried it yet.  Will see what I can do.<br>
> ><br>
> > Couple of quick questions.<br>
> ><br>
> > 1) You say it screws your host if you don't uses nospawn.  What happens?<br>
<br>
> host console is not useable, random issues around missing characters when i<br>
> type<br>
> unable to login on other terminals because i cannot type<br>
> and i see so many systemd logs on the console<br>
<br>
</div>I have a very strong suspicion that systemd is not going to be<br>
compatible with running in a container because it wants to set up and<br>
managed cgroups in the container which it can not do.<br>
<br>
When I try to start it with systemd, the first process doesn't even seem<br>
to come up (number of tasks is 0) and then the host can not remove the<br>
container even after I've done an lxc-stop on it.  But that's when I'm<br>
logged in and running lxc-start from an ssh terminal Window.  If I start<br>
it from a real ttyX console then I get all sorts of startup messages<br>
from the container and the consoles are hosed up like the console in the<br>
container has gotten crosswise with the console in the host.  Things try<br>
to initialize but all sorts of things time out and eventually I have to<br>
reset the host with an Magic SysRq sequence.<br>
<br>
Gave up on systemd.<br>
<div class="im"><br>
> > 2) Have you disabled the sys_admin cap by dropping it in that container?<br>
> > I find that causes me all sorts of grief.<br>
> ><br>
> i will try that<br>
<br>
</div>Don't.  It wouldn't do any good and causes lots of other problems (for<br>
me at least).<br>
<div class="im"><br>
> > 3) Was this a fresh template build or did you upgrade an F14 machine to<br>
> > F15 (I was going to use "yum --releasever=15 distro-sync" in one of my<br>
> > running F14 containers).<br>
<br>
> yes fresh install<br>
<br>
</div>Here's what I've done and now gotten an F15 container to work.<br>
<br>
I started out with an F14 container and upgraded it to F15 using the<br>
"yum --releasever=15 distro-sync" method.  I was able to reproduce your<br>
problems above and thought there may be some conflicts over cgroups so I<br>
decided to disable systemd.<br>
<br>
If it's not present (it wasn't for me) install upstart into the<br>
container from the host using "yum --installroot={your VM root}<br>
upstart".<br>
<br>
Next cd to {your VM root}/sbin and rm init (which is symlinked<br>
to ../bin/systemd) and symlink it to upstart (which is in sbin).<br>
<br>
This got me almost there.  The machine was starting but I was having<br>
your funky console problem and I realized (largely because I'm working<br>
on other related problems) that it was the ptmx device causing this.  It<br>
was mapping incorrectly.<br>
<br>
So, cd to {your VM root}/dev and rm ptmx if it's a hard device and not a<br>
symlink.  Then symlink pts/ptmx to ptmx.  If you started with some sort<br>
of template, this may already be done and you may not run into this<br>
problem at all.<br>
<br>
Now you should be able to fire your F15 container up.<br>
<br>
Also find the lines in /etc/init.d/halt that remount file systems ro or<br>
you'll screw your /dev/pts fs in the host when you shut that container<br>
down or reboot it (and, no, newinstance is not helping with that<br>
problem).<br>
<div><div></div><div class="h5"><br>
Regards,<br>
Mike<br>
--<br>
Michael H. Warfield (AI4NB) | <a href="tel:%28770%29%20985-6132" value="+17709856132">(770) 985-6132</a> |  mhw@WittsEnd.com<br>
   /\/\|=mhw=|\/\/          | <a href="tel:%28678%29%20463-0932" value="+16784630932">(678) 463-0932</a> |  <a href="http://www.wittsend.com/mhw/" target="_blank">http://www.wittsend.com/mhw/</a><br>
   NIC whois: MHW9          | An optimist believes we live in the best of all<br>
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!<br>
</div></div></blockquote></div><br>it is very clear to me that systemd is interfering with the host's systemd<br>your solution of running f15 is not much different than running a f14 container (as systemd is the major diff)<br>
systemd-nspawn can start systemd inside a "light weight" container<br>i think the problem is related to the fact that when lxc starts teh cgroup is on the root of the tree<br>while it should have been under the user's tree<br>
<br>maybe serge can say somethiing about this<br>