resolvconf not correctly configured after update from 17.04 to 17.10

Bug #1725840 reported by Artur Schmitt
100
This bug affects 22 people
Affects Status Importance Assigned to Milestone
Cubic
Won't Fix
Undecided
Unassigned
resolvconf (Ubuntu)
Confirmed
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)

Revision history for this message
Artur Schmitt (arturschmitt) wrote :
Revision history for this message
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
Revision history for this message
Artur Schmitt (arturschmitt) wrote :
Revision history for this message
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?

Revision history for this message
Artur Schmitt (arturschmitt) wrote :

Sorry for the mistake.

Revision history for this message
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
Revision history for this message
Artur Schmitt (arturschmitt) wrote :

If you need further information, please let me know.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in resolvconf (Ubuntu):
status: New → Confirmed
Revision history for this message
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 .

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1725840] Re: resolvconf not correctly configured after update from 17.04 to 17.10

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.

Revision history for this message
MuppaneniBharath (muppanenibharath) wrote :

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

Revision history for this message
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).

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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

Revision history for this message
frankie (frankiea) wrote :

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

Revision history for this message
frankie (frankiea) wrote :

Fix it with the

#apt install resolvconf

as suggested above.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Jeffrey Walton (noloader) wrote :

Ping...

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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)
Revision history for this message
aaronfranke (arnfranke) wrote :

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

Cubic PPA (cubic-wizard)
Changed in cubic:
status: New → Won't Fix
Revision history for this message
Damiön la Bagh (kat-amsterdam) wrote :

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.

Revision history for this message
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.

Revision history for this message
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.

Changed in resolvconf (Ubuntu):
assignee: Dimitri John Ledkov (xnox) → md shoeb lincoln (lincolntgl1987)
Steve Langasek (vorlon)
Changed in resolvconf (Ubuntu):
assignee: md shoeb lincoln (lincolntgl1987) → Dimitri John Ledkov (xnox)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.