Giving the working note what I'm doing currently: In order to analyze the issue, I tried to remove the /etc/resolv.conf in the normal mode and traced the syslog if any systemd service restored the file. What I observed is NM will go through this line of writing DNS, and reported the warning from calling /etc/resolvconf/update.d/libc:
<info> [1516604239.0578] dns-mgr: Writing DNS information to /sbin/resolvconf warning "/etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf" I'm thinking the /etc/resolv.conf will be dynamically recreated, and then NM moved on to finish its service (so NM is able to keep alive). However, under the recovery mode, the NM can't normally start its service and exit due to catch the signal SIGTERM (not sure if it's related to nm_dispatcher). So seems like we have two problems here: 1. why does NM fail to start 2. why does NM not try to call /etc/resolvconf/update.d/libc to restore the file in the recovery mode -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1682637 Title: during recovery mode, enable network failed due to /etc/resolv.conf not being present To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1682637/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
