On 29/05/12 07:06, Thomas Hood wrote: > We aren't getting duplicates of #1000244 so it's probably not a > frequently occurring problem. If resolvconf were systematically > failing to create the resolv.conf symlink we'd be getting hundreds of > reports about it. Based on what we know now it's most probable that > #1000244 was a result of some sort of administrator error. The version > of resolvconf that was included in Precise wasn't perfect but the bugs > were fairly minor and the known ones have since been fixed.
I'm certain that it was not an 'administration error' - I discovered that my networking was broken within an hour of clean install. Others at my office have complained of search domains not working, which smells of resolvconf being broken (my understanding is that resolvconf is responsible for populating search domains in this new resolution chain). I also don't know how you can release a system resolver implementation that "wasn't perfect", or even close to it (when the existing one wasn't broken and the new implementation adds serious complexity for questionable gain), particularly in an LTS release, but suggesting that 'the users broke it' isn't going to fix things. In any case, I'm still subscribed to the other bug, so happy for any continued discussion of that particular issue to happen there. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
