Quoting Michael H. Warfield (m...@wittsend.com):
> On Fri, 2013-10-04 at 10:56 -0500, Serge Hallyn wrote:
> > Quoting Michael H. Warfield (m...@wittsend.com):
> > > Hey Serge,
> > >
> > > On Wed, 2013-10-02 at 23:39 -0500, Serge Hallyn wrote:
> > > > Quoting Michael H. Warfield (m...@wittsend.com):
> > > > > + mount -o loop ../LiveOS/squashfs.img squashfs
> > >
> > > > Heh, this is unfortunate - since I test things inside containers, now I
> > > > have to face the loop device in containers issue :)
> > >
> > > > For now I just added b 7:0 to my devices whitelist and loosened the
> > > > apparmor policy. Fedora build did its thing. Then I removed those
> > > > exceptions.
> > > >
> > > > I did have to remove the devices whitelist entries for 4:0 and 4:1.
> > >
> > > I swear, I thought you meant you had to remove them in the container
> > > config of the Ubuntu container you were running this in, just as you had
> > > to add the b 7:0 for the loop device. :-P Oh well.
> > >
> > > > They are for /dev/tty{0,1} - the real ones, which we don't use
> > > > in containers. Since the ubuntu container in which I was testing
> > > > didn't have that, I couldn't grant it to the fedora container, but
> > > > it doesn't need it.
> > >
> > > > Other than that, it looks good!
> > >
> > > > There is a weird glitch, when i first start the container, i type
> > > > in username root, then have to hit return again before it shows
> > > > me the password prompt. It doesn't accept the password. Second
> > > > login attempt works fine.
> > >
> > > I've looked at this some more and it's only happening on the console
> > > device that is connected with lxc-start. It's not happening with any of
>
> > That's interesting. Note that when I start an ubuntu container in a
> > private user namespace, the lxc-start console also acts differently
> > from the other consoles. The shell says there's no job control, and
> > sudo refuses to run.
>
> Yeah, I'm seeing the same problem you're seeing on a Fedora host with
> all the various containers I have running (Fedora (13,14,17,18,19),
> CentOS (5,6), Oracle, OpenSuse, Ubuntu), were we have this weird
> behavior of the lxc-start console. It's not dependent on the host
> (Ubuntu or Fedora) and it doesn't really seem to be dependent on the
> container distro. Not sure what the deal is there. Can't find any
> different from "stty -a" for anything...
I forget the details, but (if you're looking into it right now) there
*was* something which was different - maybe it was ownership of
something under /proc/pid/fd for the getty or lxc init.
(I'll be looking into it in a few weeks when hopefully i'm back to
unprivileged container creation and startup)
-serge
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
