Cannot resolve domain names if eth0 is in /etc/network/interfaces

Bug #1023486 reported by Brendan Donegan on 2012-07-11
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
High
Mathieu Trudel-Lapierre

Bug Description

I installed two systems with Quantal via a preseed. After booting, neither of them could connect to the web. A workaround was to remove the eth0 section from /etc/network/interfaces (which the preseed added). This is the interfaces file before:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

After restarting network-manager service it worked again immediately.

It was also suggested that the state of resolv.conf on the system might be a problem:

nameserver 209.6.3.210
nameserver 127.0.0.1
search lexenab

Removing nameserver 127.0.0.1 and restarting networking/resolvconf and network-manager seemed to fix it.

(having looked at the resolv.conf file after it worked again the 127.0.0.1 is back, which is interesting)

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: network-manager 0.9.4.0+git201206081144.2efeac8-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-4.4-generic 3.5.0-rc6
Uname: Linux 3.5.0-4-generic x86_64
ApportVersion: 2.3-0ubuntu4
Architecture: amd64
Date: Wed Jul 11 11:41:31 2012
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120711.1)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)

Thomas Hood (jdthood) wrote :

Please run "apport-collect 1023486" to submit more information about the machine in question.

Changed in network-manager (Ubuntu):
status: New → Incomplete
Thomas Hood (jdthood) wrote :

Initially eth0 was defined in /etc/network/interfaces. Normally in /etc/NetworkManager/NetworkManager.conf there is

    [ifupdown]
    managed=false

which causes NetworkManager not to touch eth0. When you removed the eth0 section from /e/n/i and restarted network-manager, NetworkManager took control of eth0, configured it and obtained nameserver addresses from the DHCP server. Somehow the addresses then got into resolv.conf but it isn't clear to me that this was done in the right way.

Please submit the output of the following commands run in a terminal.

    cat /etc/resolv.conf
    ls -l /etc/resolv.conf
    sudo lsattr /etc/resolv.conf
    ls -l /run/resolvconf
    ls -l /run/resolvconf/interface
    for F in /run/resolvconf/interface/* ; do echo === $F === ; cat $F ; done
    ls -l /etc/resolvconf/resolv.conf.d
    for F in /etc/resolvconf/resolv.conf.d/* ; do echo === $F === ; cat $F ; done
    ls -l /etc/resolvconf/interface-order
    cat /etc/resolvconf/interface-order

affects: network-manager (Ubuntu) → resolvconf (Ubuntu)

/etc/resolv.conf contains only 127.0.0.1, as introduced by NetworkManager.
/run/resolvconf/interface contains only NetworkManager, which has 127.0.0.1 with possibly a search and/or domain entry.
/etc/resolvconf/resolv.conf.d is irrelevant in this particular case and files wheren't changed. original however contains what it *probably* the information introduced by ifupdown; but that's incidental.
/etc/resolvconf/interface-order: unchanged; contains lo interfaces, then tun, tap, hso, em, p, and eth, ath, then wlan and ppp.

This is straight-out a bug in the patch that assumes *UP* for unmanaged interfaces. Maybe that patch ought to be dropped by now, but it at the very least needs to be updated to take into account changes to how DNS updates are being done now; it's probably a simple matter of checking whether the NMDevice is unmanaged at the point at which DNS is about to be changed; but there might still be the issue of reverting to the original data.

Totally reproduceable on my system --> Triaged, because the next steps are pretty obvious.

Changed in resolvconf (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → High
Thomas Hood (jdthood) wrote :

Reassign this back to network-manager then?

Paul Tötterman (ptman) on 2012-07-25
tags: added: lucid

Any progress on this bug? It blocks us from getting test results for Quantal so it would be good if it was fixed soon.

Stéphane Graber (stgraber) wrote :

As suggested, moving to network-manager. There's no clear evidence of resolvconf doing anything wrong here.

affects: resolvconf (Ubuntu) → network-manager (Ubuntu)
Changed in network-manager (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.9.6.0-0ubuntu3

---------------
network-manager (0.9.6.0-0ubuntu3) quantal; urgency=low

  * debian/patches/dnsmasq-dbus-updates.patch: make sure the no_reply flag is
    set for the SetServers message we send to dnsmasq -- we're not expecting a
    reply and the messages otherwise stick around in the queue as pending.
    (LP: #1033600)
  * debian/patches/lp990011_use_tempaddr_sysctl_default.patch: properly query
    both /etc/sysctl.d/10-ipv6-privacy.conf and /etc/sysctl.conf for the value
    of use_tempaddr. (LP: #998223)
  * debian/patches/dnsmasq-dbus-updates.patch: fail DNS caching updates (so as
    to not write 127.0.0.1 to resolv.conf) if the lists of device configs were
    empty (no nameservers or domains). (LP: #1023486)
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 16 Aug 2012 00:46:06 -0400

Changed in network-manager (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers