Hi On Saturday 29 March 2014, Cameron Norman wrote: > On Sat, Mar 29, 2014 at 2:54 PM, Stefan Lippers-Hollmann <[email protected]> wrote: > > On Saturday 29 March 2014, Cameron Norman wrote: […] > I think another problem with starting wpa_supplicant before the > filesystem is up is that it uses /var/run where it should use /run. Do > you think you (or somebody else) will be interested in doing that? If > so, should I file a new bug?
Moving from /var/run/ to /run/ directly has been done in the packaging
Vcs already[1] and will be part of the next upload (for wpa 2.1).
> > 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.
>
> I do not think it blocks boot on async systems (at least when NFS is
> not used) like Upstart or systemd.
It does block[2] until the connection is established, which -for wlan-
includes associating with the AP and receiving a dhcp lease (if dhcp
is in use); I've just confirmed that using wired ethernet with bridges
and IPv6 involved a few weeks ago. Not using allow-hotplug for wireless
devices is pretty much always a bad idea, especially considering that
STA mode doesn't allow bridging (which would be one of the few
potential reasons for auto) in the first place.
Regards
Stefan Lippers-Hollmann
[1] http://anonscm.debian.org/viewvc/pkg-wpa?view=revision&revision=1862
[2] many daemons, enough to considerably affect boot times and boot
order
signature.asc
Description: This is a digitally signed message part.
