resolvconf not correctly configured after update from 17.04 to 17.10

Bug #1725840 reported by Artur Schmitt on 2017-10-21
94
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Cubic
Undecided
Unassigned
resolvconf (Ubuntu)
Undecided
Dimitri John Ledkov

Bug Description

After having updated my laptop from Ubuntu 17.04 to 17.10, the DNS lookup on my wireless network connection did not work any more.

As it seems, the file /etc/resolv.conf was static and contained wrong data assigned by the NetworkManager. When I changed the file content manually to

  nameserver 127.0.0.53

DNS lookup worked fine. After reboot, however, I had to repeat this operation since NetworkManager seems to have replaced the file content.

Finally, I found a solution. Running

sudo dpkg-reconfigure resolvconf

the file /etc/resolv.conf was replaced by the link

/etc/resolv.conf -> ../run/resolvconf/resolv.conf

Now, the wireless network seems to work properly.

Hence, there must be some kind of bug during the update process from Ubuntu 17.04 to 17.10 that impedes resolvconf to be configured properly.

Best regards,

Artur

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: resolvconf 1.79ubuntu8
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sat Oct 21 23:17:38 2017
InstallationDate: Installed on 2013-10-18 (1463 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
PackageArchitecture: all
SourcePackage: resolvconf
UpgradeStatus: Upgraded to artful on 2017-10-19 (1 days ago)

Artur Schmitt (arturschmitt) wrote :
Steve Langasek (vorlon) wrote :

Please attach your upgrade logs from /var/log/dist-upgrade to help us try to see what has happened on your system.

Both before and after the upgrade, /etc/resolv.conf should be a symlink to /run/resolvconf/resolv.conf. If something has replaced that with a file, we would need to figure out what that is. It probably wasn't resolvconf itself.

Changed in resolvconf (Ubuntu):
status: New → Incomplete
Artur Schmitt (arturschmitt) wrote :
Steve Langasek (vorlon) wrote :

Preparando para desempaquetar .../013-resolvconf_1.79ubuntu4_all.deb ...
Desempaquetando resolvconf (1.79ubuntu4) sobre (1.79ubuntu1) ...

This shows an upgrade from 16.10 to 17.04, not an upgrade from 17.04 to 17.10. Do you have a later log file available?

Artur Schmitt (arturschmitt) wrote :

Sorry for the mistake.

Steve Langasek (vorlon) wrote :

Thanks. This log shows the correct upgrade, but unfortunately it doesn't show any obvious explanation for why /etc/resolv.conf was replaced.

I'll set this back to new, but I guess we aren't going to make forward progress on understanding what happened without some further information.

Changed in resolvconf (Ubuntu):
status: Incomplete → New
Artur Schmitt (arturschmitt) wrote :

If you need further information, please let me know.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in resolvconf (Ubuntu):
status: New → Confirmed
Matteo Dell'Amico (della) wrote :

Same bug for me: /etc/resolv.conf was pointing to /run/NetworkManager/resolv.conf rather than ../run/resolvconf/resolv.conf, as fixed by dpkg-reconfigure resolvconf.

Bug also confirmed by a bunch of other people: see https://askubuntu.com/questions/966870/dns-not-working-after-upgrade-17-04-to-17-10/967341 .

On Sat, Nov 04, 2017 at 06:55:17AM -0000, Matteo Dell'Amico wrote:
> Same bug for me: /etc/resolv.conf was pointing to
> /run/NetworkManager/resolv.conf rather than
> ../run/resolvconf/resolv.conf, as fixed by dpkg-reconfigure resolvconf.

> Bug also confirmed by a bunch of other people: see
> https://askubuntu.com/questions/966870/dns-not-working-after-
> upgrade-17-04-to-17-10/967341 .

Unfortunately this is the sort of problem that is very difficult to debug
after the fact, particularly as the kinds of changes users make to try to
resolve the problem for themselves tend to erase necessary clues.

If someone has /etc/resolv.conf as a symlink to
/run/NetworkManager/resolv.conf, it would be helpful to know the timestamp
of that symlink, which we could then correlate with package upgrade logs.

I do have the same issue after upgrade from 17.4-17.10. So do we have a FIX !!!

Danni Uptlen (ydrol) wrote :

I have this same issue on a clean install of xubuntu 17.10. My biggest issue is that it seems to return after reboot (has reoccurred twice now, i assume after applying updates or something as I have restarted more than twice). I have previously been doing the following to fix:
sudo rm /etc/resolv.conf
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf
systemctl restart resolvconf

I have a backup of the original resolv.conf (mv resolv.conf resolv.conf.old).

Steve Langasek (vorlon) wrote :

Danni, this is useful information and gives the best hope of being able to debug the problem. Was your original resolv.conf a symlink or a real file? Can you attach it to this bug report?

Can you also paste the output of 'dpkg -S /etc/NetworkManager' on your system?

Daniel (dmeltzer) wrote :

Hello,

Was just bitten by this as well. etc/resolv.conf was pointing at 127.0.1.1.

hydrogen@Bliss:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 33 May 24 2016 /etc/resolv.conf -> ../run/NetworkManager/resolv.conf

hydrogen@Bliss:~$ dpkg -S /etc/NetworkManager/
network-manager, network-manager-vpnc: /etc/NetworkManager

Fixed by moving symlink, but let me know if I can provide any additional information.

Steve Langasek (vorlon) wrote :

On Sat, Dec 09, 2017 at 05:12:36PM -0000, Daniel wrote:
> Hello,

> Was just bitten by this as well. etc/resolv.conf was pointing at
> 127.0.1.1.

> hydrogen@Bliss:~$ ls -l /etc/resolv.conf
> lrwxrwxrwx 1 root root 33 May 24 2016 /etc/resolv.conf -> ../run/NetworkManager/resolv.conf

> hydrogen@Bliss:~$ dpkg -S /etc/NetworkManager/
> network-manager, network-manager-vpnc: /etc/NetworkManager

> Fixed by moving symlink, but let me know if I can provide any additional
> information.

Can you attach the contents of /etc/NetworkManager/conf.d and
/etc/NetworkManager/NetworkManager.conf from your system?

atimonin (atimonin) wrote :

I have a similar issue on a fresh 17.10 install:
global sites are resolving OK, but local corporate sites not resolving

firther investigation:

# systemctl status systemd-resolved-update-resolvconf.service
● systemd-resolved-update-resolvconf.service
   Loaded: loaded (/lib/systemd/system/systemd-resolved-update-resolvconf.service; static; vendor preset
   Active: inactive (dead)
Condition: start condition failed at Tue 2017-12-19 14:05:37 MSK; 2 days ago
           └─ ConditionFileIsExecutable=/sbin/resolvconf was not met

# dpkg -l resolvconf
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-====================-===============-===============-=============================================
un resolvconf <none> <none> (no description available)

#apt install resolvconf

fixed the issue

frankie (frankiea) wrote :

I recently upgraded to 17.1 and have this same issue. Please provide a fix.

frankie (frankiea) wrote :

Fix it with the

#apt install resolvconf

as suggested above.

Antony Jones (wrh) wrote :

Been affected by this since my fresh 17.10 install (not an upgrade, but a clean install).

The install was desktop amd64 iso, with no customisations at all, I'm surprised that this package is missing.

Steve Langasek (vorlon) wrote :

This package is not used in new installs of 17.10, by design. If you are seeing wrong behavior of /etc/resolv.conf on a new install, that is not this bug. Please file a separate bug report against the systemd package with a description of what you are seeing so that we can help you.

Jeffrey Walton (noloader) wrote :

Ping...

Anupam Datta (adbd04) wrote :

In my case it works well with WiFi network, But the Ethernet network is having the issue. In same port other machine works, but not mine. Earlier with 16:04 it used to work.

nish (nishantkumar05) wrote :

+1 for the issue.

Its broken for some VPN cases. Maintainer please note that some VPN application updates DNS with resolvconf package and removes those setting on exist. This is breaking the DNS resolution in some rare cases.

Steve Langasek (vorlon) wrote :

> Its broken for some VPN cases. Maintainer please note that some VPN application
> updates DNS with resolvconf package and removes those setting on exist. This is
> breaking the DNS resolution in some rare cases.

So, in that case I wonder if we shouldn't force removal of resolvconf on upgrade to 18.04, to make it clear that this is no longer supported. Dimitri, do you have any thoughts on this?

Changed in resolvconf (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
aaronfranke (arnfranke) wrote :

This breaks chroot environments of 17.10 and up in a host of 17.04 and below.

Cubic PPA (cubic-wizard) on 2018-10-20
Changed in cubic:
status: New → Won't Fix

This issue is also happening in Ubuntu 16.04LTS with backports enabled. So I think there is something foobar with systemd-resolved and not resolvconf.

Paul Hewlett (phewlett76) wrote :

I recently did an apt update on my laptop running cosmic. DNS was very slow and I got the degraded to UDP message. Investigation showed that /etc/resolv.conf symlinked:

    lrwxrwxrwx 1 root root 39 Oct 22 2017 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

I fixed it by removing the prefixed '..':

     lrwxrwxrwx 1 root root 37 Dec 2 11:54 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

and all is now good.

Steve Langasek (vorlon) wrote :

On Sun, Dec 02, 2018 at 11:59:42AM -0000, Paul Hewlett wrote:
> I recently did an apt update on my laptop running cosmic. DNS was very
> slow and I got the degraded to UDP message. Investigation showed that
> /etc/resolv.conf symlinked:

> lrwxrwxrwx 1 root root 39 Oct 22 2017 /etc/resolv.conf ->
> ../run/systemd/resolve/stub-resolv.conf

> I fixed it by removing the prefixed '..':

> lrwxrwxrwx 1 root root 37 Dec 2 11:54 /etc/resolv.conf ->
> /run/systemd/resolve/stub-resolv.conf

> and all is now good.

There is no reason that using an absolute rather than a relative symlink for
this file would fix "slow" DNS. Those two symlinks point to the same real
file, and either the symlink works and your DNS resolves the same, or the
symlink doesn't work and you get no DNS at all.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers