Comment 53 for bug 44194

On Friday 27 February 2009 20:51:41 Colin Watson wrote:
> Having reviewed the whole bug, I have to say that this all seems like an
> order of magnitude more work than is really required. The suggested
> approaches involve lots of complex interface definition, strict ordering
> constraints, and the need to warn users when they violate constraints.
> Why not make it all simpler instead? Simpler systems with fewer
> constraints tend to be more robust.
>
> There is precedent in Ubuntu for moving libraries and programs to the
> root filesystem when it is necessary to deal properly with hardware
> activation, whether that be hard ordering constraints (such as fuse and
> ntfs-3g being needed early on in some environments) or cases such as
> this where jobs could in principle be reordered to work in most cases
> but it's really much simpler to decouple things. I think the proper fix
> for this bug is to move the various libraries needed by wpasupplicant to
> the root filesystem, and to ensure that wpasupplicant can operate with
> only /var/lock/ and /var/run/ writable, as is the case in the early
> stages of the Ubuntu boot process. /var/lock/ and /var/run/ are mounted
> as temporary filesystems precisely so that programs can run early,
> without having to arrange to have themselves deferred until a later
> time. It is obviously simpler not to need to defer execution.
>

Yeah, makes sense.

> While I'm sympathetic to the goal of a small root filesystem, it should
> take second place to a correct and reliable boot process. This proposed
> change would increase the size of the root filesystem by perhaps 2MB,
> which I think we can live with. And, of course, as has already been
> observed it's a bug for programs in the root filesystem to link to
> libraries in /usr, which wpasupplicant already does; it's often
> reasonable to fix this by changing the libraries.
>
> The only extra complexity I have found here so far is that wpasupplicant
> expects to be able to write to log files in /var/log/. This is perhaps
> not absolutely critical to fixing this bug but it would obviously be
> desirable to fix it. Any ideas? One simple approach would be to move it
> to syslog with an appropriate facility, priority, and prefix; I don't
> know whether the wpasupplicant maintainers would find this acceptable.
>

syslog debug output was just committed upstream development branch [0] fwiw.

Thanks, Kel.

[0] http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=daa70d49de46278cf5a92b279d1d262af573cb63