Comment 19 for bug 2008952

I'm also going back to the tabular network state printed out by in cloud-init.service shows: that the primary network interface is still down at this point in boot, which it shouldn't be. cloud-init should be waiting on the presence of link up before starting the cloud-init.service (network boot stage). I'm working on the hypothesis that we are missing an `After=NetworkManager-wait-online.service` which wasn't present in cloud-init because it didn't have to cope with non systemd-networkd managed devices in ubuntu-server installs.

ci-info: | enp0s31f6 | False | . | . | . | 6c:24:08:9e:54:e6 |

Running a couple of tests in a customized Desktop Live iso installer now to confirm

# update per #20. Cloud-init.service can't be after NetworkManager-wait-online.service without introducing a systemd ordering cycle because NetworkManager.service is After=dbus.service which is After=sysinit.target. The only way currently that cloud-init.service can wait until After=NM-wait-online.service is for cloud-init.service to drop it's Before=sysinit.target in desktop live installers (or NetworkManager to grow support for setup prior to dbus.service availability so it can drop the 'After=dbus.service' from systemd unit config)