Comment 2 for bug 366967

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 with 8.10 and 9.04 and reproduce the behaviour I observed.
May be ifup should be taught that complex interface configs are not to be processed from under udev and fail immediately in this case. Like, if the interface config contains options related to resolvconf, wpa-supplicant, or any commands in 'up' options. Or may be, big red warning should be included in 'man 5 interfaces' that the user should not expect the filesystem to be mounted r/w during interface bring-up, which will certainly teach the user about certain limitations of right things to do at this moment.

So far, the best workaround for me has been the one I mention above.