I suspect because in bionic/artful we're missing resolvconf package, that the systemd-resolved service ends up starting later in boot. The systemd-resolved-update-resolveconf.{service,path} require /sbin/resolvconf to run; this service had a path-based trigger that would get hooked whenever DHCP clients would call resolvconf to kick off a DNS update once config was available.
I suspect that systemd-networkd itself isn't poking DNS service properly after acquiring information.
The dependency loop comes from systemd-resolved using default dependencies which run after when cloud-init.service would run.
This then needs systemd-resolved to specify DefaultDependencies=No and something like network-online.target to require systemd-resolved.
I modified cloud-init.service to include an After=systemd-resolved.service but some other service may require dns, so I feel this is a property of network-online.target.
I suspect because in bionic/artful we're missing resolvconf package, that the systemd-resolved service ends up starting later in boot. The systemd- resolved- update- resolveconf. {service, path} require /sbin/resolvconf to run; this service had a path-based trigger that would get hooked whenever DHCP clients would call resolvconf to kick off a DNS update once config was available.
I suspect that systemd-networkd itself isn't poking DNS service properly after acquiring information.
The dependency loop comes from systemd-resolved using default dependencies which run after when cloud-init.service would run.
This then needs systemd-resolved to specify DefaultDependen cies=No and something like network- online. target to require systemd-resolved.
I modified cloud-init.service to include an After=systemd- resolved. service but some other service may require dns, so I feel this is a property of network- online. target.