Comment 11 for bug 1353008

Removing duplicate status. After understanding more of the failure mode, it's certainly distinct from 1345433. The problem here is the initial log message printed by "cloud-init init-local" is failing with a symlink error.

Traceback (most recent call last):
  File "/usr/bin/cloud-init", line 618, in <module>
    sys.exit(main())
  File "/usr/bin/cloud-init", line 614, in main
    get_uptime=True, func=functor, args=(name, args))
  File "/usr/lib/python2.7/dist-packages/cloudinit/util.py", line 1875, in log_time
    ret = func(*args, **kwargs)
  File "/usr/bin/cloud-init", line 491, in status_wrapper
    force=True)
  File "/usr/lib/python2.7/dist-packages/cloudinit/util.py", line 1402, in sym_link
    os.symlink(source, link)
OSError: [Errno 2] No such file or directory

Aug 22 13:55:52 juju-trusty-lxc-template [CLOUDINIT] util.py[DEBUG]: Creating symbolic link from '/run/cloud-init/result.json' => '../../var/lib/cloud/data/result.json'

Thus it's hard to see in the log what is going wrong.

  - "cloud-init init-local" does the waiting for network bit.
  - "cloud-init init" expects the network devices to be up

Two issues:

1) Why is the symlink failing?

From the error message (No such file or directory), the only ways I've gotten it to repeat is if the directory where the link is requested to be placed does not exist, or if using relative paths, the directory cannot be calculated -- i.e., dirname(source) doesn't exist.

2) Why doesn't cloud-init-init block on success of cloud-init, and not just completion of it?

Perhaps this is a limitation of the upstart job chain. I'm not familiar enough with that to speak to it. Or, perhaps it's by design.

I'll add more to the bug debugging wise as I find it.