Comment 52 for bug 44194

Revision history for this message
Colin Watson (cjwatson) 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.

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.