Public bug reported:
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 :>
** Affects: ifupdown (Ubuntu)
Importance: Undecided
Status: New
--
ifupdown-udev integration should be thought-out more thoroghly
https://bugs.launchpad.net/bugs/366967
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
