Comment 38 for bug 44194

On Tuesday 02 December 2008 16:52:21 Reinhard Tartler wrote:
> Mathias Gug <email address hidden> writes:
>
> > 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.
>
> 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.
>
> How about this: ifupdown needs to somehow know that a statically
> configured wpa device cannot be upped early in the boot process, but
> allow other devices to be configured. So the delayed starting of the
> interface is made conditionally on that fact. The question is who
> detects this. I see two possibilites
>
> - ifupdown
> - the wpasupplicant ifupdown hook.
>
> I'd suggest looking in the 2nd first.

I disagree to an extent, the problem doesn't sound specific to wpa_supplicant's
shell glue at all, but rather, the inflexibility of the statically maintained
ifupdown software on an ever evolving Debian/Ubuntu software ecosystem.

A "cheap" fix could be included in an individual ifupdown hook script, but it
strikes me that the central network dispatcher/configurator framework should be
striving to handle situations such as that described, as future hooks may also
fall prey to this pitfall.

Thanks, Kel.