Comment 17 for bug 1843634

summary: ensuring cloud-init.service runs after wicked and avoid updating resolv.conf without dns values in network_config will fix this issue.

I'm confident that if cloud-init.service runs after wicked.service and the proposed fixed attached to this bug will resolve this issue. I just wanted to make sure we weren't missing a scenario in reasoning behind wicked running before.

> or it could be that a loop is created. Although the creation of a loop between
> "After=dbus.service" and "After=wicked.service" is hard to imagine, but it will have
> to be tested.

That could be an issue; if so, you likely can replace dbus.service with dbus.socket; as this allows the services to initiate connections to dbus. This is usually sufficient for a dependent service to get going.

As Moustafa pointed out, we need a better patch (which I've proposed and linked to this bug above) which checks if the network config has any dns information before attempting to update resolv.conf; it appears that in some SLES images they contain a resolv.conf template which is used by 'netconfig' and the cloud-init comment added to the file causes netconfig to not update resolv.conf, meaning no DNS at all.