Breezy -> Dapper transition needs proper /etc/resolvconf/run handling

Here is the proposed patch to the postinst script.

Sorry, trying again. For some reason Melone ate my plain/x-patch
attachment.

Well, application/octet-stream doesn't work either. Here's another go!

--- resolvconf.postinst.orig 2006-04-04 12:04:55.000000000 +0200
+++ resolvconf.postinst 2006-04-04 12:33:20.000000000 +0200
@@ -69,6 +69,9 @@
   if [ -z "$RUN_CANONICALPATH" ] ; then
    report_err "Deleting /etc/resolvconf/run symlink whose canonical path could not be determined"
    rm -f /etc/resolvconf/run
+ elif [ "${RUN_CANONICALPATH}" != "${RUN_CANONICALPATH#/dev/shm}" ] ; then
+ report_err "Deleting /etc/resolvconf/run symlink to /dev/shm (inaccessible during bootup)"
+ rm -f /etc/resolvconf/run
   fi
  fi
  # Delete it if it isn't a directory or a link to one

Hi! Thanks for the bug.

However, this is already reported as Bug #33362 which is already fixed. Can you please verify this with the latest Dapper, to make sure?

Thanks,

I did a purge and reinstall of resolvconf and the misbehaviour was still there.

What was missing is a link:

ln -s /var/run/resolvconf/resolv.conf resolv.conf

And resolv.conf is working as I will expect it
:-)

Indeed.

resolvconf's debian/init needs to rebuild /var/run/resolvconf... nasty...

The symlink should be /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf (and the /etc/resolvconf/run pointing to /var/run/resolvconf). Of course coastgnu's link has the same effect, just pointing out how it's supposed to work.

And just to state it again here: /etc/init.d/resolvconf already _does_ create the run directory if it is missing.

Sorry, this seems to be something (slightly) different than bug
#33362, I'm afraid. I'm using the latest Dapper already.

As I understand, bug #33362 refers to the fact that we should use
/var/run rather than /dev/shm. My bug report was meant to point out
that this transition is not handled cleanly by the postinst script.
The typical breezy installation will have a link
/etc/resolvconf/run -> /dev/shm/resolvconf *and* this link will be
canonicalisable at the time of the upgrade. Therefore, the postinst
script won't touch this link although it really should change it to
/var/run/resolvconf -- and rebuild this directory which is, as I
understand, taken care of by the initscript.

Sorry if I'm getting something wrong here.

No, you're entirely correct, and I agree with you, see my comment in bug #33362. My patch works for new installations, it does not handle upgrades properly. I thought that upgrades didn't matter because the package was broken before anyway.

But there was a working version in Breezy, and we need to handle updates from that version.

My proposal for fixing this mess is the following:

* In the postinst script, find out whether or not we have a working "run" directory. If so, move its contents to /var/run/resolvconf so resolvconf keeps working until reboot. If no such directory exists, resolvconf was in a broken state and will only work after the next reboot (no regression).

* Unconditionally replace /etc/resolvconf/run by a symlink to /var/run/resolvconf.

* If /etc/resolv.conf is a symlink, replace by a symlink to /etc/resolvconf/run/resolv.conf. (This should be the case anyway, but let's play safe.)

* Stop supporting any other configuration but /etc/resolvconf/run being a symlink to /var/run/resolvconf. This removes a whole lot of logic from the maintainer scripts. /var/run is the only sensible solution with the Dapper boot sequence.

* If the "run" symlink has been changed from our default config, abort the init script, giving a useful error message which indicates that such a configuration is not supported.

Any comments?

I generally feel a bit uneasy about changing things unconditionally,
perhaps even without notifying the admin. That's why my patch does
change the link without confirmation by the admin *only* if everything
seems to be untouched in breezy. Of course, we can drop this logic in
post dapper releases as Ubuntu only supports step-by-step upgrades.
However, I'd rather not touch configurations changed by the local
admin---or there should be some sort of appropriate notification, at least.

Further changes from your patch:

* I removed the creation of directories directly under /etc/resolvconf. Those won't be writable at boot time and have no merit.

* Killed off the whole /proc/mounts parsing. We know /var/run is on tmpfs after the next reboot.

* Try to keep resolvconf alive until reboot by placing a symlink to the old /dev/shm location.

If you don't have any objections, I think we can commit this.

Looks quite nice. Thanks.

I'd like the inputs of the MOTU reviewers before committing. =)

Thanks,

Looks fine to me, Zak... should be at least better than the current version :)

Thanks for everyone's inputs! =)