On Sat, Jan 25, 2014 at 11:17 PM, Curtis Hovey-Canonical < cur...@canonical.com> wrote:
> Hi Andrew. > > On Fri, Jan 24, 2014 at 8:40 PM, Andrew Wilkins > <andrew.wilk...@canonical.com> wrote: > > This looks a lot like a Trusty-specific issue to me, and nothing to do > with > > sudo. When did CI move to Trusty? > > CI is on Precise. I am on trusty. > Okay. > CI has not passed local upgrade to 1.17.1 and deploy with 1.17.1 tests > since lp:juju-core r2248. The next revision tested was 2253 (a lot of > revs landed while CI was retesting intermittent failures) > > CI sees this on when is uses 1.17.1 juju to boostrap: > > juju --debug bootstrap -e local --constraints mem=2G 2>&1 | tee > bootstrap.log > 2014-01-25 14:51:09 DEBUG juju.environs.configstore disk.go:77 Making > /var/lib/jenkins/juju-ci/environments > 2014-01-25 14:51:09 DEBUG juju.environs.configstore disk.go:67 Making > /var/lib/jenkins/juju-ci/environments/local.jenv owned by 1000:1000 > 2014-01-25 14:51:09 ERROR juju.cmd supercommand.go:294 cannot create > new info for environment "local": chown > /var/lib/jenkins/juju-ci/environments/local.jenv: operation not > permitted > This looks like it's still running under sudo. Is that the case? (I see it's not in the command line, but is this a script that is run under sudo?) The "Making ... owned by 1000:1000" line shouldn't be there. I suspect the moving back in forth between juju 1.17.1 and juju 1.16.5 > is the reason that juju 1.16.5 can no long bootstrap. Juju and lxc are > left in a bad state after attempting to use 1.17.1: > > juju --debug bootstrap -e local --constraints mem=2G 2>&1 | tee > bootstrap.log > 2014-01-25 14:59:53 ERROR juju.state open.go:93 TLS handshake failed: > x509: certificate signed by unknown authority > 2014-01-25 14:59:54 ERROR juju.agent agent.go:470 failed to initialize > state: no reachable servers > 2014-01-25 14:59:54 ERROR juju supercommand.go:282 no reachable servers > > > Trusty no longer has the /etc/lxc/auto directory, and instead the LXC > > container config file has an attribute that says the container should be > > auto-started with the machine. Jesse has an in-progress CL that addresses > > this by checking if the auto directory exists before attempting to create > > the auto-start symlink. > > Great. > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
