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

[Michael H. Warfield]

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
the lxc-console connections to the container, which are showing up
on /dev/tty[1-3].  I still don't know why this is, if it's a peculiarity
in the way systemd is starting the getty on /dev/console or if it's some
peculiarity in the way lxc-start is behaving there.  Funny thing is that
I seem to recall the systemd dudes swearing that they were disabling the
"console" when running in a container and yet there I see it systemd -
"Starting Console Getty..."

> Yum also isn't finding any mirrors, but
> that may be a problem local to me.

I think that's because the network isn't starting for some reason.  I'm
looking into that one now.

That one looks to be because we have not installed NetworkMangler (err,
NetworkManager) and the legacy network service is not enabled by
default.  I've got two courses of action I could take on this.

1) I could add NetworkManager to the install packages for probably 17
and up.

2) I could make sure the legacy "network" service is enabled but I'm not
sure if or when they are likely to deprecate that.

My preference at this point is to go with #2 as I think it will be a
bloody code day in a bloody warm place before that service is completely
removed since it's preferred on servers over NetworkManager.  That looks
fairly simple to do.  Just setting a few symbolic links.  I'll work up a
patch for that.  Maybe conditionalize it.

> Will test some more tomorrow.

> Thanks!

> -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/20131004/f31da03f/attachment.pgp>