Quoting Michael H. Warfield (m...@wittsend.com): > Serge, > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote: > > Quoting Serge Hallyn (serge.hal...@canonical.com): > > > Quoting Michael H. Warfield (m...@wittsend.com): > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote: > > > > > Quoting Michael H. Warfield (m...@wittsend.com): > > > > > > Serge, > > > > > > > > > > > > > > ... > > > > > > > > > > Short of building a custom systemd, I don't know how to fix that > > > > > > problem > > > > > > and I suspect this OP is going to run into this same thing > > > > > > (container > > > > > > taking over host's console) and might explain some of what he's > > > > > > seeing. > > > > > > Several of these look like they could cause problems (like /dev/pts > > > > > > in > > > > > > there). I've really reached an impasse at getting systemd (at least > > > > > > Fedora 16 and 17) to work in a container without screwing up the > > > > > > host. > > > > > > Prohibiting mounts entirely in the container might work but I > > > > > > suspect > > > > > > (having read some systemd error messages) systemd is going to have > > > > > > some > > > > > > serious heartburn there. > > > > > > > > > > > > Thoughts? > > > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the > > > > > container should work, i.e. systemd was not going to fail as a result. > > > > > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list > > > > from my post to the systemd-devel list. Looks like they have a > > > > mechanism in place to do this... > > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface > > > > > > Saw the email, haven't yet read the page, thanks. > > > So based on that page, what we do (set 'container=lxc') should already be > > sufficient. > > Thanks to the dude asking a libvirt-lxc question on the list, I was let > to a page that let to a page that led to some discussion you were having > back in March with Ramez Hanna on this very subject, "Re: [Lxc-users] > f16 update"... > > http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg03263.html
thanks, I knew we'd been over some of this, but couldn't find my logs of it. > This would look to be the kludge to make a workaround for this problem, > I'm just not sure how to make it happen. Given you already found the > answer that the device for /dev has to be different than the device for > the parent, what should we do. > > I tried this in the config... > > lxc.mount.entry=tmpfs /var/lib/lxc/private/Alcove/dev tmpfs defaults 0 0 How about just a devtmpfs? We actually now do this by default (as of very recently) in ubuntu by adding devtmpfs dev devtmpfs defaults 0 0 to /var/lib/lxc/$container/fstab Or, are you on an older kernel which doesn't have devtmpfs? > Maybe I got that entry wrong but it didn't do anything (and would have > resulted in other failures later as I found out). A similar mount entry > for a shared filesystem worked just fine. > > Trying an empty /dev fails because it's missing EVERYTHING so starting > out with a tmpfs without populating it is not the answer either. > > The correct answer would be to mount a tmpfs file system and then > populate it before firing up systemd in the container. I don't see how > to do that. A bind mount isn't going to work either, for the reasons > you stated in that thread, it ends up on the same device. Having > another mount on another real device would be a workaround but a really > bad kludge that would complicate things immensely. > > > -serge > > > -- > Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
