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