After installing the f24 beta, and uninstalling NetworkManager, resolv.conf is left in a busted state. This seems unintentional: # file /etc/resolv.conf /etc/resolv.conf: broken symbolic link to /var/run/NetworkManager/resolv.conf
When stopping NetworkManager, interfaces are left up. Likewise, the symbolic link /etc/resolv.conf is not changed. This allows you to restart NetworkManager without loosing connectivity. you encounter the same issue if you do: systemctl mask NetworkManager && reboot # ups, nobody took over resolv.conf and it points to nowhere. So I don't think that the answer to this bug is that RPM should reset resolv.conf on package removal. Also, I don't see how NetworkManager.rpm could mangle /etc/resolv.conf on package removal, because RPM wouldn't know which better DNS configuration to use instead. An empty resolv.conf isn't useful either. Also, mangle /etc/resolv.conf on package removal breaks: systemctl stop NetworkManager # still connected dnf remove NetworkManager # ups, RPM broke resolv.conf systemctl start other-networking-daemon.service # resolv.conf is good again. # Or at least, it's up to other-networking-daemon. If you stop NetworkManager for good and want to uninstall it, it is up to you to configure your network and resolv.conf (or setup another component to do that). I don't see how this could be fixed.
I did. I set up network (chkconfig network on) and rebooted. After which the symlink is still broken.
In the case where the sysinit network scripts are enabled, they could fix the /etc/resolv.conf file if it's a broken symlink. One simple change would work at least in the case where DNS1 or DNS2 are set in the configuration. This change would be to modify /etc/sysconfig/network-scripts/ifup-post to replace a broken symbolic link with an empty file around line 77, where it currently backs up resolv.conf. For example: # backup resolv.conf cp -af /etc/resolv.conf /etc/resolv.conf.save # replace a broken symbolic link with an empty file if [ -h /etc/resolv.conf -a ! -e /etc/resolv.conf ]; then rm -f /etc/resolv.conf touch /etc/resolv.conf fi If NetworkManager creates a backup of /etc/resolv.conf when it overwrites it with a symlink, then perhaps this could be extended to attempt to restore the backup, but I personally believe the above fix is safer. Anyway, I would love to see this fix to /etc/sysconfig/network-scripts-ifup-post.
I just created bug 1401154 in the initscripts component to describe this workaround.
What's this got to do with system-config-network?
Nils, it shouldn't be assigned to system-config-network. Sorry for that!
For now, I am closing this as NOTABUG. It just means, if you change your networking configuration, you can end up with broken resolv.conf if you do it wrong. If you mess up your networking configuration, all kind of things can happen. It's unclear to me what NetworkManager should do to prevent that. If a user does: $ systemctl mask NetworkManager $ reboot the same issue happens. But NetworkManager isn't even aware that it's going to be disabled on reboot. And the NetworkManager RPM was not removed either. It's really just user configuration. The user must configure a replacement for NetworkManager. Whatever that means in detail is up to the user. If you have a *concrete* suggestion what NetworkManager should do, please reopen. Thanks.
The following are sufficient to trigger this issue: # dnf erase NetworkManager # chkconfig network on # reboot To my view, I have just configured a replacement: network. Network relies on this symlink not being dead - that is, it wants to write to a file accessible by pathname /etc/resolv.conf, which is normal. In the worst case, on removal, NetworkManager should absolutely fix this symlink. The error cases from not fixing this symlink are utterly unintuitive as well; no one expects a broken symlink there. If you prefer this to be worked around in network or initscripts that's fine with me too, but right now every component says they can't fix it, and so the bug remains.
Agreed. There should be some approved way to disable NetworkManager that results in a working system.
marking this as duplicate. Please follow up at bug 1367551 *** This bug has been marked as a duplicate of bug 1367551 ***