Hi On Saturday 29 March 2014, Cameron Norman wrote: > This bug can be seen in Upstart (#694963), and hangs boot in a NFS > mounted /usr, as well as errors the network setup when one uses "auto" > in /etc/network/interfaces. Here is the output of ldd, with the libs in > /usr bolded (HTML):
[ please avoid HTML Mails, they're very likely to be eaten by antispam measures along their way ] As you see in the bugreport, this is a long standing issue, which is only partially under our control. Actually the situation has been improved significantly during the last release cycle with many of the required libraries moving from /usr/lib/ to /lib/ already. What remains is libssl1.0.0, as libpcsclite can be avoided, but actually working on that (which is a bit problematic on kfreebsd-any) doesn't make sense before the hard-dependency is out of the way (libssl). So yes, wpa_supplicant being in /sbin/ is a bug, done ages ago by previous maintainers of the package. However moving it to /usr/ isn't a solution either, as wpa_supplicant is heavily used in local configuration scripts, which may break hard if wpa_supplicant were to disappear from /sbin/ (and introducing a compatibility symlink from /sbin/wpa_supplicant to /usr/sbin/ wouldn't actually gain you anything in practice, other than papering over the problem). And technically speaking you do want the stuff needed to bring up the network outside of /usr/. That said, trying to mount any remote filesystem over wlan at the kernel level, even more so for vital filesystems just as /usr/, /var/ or /tmp/ would be plainly insane, as you do have to expect interruption with wlan for any real world deployment (which would make your system hang, if vital parts are mounted over wlan). Likewise 'auto' is usually not a good configuration for wireless interfaces either, as -like you mentioned- this does block booting until a connection has been established, which is something you can't guarantee for wlan - not even for a static system. So what are the options to fix this? - the ideal fix for this would be to move libssl into /lib/, which is outside of our domain and depends on the openssl maintainer. Combined with using weak symbols for the libpcsclite dependency[1] (this has been tried already, but failed on kfreebsd-any - although this is fixable given enough attention), this would close the bug once and for all. However anyone mounting /usr/ over a wireless link would still be insane, even if this were possible from the policy side of it. - another approach would be mounting /usr/, along the rootfs, from within the initramfs environment, to the best of my knowledge this has been planned for quite a while already (and should even be possible in experimental, iirc rleigh's efforts correctly). - moving wpa_supplicant from the rootfs into /usr/ would fullfill the letter of the FHS and Debian policy, but wouldn't actually solve this problem at all (combined with a lot of pain in breaking lots of local configuration). Still, doing this would be the easiest option for us to close this bug (so consider me happy to oblige) - but that's not really helping anyone in practice. Whatever we end up with, you won't *ever* be able to depend on wireless links for reliable operations or mounting vital parts of your filesystem tree remotely. It just is, by definition, an unreliable network connection in practice (just about anywhere outside of lab environments). While you may not notice short interruptions for browsing the web (other than some log spam talking about reconnecting), the kernel (and nfsd in particular) doesn't like stalled network connections for mounted remote filesystems at all. Any assumptions relying on stable (and early boot) availability of wireless links are simply flawed, even if the the FHS issues were fixed. Regards Stefan Lippers-Hollmann [1] using weak symbols for libpcsclite would reduce the breakage to wpa_supplicant configurations reading wpa credentials from smartcards, which is a corner-case I'd be willing to risk.
signature.asc
Description: This is a digitally signed message part.