[lxc-devel] [PATCH 1/1] templates/lxc-fedora Rework for distro independence.

[Serge Hallyn]

Quoting Michael H. Warfield (mhw at WittsEnd.com):
> On Fri, 2013-10-04 at 10:56 -0500, Serge Hallyn wrote: 
> > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > Hey Serge,
> > > 
> > > On Wed, 2013-10-02 at 23:39 -0500, Serge Hallyn wrote: 
> > > > Quoting Michael H. Warfield (mhw at 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