resolvconf 1.69ubuntu1.1 breaks network install

As this is a regression in an SRU, assigning to the developer who uploaded that version. Timo, can you please look at this?

Hmm, I can't connect the bug description to the actual upload, a debdiff attached.

Steps to reproduce using https://launchpad.net/ubuntu/+source/resolvconf:
dget https://launchpad.net/ubuntu/+archive/primary/+files/resolvconf_1.69ubuntu1.dsc
dget https://launchpad.net/ubuntu/+archive/primary/+files/resolvconf_1.69ubuntu1.1.dsc
debdiff resolvconf_1.69ubuntu1.dsc resolvconf_1.69ubuntu1.1.dsc

The only change was to add a preinst rule when upgrading from 12.04 LTS's resolvconf version to 14.04 LTS, to add a symbolic link to the correct location. And that only in the case if resolvconf is already installed on the system, is of lesser version than 1.64 (meaning the 12.04 LTS's version) and if the /etc/resolv.conf file does not exist in the first place. For other cases like new installations there were no changes. This closed the bug #1308378.

What am I missing?

It seems there is a big binary diff in both the sysvinit file and maintainer scripts simply from doing a rebuild. I attach a manual diff (just a few checksums etc omitted) here which includes the small source change that was made to the preinst and all the automated changes:

 etc/init.d/resolvconf | 204 +++++++++++++++++++++-----------------------------
 postinst | 2
 preinst | 27 +++---
 prerm | 3
 4 files changed, 107 insertions(+), 129 deletions(-)

I find it hard to grasp which of the changes are problematic, which are fine and how they could be affected. Stéphane has been maintaining the Ubuntu delta in the years past, I hope he could have a SRU:able solution here? There is nothing that could be reverted unless there is some sort of compatibility mode that would give the same build result as in the 1.69ubuntu1 (preferably with the preinst fix included for upgraders).

I have debugged this problem further:

The problem seems to be that the postinst script executes "invoke-rc.d resolvconf start", which indeed seems to execute the init script /etc/init.d/resolvconf during the installation of the package. There is no /usr/sbin/policy-rc.d in the target system, so the execution of the init script is not suppressed.

When running the postinst script on it's own, it moves the original /etc/resolv.conf file to /run/resolvconf/resolv.conf and links /etc/resolv.conf to it. So far so good. But when "/etc/init.d/resolvconf start" gets called as a result of "invoke-rc.d resolvconf start", the contents of /run/resolvconf get removed (resolvconf ---wipe-runtime-directories), and a new and empty resolv.conf gets created (resolvconf --enable-updates).

After that the subsequent installation steps, which try to access the network, fail.

Are there any news regarding this problem?

From my point of view, the problem should be clear. The upstream (Debian) changes, that were introduced in the 1.69ubuntu1.1 version, don't work together with the (Ubuntu) postinst script, which causes the empty /etc/resolv.conf during installation, and then subsequent installation steps fail.

So the postinst script needs to be fixed, so network installations are possible again.

@Cs-gon: Do you have any problem with resolvconf 1.76ubuntu1?

@Cs-gon: Can you reproduce this problem (bug #1392297) with resolvconf 1.77ubuntu1?

Resolvconf 1.77ubuntu1's debian/rules runs dh_installinit with `--no-start` and so there is no longer a `invoke-rc.d resolvconf start` (which wipes runtime directories) in debian/postinst. To enable resolvconf updates, postinst simply does "resolvconf --enable-updates".

If `invoke-rc.d resolvconf start` was the cause of the problem then the problem should be solved in 1.77ubuntu1.