[Lxc-users] [lxc-devel] [GIT] lxc branch, master, updated. 7f99e339363d9f005c9386f60a1d8c0953c85053
Michael H. Warfield
mhw at WittsEnd.com
Fri Nov 2 21:45:40 UTC 2012
On Thu, 2012-11-01 at 20:15 -0400, Michael H. Warfield wrote:
> On Thu, 2012-11-01 at 19:17 -0400, Michael H. Warfield wrote:
> > On Thu, 2012-11-01 at 23:28 +0100, Serge Hallyn wrote:
> > > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > > On Thu, 2012-11-01 at 22:44 +0100, Serge Hallyn wrote:
> > > > > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > > > > On Thu, 2012-11-01 at 21:20 +0100, Daniel Baumann wrote:
> > > > > > > On 11/01/2012 09:08 PM, Michael H. Warfield wrote:
> > > > > > > > I know, I KNOW this is an 11th hour request. Can we please get Serge's
> > > > > > > > autodev stuff into this release? Please?
> > > > > >
> > > > > > > release early, release often?
> > > > > >
> > > > > > > just release current git as 0.8.0 now, and the one with the autofoo as
> > > > > > > 0.8.1 soon after that?
> > > > > >
> > > > > > That would be ideal but we've been sitting at 0.8.0rc2 for something
> > > > > > like 3-1/2 months now. I know Daniel (the other Daniel, the Daniel) has
> > > > > > been incredibly busy. I have no objection to getting this out the door
> > > > > > as 0.8.0 with a fast bump to 0.8.1 for the systemd stuff, but another
> > > > > > several months is not good. Can we get this fast bump? We'll be
> > > > > > staring Fedora 18 in the face by then. The working versions of Fedora
> > > > > > are no longer in support and we've got more distros adopting systemd.
> > > >
> > > > > I think this will end up slated for 0.9.0 (which we're hoping will be
> > > > > soon), but in any case I went ahead and created a branch at
> > > > > git://github.com/hallyn/lxc called upstream.nov1.2012.autodev, with
> > > > > an autodev patch on top of Daniel's latest push.
> > > >
> > > > > I quickly tried my hand at fixing the error you had with /dev/ttyN. I
> > > > > haven't tested that bit. I will not be able to be online at all from
> > > > > now until weekend or monday, so if it needs more tweaks please feel
> > > > > free to 'just fix it'.
> > > >
> > > > Problem. Works for the systemd containers but not for my older
> > > > containers. I get this...
> > > >
> > > > [root at forest Plover]# cat 2012-10-30-18:17:46.log
> > > > lxc-start 1351635466.998 ERROR lxc_conf - Operation not permitted - error 1 creating /usr/lib64/lxc/rootfs/dev/tty6
> > > >
> > > > lxc-start 1351635466.999 ERROR lxc_conf - failed to setup the ttys for 'Plover'
> > > > lxc-start 1351635466.999 ERROR lxc_start - failed to setup the container
> > > > lxc-start 1351635466.999 ERROR lxc_sync - invalid sequence number 1. expected 2
> > > > lxc-start 1351635466.999 ERROR lxc_start - failed to spawn 'Plover'
> > > >
> > > > Alcove (the systemd container) was the first one started so it may be an
> > > > ordinal thing or it may be a systemd thing. But it's a problem.
> > > \
> > > Hm, perhaps the container doesn't have mknod?
>
> > They all should have, but I will investigate. Those devices would have
> > existed in the static file system with /dev. Could it be a problem with
> > the device already existing in the /dev directory?
>
> Ok... Now this is just bloody weird. I do not understand this.
>
> Yes the containers come up. But...
>
> Here's what shows up in the detached container's log...
>
> [root at forest Audience]# cat 2012-10-30-18:52:41.log
> lxc-start 1351637562.011 ERROR lxc_conf - Operation not permitted - error creating /usr/lib64/lxc/rootfs/dev/tty6
> Now wait a minute... What about 1, 2, 3, 4, and 5??? They succeeded
> but 6 failed? How does that make any sense. In the container...
> crw-rw-rw- 1 root root 5, 0 Apr 13 2006 tty
> crw--w---- 1 root tty 136, 16 Oct 30 2012 tty1
> crw--w---- 1 root tty 136, 17 Oct 30 2012 tty2
> crw--w---- 1 root tty 136, 18 Oct 30 2012 tty3
> crw--w---- 1 root tty 136, 19 Oct 30 2012 tty4
> crw--w---- 1 root tty 136, 20 Oct 30 2012 tty5
> crw--w---- 1 root tty 136, 21 Oct 30 2012 tty6
> Ok... That's probably from a couple of days ago. But no error messages
> for the others and they are not "freshly made" either... That was a
> CentOS 5 container.
> Trying it with another Fedora container but removed the tty? entries.
> No errors. Hmmm... Wait... Another problem... Container "Plover"...
> [mhw at plover ~]$ who
> mhw pts/9 2012-10-30 19:47 (forest.ip6.wittsend.com)
> [mhw at plover ~]$ sudo -s
> sudo: sorry, you must have a tty to run sudo
> What?
Ok... The problem with the container "plover" appears to have been an
error on my part. I think I cleaned out too many tty devices.
Carefully only removed tty? devices from the static /dev in that
container and started it up...
[root at forest Plover]# cat 2012-10-31-06:41:37.log
lxc-start 1351680097.900 ERROR lxc_conf - Operation not permitted - error creating /usr/lib64/lxc/rootfs/dev/tty6
Still got the error creating /dev/tty6 but not 1-5.
But wait. In the container itself...
[mhw at canyon mhw]$ ssh plover.ip6.wittsend.com
Last login: Tue Oct 30 18:40:12 2012 from canyon.ip6.wittsend.com
[mhw at plover ~]$ sudo -s
[root at plover mhw]# ls -l /dev/tty?
crw-------. 1 root root 136, 36 Oct 31 06:41 /dev/tty1
crw-------. 1 root root 136, 37 Oct 31 06:41 /dev/tty2
crw-------. 1 root root 136, 38 Oct 31 06:41 /dev/tty3
crw-------. 1 root root 136, 39 Oct 31 06:41 /dev/tty4
crw-------. 1 root root 136, 40 Oct 31 06:41 /dev/tty5
crw-------. 1 root root 136, 41 Oct 31 06:41 /dev/tty6
So it gave an error but did actual work.
I've got this narrowed down... If "devtty" is defined you do one thing
and, if not, you drop into the autodev logic. Is that correct? If I
use devtty, then the INFO dump says "0 ttys created and, in fact, none
are, so I guess I don't know how to use that parameter.
What I don't understand is why only the last one is generating the
error. Condition is that lxc.devtty = <NULL> and lxc.autodev = <NULL>.
> Sigh...
> No problem in Alcove (F17):
>
> [mhw at canyon mhw]$ ssh alcove.ip6.wittsend.com
> Last login: Wed Oct 31 01:51:39 2012 from canyon.ip6.wittsend.com
> [mhw at alcove ~]$ sudo -s
> [root at alcove mhw]#
>
> Back to Audience (CentOS 5) and removed /dev/tty?:
>
> No errors as seen before.
>
> Successfully created tty1-6.
>
> Sudo works.
>
> WTH?
>
> There's something wrong here. Audience and Plover do not have autodev
> enabled. Why has this changed? Shouldn't that be under the autodev
> switch as well?
>
> > > I've updated the git tree to not fail when mknod is denied. It should
> > > just spit out an error, and presumably another one when it next tries
> > > to bind mount the pty onto it, but that's ok.
>
> > > Does git://github.com/hallyn/lxc#upstream.nov1.2012.autodev work better
> > > now? (I'm logging off now, so if not I probably won't know for some time)
> >
> > Working now. All containers are up.
> >
> > When you get back to it, dude! Many thanks!
> >
> > > -serge
> >
> > > ------------------------------------------------------------------------------
> > > LogMeIn Central: Instant, anywhere, Remote PC access and management.
> > > Stay in control, update software, and manage PCs from one command center
> > > Diagnose problems and improve visibility into emerging IT issues
> > > Automate, monitor and manage. Do more in less time with Central
> > > http://p.sf.net/sfu/logmein12331_d2d
> > > _______________________________________________
> > > Lxc-users mailing list
> > > Lxc-users at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/lxc-users
> >
> > 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-users/attachments/20121102/8c9ab62e/attachment.pgp>
More information about the lxc-users
mailing list