I just upgraded one of my systems to Maverick, and the bug seems to be solved out-of-the-box there.
However, it seems that they just dropped in the upstart script from this bug without much thinking, resulting in somewhat of a mutant resolvconf, because a) the upstart script assumes the modified /sbin/resolvconf from this bug, i.e. it gets called with -r -i --enable-updates --dsiable-updates options, but the provided /sbin/resolvconf is not aware of these options. b) there's a link to start resolvconf from /etc/rcS.d, while there's also an upstart script (?!). The fact that /etc/init.d/resolvconf is 'upstardized' probably prevents it from doing double initialisation, but the link from /etc/rcS.d is not necessary. Third, resolvconf's data has been moved again back to /etc/resolvconf/run, forcing the need for a writable rootfs. So, it works at boot, but there's no enabling/disabling updates (start/stop resolvconf service) and no initialisation of the volatile directory structure by /sbin/resolvconf itself. This directory structure is probably instead prepared during install by the packaging scripts. -- resolvconf starts after ifupdown, does not pick the dns-nameserver and dns-search lines up from /etc/network/interfaces https://bugs.launchpad.net/bugs/448095 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
