Runtime directory does not exist during /etc/rcS1.d/08loopback setup

[Ilkka Tuohela]

When /etc/rcS1.d/08loopback is run, the resolvconf runtime directory
does not yet exist, and a warning message results. Resulting error comes from /etc/network/if-up.d/000resolvconf, but the reason we get this error is that /etc/init.d/resolvconf is not called yet.

My suggestion is to change postinst script:

    update-rc.d resolvconf start 07 S . stop 89 0 6 . > /dev/null || exit 0

[Mathieu Bérard (mathieu-berard)]

This happen for me as well.
But is-it useful to run resolvconf for the loopback interface ?
If not mybe we can add

---
# Quit if we're called for the loopback
[ "$IFACE" = lo ] && exit 0
---

to /etc/network/if-up.d/000resolvconf

[Sebastian Kapfer (caci)]

Some people may have a "nameserver" line in their "lo" configuration, for adding a 127.0.0.1 local nameserver. I'm not sure this configuration makes any sense, you could just add that to /etc/resolvconf/resolv.conf.d/base :-)

[Sebastian Kapfer (caci)]

What does work for me is
* starting /etc/init.d/resolvconf earlier, i.e. as rcS/S07resolvconf.
* making /etc/resolvconf/run point to /var/run/resolvconf.

This _should_ work (and does, for me) as mountvirtfs is S01 and provides a writable /var/run.

I'm not sure this still works if /var is a separate partition. However, that would be a mountvirtfs bug, not a resolvconf one. (mountvirtfs would have to mount /var readonly to be able to mount a tmpfs at /var/run. I don't think it currently does that.)

Anyways, the above fulfills the requirements as far as resolvconf is considered and should be applied to the package.

[Sebastian Kapfer (caci)]

Fix works fine even for a split-/var setup.

[Sebastian Kapfer (caci)]

Fix by using /var/run instead of /dev/shm

[Zak B. Elep (zakame)]

Bah with the bad upload: this is yet another "/var/run is on a tmpfs" bug, so even if we move from /dev/shm we still have a prob.

If we are to follow /var/run, /etc/init.d/resolvconf must recreate /var/run/resolvconf at startup...

[Sebastian Kapfer (caci)]

No it's not. /etc/init.d/resolvconf _does_ create the directory the symlink /etc/resolvconf/run points to.

I.e. once /etc/resolvconf/run -> /var/run/resolvconf and /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf everything works fine.

Maybe the postinst script should enforce these two symlinks (i.e. overriding previous changes by the local admin). Any different setup will fail to work with the current Ubuntu boot sequence.

[Marc Schiffbauer (mschiff)]

Sorry for "cross-posting" here and at #37118. This bug system is new to me and saw too late that the other is a duplicate to this and I did not get any emails from the system.... so to be sure:

I am having Problems with resolvconf, too.

I think the problem is that we have
  S07resolvconf
and
  S11mountdevsubfs
in /etc/rcS.d/
so resolvconf is started before /dev/shm is mounted by mountdevsubfs which cannot work IMO.... or am I missing something?

-Marc

[Sebastian Kapfer (caci)]

resolvconf is supposed to be using /var/run which is mounted in S01mountvirtfs. Using /dev/shm is a ugly hack anyway, and as you observed correctly, /dev/shm is not available until S11.

[joe (joerg-unglaub)]

Thats my opinion to resolfconf should be S12resolvconf
and loopback S13loopback resolvconv is definately run to early as it depends ond mountdevsubfs which mounts /dev/shm

[Sebastian Kapfer (caci)]

Did you _read_ the posts of the other users?

[Zak B. Elep (zakame)]

Should now be fixed in latest Dapper 1.34ubuntu2 .

[dix_ans (dichodaemon)]

I still can't get it to work. I have desinstalled/reinstalled resolvconf. When I reboot there is no /var/run/resolvconf/resolv.conf file, but the file /var/run/resolvconf/interface/eth0 has the correct DNS configuration. Is this just me or other people are still having problems?

[Sebastian Kapfer (caci)]

Did you purge resolvconf?

Your bug seems to be different from all the others, we probably should open a separate report for that one.

[dix_ans (dichodaemon)]

Hello again,

I have purged resolvconf and now everything is working OK, thank you very much!

Dizan