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

[Michael H. Warfield]

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...

> So there appears to be *something* that is happening differently
> there.  It could be as simple as the distro init is mucking with the
> console in a way it shouldn't, or setsid() is doing something...
> But it would be great if we could get to the bottom of it.

If it's the distro init, all of them are doing it and I think I have a
gmix of sysv init, upstart, and systemd.

BTW...  I have all those containers (17 of them) running with autodev =
1 with the devtmpfs patch and they're all running very happily.  I
probably won't have that patch posted before next week but I'm pleased
with how it's behaving so far.  I had to build my OpenSuse container on
an OpenSuse host and transport it over but it's running happy that way
too.  Only ones I haven't tested yet are Alt and Arch.

> -serge

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20131008/4ba44066/attachment.pgp>