[00:00] <bahamat> The error was something like `mounts.0.4`, which I take it to mean they are indexed starting with 0 not 1
[00:00] <bahamat> Ok, so that cloud-config works now, having fixed those errors.
[00:01] <bahamat> The instance does reboot, and maybe that's incidentally getting it to work.
[00:01] <minimal> it might be counted from 0 but the 5th field is still the 5th field whether it is called field "4" or field "5" ;-)
[00:01] <bahamat> Fair enough.
[00:02] <minimal> YAML tried to be "smart" about the types of values which is why sometimes values need to be quoted to stop it making incorrect decisions ;-)
[00:08] <bahamat> Alright, thanks for the help everyone. I'm very glad that I got this working, and that the only thing wrong was my own typos.
[00:09] <bahamat> Oh, one more question. Does runcmd run after packages?
[00:26] <minimal> not in the default config, no
[00:26] <minimal> runcmd runs in the "config" state and packages runs in "final" stage - this is defined in /etc/cloud/cloud.cfg
[07:45] <xplora> This  'cloud-init status --wait'  is running forever,  following the lquick-start tutorial with lxd. What I am missing?
[11:12] <masber> hi, I stumped into a server with a cloud-init configuration, for some reason the IPs are not configured as they should, I checked a bit and I can se the cloud-init templates and the values under `/set/cloud`, the values seems to have the right IP I want the machine to have but when I run `$ cloud-init init` the IPs are not configured, any idea why?
[13:44] <blackboxsw> xplora: that means that cloud-init is blocking on one of the boot stages not running yet. `cloud-init status --format=yaml` without the `--wait` should provide more context on the boot stages (init-local, init, modules-config and modules-final) and whether they have all finished. I'm presuming one of those four has not run yet for some reason. 
[13:53] <blackboxsw> masber, to see what cloud-init thinks it saw for network config you can check contents of /run/cloud-init/network-data.json. Also `grep -A 6 "Applying network config" /var/log/cloud-init.log` could give you a good hint about what cloud-init did when it found network configuration.  Note, that if configuration containing `network: {config: disabled}` exists in /etc/cloud/cloud.cfg.d/* then cloud-init won't write net cfg
[13:54] <blackboxsw> https://cloudinit.readthedocs.io/en/latest/reference/network-config.html#disabling-network-configuration
[19:03] <xplora> Thank you, blackboxsw. When I ran "systemctl --failed", I got these: snap.lxd.activate.service  not-found  failed failed  snap.lxd.activate.service. It is like the problem is "snap.lxd.activate.service"