Comment 69 for bug 448095

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.