Comment 39 for bug 44194

>> Waiting until S40networking is run brings up an issue with iscsi
>> devices. The current way of handling iscsi devices is to treat them
>> as local devices by making sure that all iscsi devices are created
>> before local filesystems are mounted (S35mountall.sh and
>> S30checkfs.sh). That requires ifupdown scripts to be run as soon as
>> network interfaces are discovered instead of S40networking.
> ah, I see. This means that you've decided that booting from iscsi
> devices (feature A) is "more important" than booting with having wpa
> statically configured (feature B) in /etc/network/interfaces.

Sheesh, calm down, dude. This is not an either/or situation. There's no
doubt that your "fix" breaks several completely reasonable use cases.
It's completely reasonable to attempt to configure network interfaces as
they're discovered by udev. wpasupplicant for some reason deals very
badly with this. Glancing at its pre-up script, I'm guessing your
problem is this:

# quit if executables are not installed
if [ ! -x "$WPA_SUP_BIN" ] || [ ! -x "$WPA_CLI_BIN" ]; then
        exit 0
fi

If wpasupplicant isn't around (/usr isn't mounted, for instance), you
exit 0. This tells ifupdown that everything is fine and that you don't
want to do anything else to configure this device, and ifup happily
marks the interface as configured.

If wpasupplicant can't do its thing before /var/run/network/initialized
exists, why don't you just check for that _in_ _wpasupplicant's_ _if-*_
scripts instead of ruining for everyone else by putting it in udev?

> This particular bug is about B. I don't agree that A warrants breaking
> B. What you have done is to deliberatly break B in order to allow A to
> work.

Dude... You're the one who broke it to begin with. Mathias fixed the
breakage you introduced and reopened this bug to let you know that this
problem is now back (because your solution wasn't acceptable). This
seems perfectly reasonable to me. In fact, I'm the one who suggested it
to begin with. Mathias was just nice enough to do it for me.

> - ifupdown
> - the wpasupplicant ifupdown hook.

> I'd suggest looking in the 2nd first.

Yes, someone with the appropriate testing environment (perhaps even
someone who's being bitten by this bug) or with enough interest in
wpasupplicant should look into it. Sure, it would be nice if Mathias
did this, but I really don't believe it's his responsibility.

Imagine this: If I had a problem with a module in the kernel, and I knew
it only happened with SMP kernels, it would fix my problem 100% if I
disabled SMP in our kernels. If someone on the kernel team found that to
be inappropriate and reverted that change thus breaking my module again,
it doesn't make it their job to fix my module. Sure, it'd be nice if
they did, but it's not their responsiblity. Putting that check in udev
is a very inappropriately big hammer to solve this problem.