[updated] I am talking here about /etc/init.d/rcS and /etc/init.d/network.sh. I stumbled upon this when my Fritz!WLAN USB stick never started after booting, but did when hitting the "Restart" button in netbox. I first reported the symptoms here: http://forum.slitaz.org/index.php?p=/discussion/2663/fritzwlan-usb-stick-works-but-does-not-start-automatically.
During boot with SliTaz 3.0, udev is launched by rcS but fails to detect the WLAN USB stick. rcS then continues with various scripts including network.sh.
Obviously, network.sh fails miserably at detecting any wlan0.Only after finishing local.sh will rcS start several deamons, one of which is the Hardware Abstraction Layer (HAL). On my old laptop HAL is what finally succesfully detects my WLAN USB stick... Way too late.
After booting, the Network Status Monitor will not show anything for wlan0.Nonetheless, one still can manage to get online by hitting the "Restart" button under the "Configure" tab of netbox.
In /etc/init.d/rcS.conf, I changed:
UDEV="yes"
to
UDEV="no"
since in my particular case, udev fails anyhow during booting.
More importantly, I changed
RUN_SCRIPTS="bootopts.sh network.sh i18n.sh hwconf.sh local.sh"
to
RUN_SCRIPTS="bootopts.sh i18n.sh hwconf.sh local.sh"
making sure that network.sh will not be launched before detecting my WLAN hardware.
In /etc/init.d/rcS, add a line to launch network.sh after the daemons have started, as indicated below:
# Start all daemons specified with $RUN_DAEMONS.
echo "Starting all daemons specified in /etc/rcS.conf..."
for daemon in $RUN_DAEMONS
do
if [ -x /etc/init.d/$daemon ]; then
/etc/init.d/$daemon start
fi
done
/etc/init.d/network.sh
# Back to a verbose mode.
After making these changes to rcS, there are still errors in the boot log originating with network.sh. I had to add a sleep command of a hefty 25 seconds to the wifi() procedure of /etc/init.d/network.sh:
wifi() {
sleep 25
# For wifi. Users just have to enable it through yes and usually
# essid any will work and the interface is autodetected.
You may have to experiment with the duration of sleep in function of your particular laptop and WLAN USB stick. For the Fritz!WLAN stick you need to end up with about 34s total boot time as reported ate the end of /var/log/boot.log. Anything less and it will not work.
After applying these changes, you will be able to boot as fast as before to the desktop. The added delay only applies to the moment that you get connected to your WLAN. Do not be deceived the first time you boot like this by the fact that you will see nothing happening at the level of the Network Status Monitor. Just wait patiently for 25 seconds and then click on the Network Status Monitor and change the Name to wlan0, to see that you are already connected. You will need to do this once. Next time, you boot your computer, you will witness via the Network Monitor how your computer connects to WLAN shortly after logging in to the desktop (that is if you are quick enough typing your password!) All users will now be able to connect to the WLAN in this fashion, without the need to enter netbox, nor to know the root password.
All comments are invited!
@mojo: I applied the udev fix. udev now no longer fails and detects the WLAN stick. However, ifconfig in network.sh apparently cannot handle a udev-detected wlan.
I kept the fix, but I eventually reverted back to UDEV="no" in rcS.conf. In my setup it is the only thing that seems to work.
@slicel: At the end of the day, it was not the netbox commands that made the difference, but the time it took me to open netbox ;-)
I had to put network.sh at the end of rcS (because of HAL detection - udev does not work even after the fix) and launch it with a delay of 25s over the normal very impressive boot time of 9s on this PII 233MHz (try that with any flavour of Windows!). I can perfectly live with that because the desktop comes up as fast as before, and only a couple of seconds later I am connected.
I am not sure whether this wlan laziness is due to the cpu, ndiswrapper, usb 1.0 or the wlan stick itself. For that to know, one should have an idea what ndiswrapper does during such a startup.
It looks like you're new here. If you want to get involved, click one of these buttons!