current base cloud-image does not have resolvconf, but has ifupdown. The following happens:
1) cloud-init starts 2) picks ifupdown renderer 3) renders eni 4) which uses auto dhcp 5) which calls dhclient 6) because there is no resolvconf installed, default make_resolve_conf function is used which is internal to isc-dhcp 7) /etc/resolv.conf stops being a symlink and is a regular file 8) NM starts, notices that /etc/resolv.conf is a regular file and thus is not managed by resolvconf/resolved 9) NM decides to manage /etc/resolv.conf, poorly This does kind of mean that on upgrades, if one removes resolvconf without removing ifupdown things go pear shaped. One option is to re-introduce ifupdown dependency on resolvconf. Another option is to ship isc-dhclient (dhcp-enter-hook) in systemd to override make_resolve_conf function. I've started writing such a hook which uses busctl to feed per-link dhcp info to resolved. However, that has it's own problems. dbus is not started early enough, and there is no private socket to resolved, meaning that updates are getting lost on boot when [email protected] units are udev triggered on hotplug. Currently working on preserving state in /run and replaying isc-dhclient gathered settings to resolved. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716833 Title: NM manages /etc/resolv.conf directly in artful after removal of resolvconf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716833/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
