touch-packages team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

Scott confirmed on IRC that it works for him on  IRC. So this seems to
be something on my system instead.

I purged (--force-depends) and reinstalled ca-certificates, and now it
curiously works. So that smells like an upgrade issue of ca-
certificates, I'll investigate and see if I can reproduce it.

** Changed in: cloud-utils (Ubuntu Utopic)
       Status: New => Incomplete

** Changed in: cloud-utils (Ubuntu Utopic)
     Assignee: Scott Moser (smoser) => Martin Pitt (pitti)

** Package changed: cloud-utils (Ubuntu Utopic) => ca-certificates
(Ubuntu Utopic)

** Changed in: ca-certificates (Ubuntu Utopic)
   Importance: High => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ca-certificates in Ubuntu.
https://bugs.launchpad.net/bugs/1363832

Title:
  [utopic] fails to build template container -- ubuntu-cloudimg-query
  fails

Status in “ca-certificates” package in Ubuntu:
  Incomplete
Status in “juju-core” package in Ubuntu:
  Invalid
Status in “ca-certificates” source package in Utopic:
  Incomplete
Status in “juju-core” source package in Utopic:
  Invalid

Bug description:
  TL;DR: Utopic's ca-certificates don't cover the cert we are using to
  sign our cloud images and their catalogs, and utopic's wget now fails
  on a cert which can't be validated. This completely breaks ubuntu-
  cloudimg-query and lxc-ubuntu-cloud.

  Original report below:
  --- 

  I tried the "local" provider again on current utopic, and today it
  fails on creating containers:

  - Start from a clean slate: no *juju* containers (I do have some
  containers for other work, though), no ~/.juju, etc. I follow
  https://juju.ubuntu.com/docs/getting-started.html and
  https://juju.ubuntu.com/docs/config-local.html

  - sudo apt install juju-core juju-local
    juju generate-config
    juju switch local

  - As I have $HOME on ecryptfs, I follow the documentation and use a
  separate juju root:

    sudo mkdir /scratch/juju
    sudo chown martin:martin /scratch/juju/

    Now I edit ~/.juju/environments.yaml in the local section to have
  "root-dir: /scratch/juju" and "default-series: trusty".

    I also apply a workaround for bug 1290920:
    lrwxrwxrwx 1 root root 12 Jun 11 21:55 /var/lib/lxc -> /scratch/lxc

  - Now bootstrap, this apparently works well:

  $ juju bootstrap
  uploading tools for series [precise trusty utopic]
  [sudo] password for martin:
  Logging to /scratch/juju/cloud-init-output.log on remote host
  Bootstrapping Juju machine agent
  Starting Juju machine agent (juju-agent-martin-local)

  This took maybe 10 seconds. /scratch/juju/cloud-init-output.log
  contains no "ERROR", and ends with "juju-agent-martin-local
  start/running, process 3997", so this seems fine. But I'll attach the
  log anyway. Note that this did *not* create any extra container; "sudo
  lxc-ls --fancy" does not show me anything new.

  $ juju status
  environment: local
  machines:
    "0":
      agent-state: started
      agent-version: 1.20.5.1
      dns-name: localhost
      instance-id: localhost
      series: utopic
      state-server-member-status: has-vote
  services: {}

  - Now I try to deploy the GUI:

  $ juju deploy juju-gui
  Added charm "cs:trusty/juju-gui-5" to the environment.

  (Returned after ~ 5 s)

  $ juju status
  environment: local
  machines:
    "0":
      agent-state: started
      agent-version: 1.20.5.1
      dns-name: localhost
      instance-id: localhost
      series: utopic
      state-server-member-status: has-vote
    "1":
      agent-state-info: container failed to start
      instance-id: pending
      series: trusty
  services:
    juju-gui:
      charm: cs:trusty/juju-gui-5
      exposed: false
      units:
        juju-gui/0:
          agent-state: pending
          machine: "1"

  This created a new container:
  juju-trusty-lxc-template  STOPPED  -     -     -       NO

  But it is basically empty, except for a new log dir:

  $ find /scratch/lxc/juju-trusty-lxc-template/
  /scratch/lxc/juju-trusty-lxc-template/
  /scratch/lxc/juju-trusty-lxc-template/config
  /scratch/lxc/juju-trusty-lxc-template/rootfs
  /scratch/lxc/juju-trusty-lxc-template/rootfs/var
  /scratch/lxc/juju-trusty-lxc-template/rootfs/var/log
  /scratch/lxc/juju-trusty-lxc-template/rootfs/var/log/juju

  The first error in /scratch/juju/log/machine-0.log is

  2014-09-01 06:36:47 ERROR juju.worker runner.go:218 exited "api":
  unable to connect to "wss://localhost:17070/"

  but it seems to retry and succeed a bit later:

  2014-09-01 06:36:50 INFO juju.state.api apiclient.go:176 connection
  established to "wss://localhost:17070/"

  then it just ends with

  2014-09-01 06:39:19 ERROR juju.container.lxc clonetemplate.go:167 container failed to start: container failed to start
  2014-09-01 06:39:19 ERROR juju.provisioner provisioner_task.go:418 cannot start instance for machine "1": container failed to start

  I'll also attach the full file. So it seems it fails very early on to
  create containers, this doesn't seem very charm specific. But just to
  make sure, I destroyed the juju service and machine (which didn't
  destroy the container, I did that manually) and service, and tried to
  "juju deploy mysql", but with the exact same result.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: juju-local 1.20.5-0ubuntu1
  ProcVersionSignature: Ubuntu 3.16.0-11.16-generic 3.16.1
  Uname: Linux 3.16.0-11-generic x86_64
  ApportVersion: 2.14.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Sep  1 08:23:10 2014
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-02-27 (185 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140224)
  PackageArchitecture: all
  SourcePackage: juju-core
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1363832/+subscriptions