Ubuntu

ifupdown-udev integration should be thought-out more thoroghly

Reported by Wladimir Mutel on 2009-04-25
290
This bug affects 81 people
Affects Status Importance Assigned to Milestone
resolvconf (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: ifupdown

$ lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04

$ apt-cache policy ifupdown
ifupdown:
  Installed: 0.6.8ubuntu19
  Candidate: 0.6.8ubuntu19
  Version table:
 *** 0.6.8ubuntu19 0
        500 http://localhost jaunty/main Packages
        100 /var/lib/dpkg/status
     0.6.8ubuntu12 0
        500 http://localhost intrepid/main Packages

On my system I used Ubuntu 8.10 for some time, as well as earlier Ubuntu versions, starting probably from 7.04.
On this system I have server+router setup with pretty advanced options in '/etc/network/interfaces' file, including use of 'resolvconf' ('dns-nameservers', also updating 'bind9' and 'squid' configs), as well as submitting 'batch' jobs ('up' commands, to run pptp and pppoe connections soon after corresponding eth iface is brought up, but not before). Of course these actions depend on certain scripts having been run, like, remounting root directory rw, 'resolvconf' initialization, and so on.

Up to and including Ubuntu 8.10, everything in my setup worked well, probably due to the fact that 'ifup' was actually called in 'rcS.d/S40networking' after all necessary preparations were done. Save for the fact that 'at'/'batch' utilities were unable to send a notification signal to 'atd' because it was not running then, but that was not a big grief as they could submit jobs into the queue directory anyway, and 'atd' could see these being started later.

After upgrade to Ubuntu 9.04, I found that 'ifup' is now called by 'udevd', very early in the boot process. Before filesystem check. Before the root is remounted rw. Before the 'resolvconf' initialized and its updates are allowed. So my nice network configuration, that I trusted to 'ifupdown' to handle for a long time, breaks. And it breaks in the middle of the way. I.e., what does not require storage in the filesystem, is still preformed. The iface is up, its address/netmask/gateway/routes are configured. But no resolvconf. And no at/batch jobs. On the first failed command, 'ifup' stops bringing the iface up, does not do any rollback like bringing it down by 'ifconfig', and on the next run from 'S40networking' it tries to bring it up again, stumbling even earlier in the configuration steps.

Anyway, commenting out the "add" line in "85-ifupdown.rules" have been an immensely helpful workaround in my case.

And even if my iface configs were simple enough, just want you to note another nice possibility of breakage :
In the same file, '85-ifupdown.rules', there is hardcoded path '/var/run/network', presumably for 'ifupdown' to hold 'ifstate' file in it. Other scripts on the system look to where '/etc/network/run' symlink points. In my setup kept from previous versions of 'ifupdown', it was pointing to '/dev/shm/network'. Okay, thought I at one step of this painful debugging, may be I should switch this symlink to '/var/run/network' as well. And I did so. Now let's look at a scenario. '/var/run' is mounted in 'S02mountkernfs.sh' . 'udev' is started in 'S03udev'. Then who knows what events could be processed by 'udev', may be including some ifups filling the 'ifstate'. Then, in 'S36mountall-bootclean.sh', '/var/run' is dutifully cleaned, removing 'ifstate' in the course. Don't know, may be it is worth to use a directory in '/lib/init/rw', as does 'resolvconf' ?

So as you see, upgrading from Ubuntu 8.10 to 9.04 happened to be a nice testcase for 'ifupdown'.
May be my information could be useful to you in further work on the package.
Lot of pain, yes, but the relief is possible :>

Related branches

Ubuntu has called ifup from a udev rule for pretty much every release, I'm not sure what changed between Ubuntu 8.10 and 9.04 that has caused your problem.

From the simplest perspective, yes, you have a very complex setup and it's likely not possible to run certain things before the filesystem is writable -- however the things you are doing should not rely on that.

As to the difference between /etc/network and /var/run/network - this is an Ubuntu/Debian difference. It sounds like some scripts are using the Debian /etc path, and need to be updated to use the Ubuntu path.

All-in-all you are experiencing a number of problems, and it would greatly help if you could explain in detail everything you have experienced. We can then get them filed as *separate* bugs that can be addressed.

Thanks

Changed in ifupdown (Ubuntu):
assignee: nobody → Scott James Remnant (scott)
importance: Undecided → Medium
status: New → Incomplete
Wladimir Mutel (mwg) wrote :
Download full text (3.7 KiB)

Everything I have configured in my /etc/network/interfaces worked for some reason up to and including Ubuntu 8.10.
I had a look into ifupdown-udev integration in Ubuntu 8.10 and so far did not notice any serious difference with 9.04, but anyway, with 9.04, actions configured in 'interfaces' started to be triggered too early (before the filesystem is remounted rw, before rundirs are cleaned, etc.).

Some samples for your consideration :

auto lo eth0

iface lo inet loopback

iface eth0 inet static
        address 192.168.200.240
        netmask 255.255.255.0
        network 192.168.200.0
        broadcast 192.168.200.255
        dns-nameservers 192.168.200.203 192.168.200.202
        dns-search example.dp.ua
        up ip addr add 192.168.201.240/24 dev eth0
        up sysctl -w net.ipv4.conf.eth0.log_martians=0

Worked in 7.*, 8.*. Stopped to work in 9.04.

Symptom : resolvconf-related information (dns-* options) is not recorded in resolvconf rundir (/lib/init/rw/resolvconf/interface/), and so resolv.conf is not regenerated with specified options.
Possible cause : udev is run at S03, and resolvconf rundir is initialized and cleaned only at S07.
 There is an integration between ifupdown and resolvconf, and it is broken by this.

Another symptom : bind9 configuration file in /var/run/bind/named.options is not regenerated, its 'forwarders' list is not updated, left empty.
Possible cause : clobbered resolvconf rundir at S07, cleaning of /var/run at S36.
 There is an integration between bind9 and resolvconf, and it is broken by this.

Workaround : comment out /ACTION.*add.*RUN.*ifup/ line in /lib/udev/rules.d/85-ifupdown.rules

Sample 2 :

auto lo eth0 eth3

iface lo inet loopback
        up iptables-restore < /home/mwg/its

iface eth0 inet static
        address 172.17.12.15
        netmask 255.255.255.0
        dns-nameservers 172.17.12.1
        up ip rule add from 172.17.12.15 lookup 4
        up ip route add default via 172.17.12.1 table 4
        up ip route add 195.24.128.78 via 172.17.12.1
        up ip route add 195.24.128.75 via 172.17.12.1
        up ip route add 195.24.128.88 via 172.17.12.1
        up echo pon dsl-provider1 | batch

iface eth3 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        up echo pon dsl-provider2 | batch

Symptom : submitting batch job fails, and bringing up the interface fails as a result. At S40, 'ifup -a' is run again, trying to bring up the same interface, and this time failing at 'ip route add' as the route has already been added. IP rule (routing policy) is added twice.
Possible cause : 'batch' calls 'at -qb' which requires /var/spool/cron/atjobs/ to be accessible r/w. I have my /var in the root filesystem so it becomes remounted r/w only at S10, while udev runs ifup shortly after S03 and probably well before S10.

Workaround : comment out the same line in the same .rules file.

I don't have an idea why these samples worked for me completely well in 8.10 and before. May be udev has become faster in 9.04, and race conditions started to happen. May be some barrier had been removed which prevented ifup from running too early. Anyway, I hope you will be able to test my samples wit...

Read more...

Download full text (4.9 KiB)

On Wed, 2009-05-06 at 05:48 +0000, Wladimir Mutel wrote:

> Everything I have configured in my /etc/network/interfaces worked for some reason up to and including Ubuntu 8.10.
> I had a look into ifupdown-udev integration in Ubuntu 8.10 and so far did not notice any serious difference with 9.04, but anyway, with 9.04, actions configured in 'interfaces' started to be triggered too early (before the filesystem is remounted rw, before rundirs are cleaned, etc.).
>
This has been the case for a while.

It would help if you could identify what things run from ifup require a
writable filesystem, in general those kinds of things shouldn't.

> Some samples for your consideration :
>
> auto lo eth0
>
> iface lo inet loopback
>
> iface eth0 inet static
> address 192.168.200.240
> netmask 255.255.255.0
> network 192.168.200.0
> broadcast 192.168.200.255
> dns-nameservers 192.168.200.203 192.168.200.202
> dns-search example.dp.ua
> up ip addr add 192.168.201.240/24 dev eth0
> up sysctl -w net.ipv4.conf.eth0.log_martians=0
>
> Worked in 7.*, 8.*. Stopped to work in 9.04.
>
None of this requires a writable filesystem?

> Symptom : resolvconf-related information (dns-* options) is not recorded in resolvconf rundir (/lib/init/rw/resolvconf/interface/), and so resolv.conf is not regenerated with specified options.
> Possible cause : udev is run at S03, and resolvconf rundir is initialized and cleaned only at S07.
> There is an integration between ifupdown and resolvconf, and it is broken by this.
>
This may be a bug in resolvconf in Ubuntu.

> Another symptom : bind9 configuration file in /var/run/bind/named.options is not regenerated, its 'forwarders' list is not updated, left empty.
> Possible cause : clobbered resolvconf rundir at S07, cleaning of /var/run at S36.
> There is an integration between bind9 and resolvconf, and it is broken by this.
>
Likewise sounds like a resolveconf issue.

Note that /var/run is not cleaned in Ubuntu since it's a tmpfs.

> iface lo inet loopback
> up iptables-restore < /home/mwg/its
>
> iface eth0 inet static
> address 172.17.12.15
> netmask 255.255.255.0
> dns-nameservers 172.17.12.1
> up ip rule add from 172.17.12.15 lookup 4
> up ip route add default via 172.17.12.1 table 4
> up ip route add 195.24.128.78 via 172.17.12.1
> up ip route add 195.24.128.75 via 172.17.12.1
> up ip route add 195.24.128.88 via 172.17.12.1
> up echo pon dsl-provider1 | batch
>
> iface eth3 inet static
> address 192.168.1.2
> netmask 255.255.255.0
> up echo pon dsl-provider2 | batch
>
> Symptom : submitting batch job fails, and bringing up the interface fails as a result. At S40, 'ifup -a' is run again, trying to bring up the same interface, and this time failing at 'ip route add' as the route has already been added. IP rule (routing policy) is added twice.
> Possible cause : 'batch' calls 'at -qb' which requires /var/spool/cron/atjobs/ to be accessible r/w. I have my /var in the root filesystem so it becomes remounted r/w only at S10, while udev runs ifup shortly afte...

Read more...

Wladimir Mutel (mwg) wrote :

Writable filesystem in my cases is required only by at/batch, as we have determined. But who knows what configurations could other people have. Certainly, if the interface config has 'up' options with any commands, this should be an indication that it is not to be brought up from udev. Or may be provide an option for the interface config, named like 'noudev', to prevent this explicitly by hand.

Potential resolvconf bug is dependent on these integration chains :
chain1 : udev is started at S03, udev runs ifupdown, ifupdown runs resolvconf for dns-* options, resolvconf expects its rundir to be initialized (rm everything, mkdir interface, etc)
chain2 : resolvconf rundir is initialized only at S07 . So earlier runs of resolvconf fail due to missing interface dir
So, resolvconf rundir initialization should happen before its first run, i.e. before starting udev to be sure.
Btw, there is nice bug 340071, just about the opposite matter.
It seems the proper order of resolvconf initialization still has to be determined.

re: /var/run, I was really wrong and now I have checked by myself that tmpfs /var/run is not cleaned really, so that's not a question now.

Network Manager is useful on the desktop, but I have a number of GUI-less servers and routers migrated from Debian to Ubuntu, with advanced enough configuration in interfaces(5) for proper operation of ifupdown and all its integration chains to really matter for me.

I don't use NFS much enough, saving aside for diskless booting, so I could not say anything significant on this topic.
Hope, ifupdown or resolvconf could be reformed to satisfy user's needs in both ways.

Jakub Turski (yacoob) wrote :

Fact that ifup runs so early from this udev rule breaks asynchronous mounting of network shares (nfs/cifs). If you add a CIFS share to /etc/fstab, set it to auto, it might not get mounted at boot anyway. It should get mounted as a result of /etc/network/if-up.d/mountnfs script run, during ifup, but... ifup will get run by udev early, and this script will either fail, or won't run as a result of another script failing. Later, when /etc/init.d/networking calls ifup -a, ifup will see that interfaces are already up, and do nothing. As a result, share will remain unmounted. It will of course work if you run the /etc/init.d/networking script by hand (or just ifdown/up). And yet another workaround is to set ASYNCMOUNTNFS=no in /etc/default/rcS. But truth is, those are just workarounds, and the actual problem lies in 85-ifupdown.rules.

What are the cases that it SHOULD and WILL run properly? How about changing that ifup call from "--allow auto" to "--allow udev", and just make sure that interfaces that are safe for such early treatment are marked with such class in /etc/network/interfaces?

Jakub Turski (yacoob) wrote :

I've looked at how Debian handles that - and it also launches ifup/down for new interfaces but with --allow hotplug. Sane approach. Please fix Ubuntu's behavior?

Changed in ifupdown (Ubuntu):
assignee: Scott James Remnant (scott) → nobody
Jorge Moraleda (jorge-moraleda) wrote :

My symptoms are the same on ubuntu 9.10 karmic. I use a static ip address, but I decided to migrate from specifying my dns servers in /etc/resolv.conf to adding a dns-nameservers line in /etc/network/interfaces. After a full boot /etc/resolv.conf is blank with only the comment lines.

  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

After I manually restart the network with ifdown/ifup, then my resolv.conf gets properly written.

This my /etc/network/interfaces:

  auto lo
  iface lo inet loopback

  iface eth1 inet static
  address 192.168.1.11
  netmask 255.255.255.0
  gateway 192.168.1.1
  dns-nameservers 68.94.157.1 68.94.156.1
  auto eth1

Wladimir Mutel (mwg) wrote :

This bug is specific to Ubuntu 9.04.

For Ubuntu 9.10, see LP:448095 (in the file '/etc/init/network-interface.conf'
comment out the line 'exec ifup --allow auto $INTERFACE')

Fredrik Staxäng (fstx01) wrote :

For the original problem, why not remove eth0 from auto in /etc/network/interfaces, and call ifup eth0 from rc.local?

It appears to me that there are conflicting requirements when interfaces should be configured. I like to have the
iptable rules in place before bringing up the outer interface.

Wladimir Mutel (mwg) wrote :

Don't know why the requirements are conflicting.
I am sure no one would object that resolvconf runtime initialization should happen before first ifup run. Just that simple.

As to iptables rules loading, I usually put iptables-restore command into 'iface lo' config section.
Earlier, Debian had a kind of infrastructure for iptables rules loading/saving, but they deprecated it once with a new iptables version, and now we have to invent our own.

Steve Langasek (vorlon) wrote :

This looks like an issue with resolvconf not being integrated with the Ubuntu event-driven boot, not with ifupdown not integrating properly with udev. Indeed, ifupdown now hooks into upstart instead of into udev, but I don't imagine this has fixed your problem.

affects: ifupdown (Ubuntu) → resolvconf (Ubuntu)
Changed in resolvconf (Ubuntu):
status: Incomplete → New
Thomas Hood (jdthood) on 2011-07-03
Changed in resolvconf (Ubuntu):
status: New → Confirmed

I have some 10.04 LTS systems which are afflicted by this, and some which aren't.

Is there really no solution to this, in an LTS distro? Seriously?

Thomas Hood (jdthood) wrote :

> Is there really no solution to this, in an LTS distro? Seriously?

Keep in mind that resolvconf is from universe.

But still, if resolvconf is going to be offered for Ubuntu then critical bugs in the Ubuntu patch need to be fixed.

...I'd be perfectly satisfied with a work-around. As it is, I've waded through all the comments on this bug and all the dupes and there's just a mess of try-this-try-that, etc. I suspect, I might be able to remove the dns- options from my interfaces file, and then somehow disable/break the auto generation of the /etc/resolv.conf file and then I could just manually set its contents. But I just haven't yet had the time to go mucking around.

Thomas Hood (jdthood) wrote :

To disable automatic generation of /etc/resolv.conf, purge the resolvconf package. Then you should have a static /etc/resolv.conf you can edit by hand. Unless you use NetworkManager in which case NetworkManager will overwrite /etc/resolv.conf.

The workaround in dupe bug #448095 might still work..

#448095 has over 80 comments -- I've read through it carefully several times and I don't see that there's a clear, works-on-Lucid work around. But that's ok -- jdthood's suggest above in comment 15 sounds like the straightforward work around I was seeking. (Since I don't need the dynamic feature of a changing resolv.conf file.) I will try it, and will report back here. Thanks Thomas and Sander for your ideas!

You could also try the PPA mentioned in comment 39 (has lucid packages), then read comment 83.

...just removing ("apt-get purge resolvconf") the package fixes the problem for me.

I don't need the /etc/resolv.conf file being dynamically modified. Simply purge the package, remove the "# this file is auto generated..." comment in /etc/resolv.conf and my problem is solved.

Jonas Sundman (jonas-sundman) wrote :

Ran into this when updating to 11.10, I suspect that an incomplete transition from /var/run to /run lead to it.

Anyway, purging the package was the cleanest fix.

Thomas Hood (jdthood) wrote :

I am the author and maintainer of resolvconf in Debian. Unfortunately I don't know enough about upstart to maintain resolvconf for Ubuntu.

In its current condition in Ubuntu (universe) the resolvconf package does not work properly.

If no one is willing to maintain resolvconf in Ubuntu then it should be removed.

jwm (jwm-angrymonkey) wrote :

It turns out that writing Upstart configuration is pretty simple, so I'll take a crack at making some Ubuntu patches in the next few weeks. Someone remind me if I forget.

upstart configuration is already done.

Also packaging and patches are available

See Bug #448095

Thomas Hood (jdthood) wrote :

That would be much appreciated.

Thomas Hood (jdthood) wrote :

More generally (and this is addressed to anyone who has submitted information to this report and to all those marked as duplicates of this one) I would appreciate it if one or more of you would step forward and offer to help me maintain the resolvconf package in Ubuntu on an ongoing basis. I would be happy to do this work myself but I am just too unfamiliar with the Ubuntu upstart architecture and with Ubuntu development processes.

I'm willing to do that.

I have done the upstart specifics of resolvconf over at bug #448095, and have made some improvements to resolvconf itself that can be beneficial to debian as well (basically factoring out hardcoded paths in /etc/resolvconf/*.d scripts and delegating those to the /sbin/resolvconf script, as well as consolidating initialisation into /sbin/resolvconf).

It's all there at bug #448095, and I;m willing to discuss those changes with you to see how we can make it more robust on both Ubuntu and Debian.

Sander,

Could you please copy the exact "changes" you're referring to back in this bug (since bug 448095 is marked as a duplicate of this one here)? It would also make it a little easier to track down and sponsor. Any type of patch will do, if you have just an upstart script that's fine, and if you have a debdiff that's even better, but we can work basing on what's already available.

Once you have a patch or something added, let me know and we can complete the work (and forward any relevant changes to Debian).

Thomas Hood (jdthood) wrote :

Hello Mathieu,

Sander is now working with the Debian maintainers of resolvconf to fix the problems in the Ubuntu version of the resolvconf package. Your participation would also be most welcome!

Sander mentioned some "improvements to resolvconf itself that can be beneficial to Debian as well" above. Some of these have now been implemented in the Debian package and will be present in upcoming release 1.62.

With these improvements in place it will be easier to adapt the package to Ubuntu.

You can follow our progress at http://lists.alioth.debian.org/mailman/listinfo/resolvconf-devel
--
Thomas Hood
Debian resolvconf maintainers

Thomas Hood (jdthood) on 2011-12-01
Changed in resolvconf (Ubuntu):
status: Confirmed → Fix Committed
Thomas Hood (jdthood) wrote :

A new Ubuntu resolvconf package has been prepared by the Debian maintainers which we hope will fix this bug.

I ask you to test this new package before we upload it to the Ubuntu repos.

Please install the resolvconf package from ppa:jdthood/resolvconf (https://launchpad.net/~jdthood/+archive/resolvconf) and let me know whether or not you have any problems with it.
--
Thomas Hood
Debian resolvconf maintainers
<email address hidden>

Martin Jackson (mhjacks) wrote :

I have installed the new packages on several oneiric and precise boxes that used to have problems with resolvconf 1.48 from Ubuntu; the 1.63ppa5 packages seem to resolve those issues. The servers are multi-interface machines, one workstation uses static addressing but never seemed to be able to populate its resolv.conf at boot time. (I had done the /etc/init.d/networking restart workaround). I installed the new packages on all of them today and they all populated resolv.conf correctly at boot time without requiring the networking restart.

Thanks for working this out - this bug has been at least a minor headache for me since intrepid, I believe.

Thomas Hood (jdthood) wrote :

Thanks very much for testing the beta resolvconf package. I am pleased to hear that it behaves better than the previous Ubuntu resolvconf package. We'll do our best to release 1.63ubuntu1 very soon.

Around the time you were writing your message I uploaded a new version, 1.63ppa6. Relative to 1.63ppa5 which you tested, this new version makes a change to the resolvconf upstart configuration such that an update is done at boot time. Previous 1.63 versions omitted to do this. (The update is necessary, otherwise machines with only static nameserver information (in files in /etc/resolvconf/resolv.conf.d/) end up with an absent resolv.conf file.) I would appreciate if you would update to 1.63ppa6 and let me know whether or not everything still works as it should on your systems.
--
Thomas Hood

Martin Jackson (mhjacks) wrote :

I will test the new version today and post the results tonight. Look for another post from me in about 10 hours.

Thanks,
Marty

Martin Jackson (mhjacks) wrote :

One of my systems (an Oneiric server) did not correctly regenerate resolv.conf on boot - but it had a partial interfaces file (dns-search was defined but not dns-nameservers. Don't ask me how that happened.)

I'm not exactly sure what to make of that, as I have several other boxes (Oneiric and Precise) that worked just fine. I have been having some problems with the network interfaces on them (they are bnx2-based cards).

I'll keep an eye on things and see if I can reboot that particular one again. Are there any diagnostic levels I can turn up in resolvconf to assist, if needed?

Thanks,
Marty

Thomas Hood (jdthood) wrote :

Well, if there was a "dns-search" option in a stanza that was activated then the corresponding "search" option should have appeared in resolv.conf. If that didn't happen then we need to figure out why it did not.

Please let me know if, after fixing /etc/network/interfaces, resolv.conf still isn't correctly generated on that one machine.

No, resolvconf has no debugging or logging features.

Cheers,
--
Thomas

Martin Jackson (mhjacks) wrote :

That was the thing - it had "dns-search" but not "dns-nameservers". The dns-search line showed up fine. I don't think that's resolvconf's fault.

After fixing /etc/network/interfaces, I rebooted the machine twice - the first time, I zero'ed the resolv.conf file (not deleting the symlink of course) and the resolv.conf regenerated as I expected. I rebooted again and the resolv.conf generated fine, so I'm good.

resolvconf v1.63ppa7 from the jdthood's PPA also fixes the boot up problem on my oneiric machine (using a local caching DNS server as well as multiple upstream DNSes for VPN connections) . Thanks!

Launchpad Janitor (janitor) wrote :
Download full text (10.3 KiB)

This bug was fixed in the package resolvconf - 1.63ubuntu1

---------------
resolvconf (1.63ubuntu1) precise; urgency=low

  [ Thomas Hood ]
  * Debian fixed bugs (LP: #797339, #871058, #471975, #378844, #894417)
  * Differences from Debian:
    - /sbin/resolvconf:
      + Exit if /etc/resolv.conf is not a symlink
    - debian/rules:
      + Install upstart script rather than initscript (LP: #366967, #750423)
    - debian/{pre,post}inst
      + Migrate (to /run) from /var/run, not from /lib/init/rw.
      + [0706f28] Remove old Sys V init scripts and symlinks
  * Thanks to Sander van Grieken for his assistance with this release.

resolvconf (1.63) unstable; urgency=low

  [ Thomas Hood ]
  * [a83fce3] Depend on a later version of the initscripts package
  * [cfc8349] Use variable instead of hard-coded path for old run dir
    in maintainer scripts, to help shrink the Ubuntu diff.
  * [9921902] Update and improve resolvconf(8)
  * [719dc9b] Run update on boot (Closes: #651801, #651827)
  * [5fc985c] Don't trigger on reconfigure (Closes: #651803)

resolvconf (1.62) unstable; urgency=low

  [ Thomas Hood ]
  * [0352a85] postrm: On removal restore original resolv.conf if current
    (dynamic) resolv.conf has no content. (Closes: #644956)
    Thanks to Josep Lladonosa Capell.
  * [7cdfa73] Move logic details from initscript to /sbin/resolvconf;
    for this purpose add new options to /sbin/resolvconf:
    --enable-updates, --disable-updates, --updates-are-enabled,
    --create-runtime-directories.
  * [7cdfa73] Eliminate "-i" option supplied to update scripts and
    the code in /etc/resolvconf/update.d/libc that made use of this.

  [ Marco Nenciarini ]
  * [e175b76] Remove hardcoded path from resolvconf's invocation in
    maintainer scripts. Thanks to lintian

resolvconf (1.61) unstable; urgency=low

  * [cbb5105] list-records: Add comment re: extglob; speed up final loop
  * [4492943] Eliminate bashisms from /sbin/resolvconf. (Other scripts in this
    package still use bash, though, so this does not close wish #519364.)
    Thanks to Stefan Monnier
  * [63da54b] update.d/libc: Only run-parts update-libc.d/ if the latter exists.
    (Closes: #642965)

resolvconf (1.60) unstable; urgency=low

  [ Marco Nenciarini ]
  * [c30024e] Switch vcs fields to git
  * [4041409] Add debian/gbp.conf to make easy the usage of
    git-buildpackage

  [ Thomas Hood ]
  * [18e2fac] Update es.po thanks to Javier Fernández-Sanguino
    (Closes: #642360)
  * [18e2fac] Include resolv.conf.d/base information in
    resolv.conf *after* dynamic information, rather than before
    (Closes: #642222)

resolvconf (1.59) unstable; urgency=low

  * dhclient-enter-hooks.d/resolvconf: Add support for dhclient
    DHCPv6 (Closes: #635470)
  * postinst: Fail with message if /etc/resolv.conf is immutable
    (Closes: #635775)
  * Mention in resolvconf(8) that /etc/default/resolvconf has
    to be created if it is to be used to set resolvconf environment
    variables (Closes: #633014)
  * Drop outdated id.po

resolvconf (1.58) unstable; urgency=low

  [ Thomas Hood ]
  * Update README
  * Update debconf template translations:
    * da.po thanks to Joe Dalton (Closes: #630241)
  ...

Changed in resolvconf (Ubuntu):
status: Fix Committed → Fix Released
Steffen H. (shulegaa) wrote :

I had an up-to-date Ubuntu 11.10 workstation. I recently received an update that required a 'restart' (aka reboot - new kernel). I put off the reboot while working away - for a week or so. So, as has happened each time I've had to 'restart' (aka reboot for a new kernel), I once again watched in disgust as my /etc/resolv.conf file got blown away.

Really? Again?

Is anyone EVER going to allow an Ubuntu system administrator to configure their networking set up via some /etc file contents. Is some GUI now mandatory? No, I don't use NetworkManager. It isn't installed. It created INCREDIBLE grief.

As others have noted, I now find that ifdown/ifup works - albeit only once I conform to the Ubuntu way and put a dns-nameservers directive into the eth0 stanza in /etc/network/interfaces.

But guess what, no more clean reboots. Each reboot requires an ifdown/ifup ritual. Really?

The rationale for not only ignoring, but obliterating, a user defined system configuration must be fascinating. I just cannot imagine.

And to think ... some wonder why the year of the Linux desktop never arrived!

Disgusted and dismayed

Steve Langasek (vorlon) wrote :

On Tue, Feb 21, 2012 at 09:26:17PM -0000, Steffen H. wrote:
> I had an up-to-date Ubuntu 11.10 workstation.

> I recently received an update that required a 'restart' (aka reboot - new
> kernel). I put off the reboot while working away - for a week or so. So,
> as has happened each time I've had to 'restart' (aka reboot for a new
> kernel), I once again watched in disgust as my /etc/resolv.conf file got
> blown away.

The Ubuntu bug tracker is a place for users to report bugs and work with
developers to resolve them. You have followed up to an existing bug report
without subscribing to it, providing only a vague description of the problem
("something" overwrote /etc/resolv.conf) and giving no reason to think your
message is related to this closed bug report.

You should not expect the Ubuntu developers to take any action in response
to such a message.

> Is anyone EVER going to allow an Ubuntu system administrator to
> configure their networking set up via some /etc file contents. Is some
> GUI now mandatory?

This has worked flawlessly for the vast majority of Ubuntu users since
Ubuntu's inception.

> As others have noted, I now find that ifdown/ifup works - albeit only
> once I conform to the Ubuntu way and put a dns-nameservers directive
> into the eth0 stanza in /etc/network/interfaces.

This sounds like you did have resolvconf installed. Resolvconf has never
been part of a standard Ubuntu install prior to 12.04, was unmaintained in
the Ubuntu archive and was in a known-broken state (as this and other bug
reports attest). The obvious solution if you aren't happy with the output
of resolvconf, a package which exists for the *sole purpose* of updating
/etc/resolv.conf, is to uninstall the package.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Thomas Hood (jdthood) wrote :

> my /etc/resolv.conf file got blown away
> [...]
> But guess what, no more clean reboots. Each reboot requires an ifdown/ifup ritual.

As Steve mentioned, the resolvconf package was not an official part of Ubuntu prior to 12.04. In earlier releases it was available from the Universe repository but was broken such that after boot it was necessary to ifdown and ifup, just as you say.

To fix this now you can choose either to remove the resolvconf package or update to the version (1.63ubuntu8) from the Precise repository.

Resolvconf has been available in Debian for about eight years now and has thousands of users. Once in a while the Debian maintainers receive complaints like yours, but these unhappy experiences have always proved to have been a result of misunderstanding about how resolvconf is supposed to work. The resolvconf package collects nameserver information and keeps a file, /run/resolvconf/resolv.conf, up to date; /etc/resolv.conf is linked to /run/resolvconf/resolv.conf. If you don't want this feature then, in a terminal, as root, do "dpkg --purge resolvconf" and edit /etc/resolv.conf.

(It may have occurred in the past that another package pulled in resolvconf via a Recommends dependency. We apologize for that, combined with the fact that the Ubuntu resolvconf package was not properly maintained.)

I think it would be better, however, if you learned a bit more about resolvconf --- especially since Ubuntu 12.04's ubuntu-minimal will depend on it: please read /usr/share/doc/resolvconf/README.gz.

elleP (pelle-quicknet) wrote :

Is there any chance of a backport for 10.04?
I am working on a headless machine that should automatically connect to a server on the first available network interface. Resolvconf seems like the right tool for the job but as mentioned here it is broken for anything but 12.04.

Thomas Hood (jdthood) wrote :

Have you tried upgrading the resolvconf package to the Precise or Quantal version?

elleP (pelle-quicknet) wrote :

Yes, unfortunately resolvconf 1.63 depends on a newer version of initscripts:

$sudo dpkg -i resolvconf_1.63ubuntu11_all.deb
dpkg: regarding resolvconf_1.63ubuntu11_all.deb containing resolvconf, pre-dependency problem:
 resolvconf pre-depends on initscripts (>= 2.88dsf-13.10)
  initscripts is installed, but is version 2.87dsf-4ubuntu17.5.
dpkg: error processing resolvconf_1.63ubuntu11_all.deb (--install):
 pre-dependency problem - not installing resolvconf
Errors were encountered while processing:
 resolvconf_1.63ubuntu11_all.deb

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers