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

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

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

/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.

Reassign this back to network-manager then?

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

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

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