[Bug 366967] Re: ifupdown-udev integration should be thought-out more thoroghly

[Thomas Hood]

> 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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/366967

Title:
  ifupdown-udev integration should be thought-out more thoroghly

Status in “resolvconf” package in Ubuntu:
  Fix Released

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 :>

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/366967/+subscriptions