Tagged with rcs - SliTaz Forum http://vanilla.slitaz.org/index.php?p=/discussions/tagged/rcs/feed.rss Sun, 28 Apr 24 23:18:49 +0200 Tagged with rcs - SliTaz Forum en-CA There is something seriously wrong with the rcS boot sequence and network.sh [SOLVED] http://vanilla.slitaz.org/index.php?p=/discussion/2671/there-is-something-seriously-wrong-with-the-rcs-boot-sequence-and-network.sh-solved Mon, 07 Mar 2011 06:07:25 +0100 on4aa 2671@/index.php?p=/discussions [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.

What is going wrong?

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.

What needs to be changed in rcS?

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.

What is wrong with network.sh?

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.

What is achieved?

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!

]]>