This is the old SliTaz forum - Please use the main forum.slitaz.org

There is something seriously wrong with the rcS boot sequence and network.sh [SOLVED]
  • on4aaon4aa March 2011

    [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!

  • mojomojo March 2011
    You mentioned in your other post you were using ndiswrapper with 2.6.30.3
    http://forum.slitaz.org/index.php?p=/discussion/2663/fritzwlan-usb-stick-works-but-does-not-start-automatically./p1
    Ndiswrapper never worked for me on kernel 2.6.30.6 trying numerous adapters which worked with ndiswrapper on slitaz-2.0 (kernel 2.6.25.5)
    The radio on the adapter associates with the wireless router but had no network connectivity with static i.p. and timed out trying to dhcp.


  • OldGuyOldGuy March 2011
    @on4aa

    This is the related code of netbox:
          <hbox>
            <button>
              <label>Restart</label>
              <input file icon="reload"></input>
              <action>echo -n "Stopping interface : \$INTERFACE... "</action>
              <action>ifconfig \$INTERFACE down</action>
              <action>killall -q udhcpc; echo "done"</action>
              <action>/etc/init.d/network.sh restart</action>
            </button>
          </hbox>

    As you can see, besides shutting the interface down and killing all dhcp clients, netbox just calls "/etc/init.d/network.sh restart"

    Rgds.
  • on4aaon4aa March 2011

    @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.

  • on4aaon4aa March 2011
    @OldgGuy: Thanks for the netbox code. I eventually came to that very same conclusion after introducing a sleep command in network.sh and seeing that it works. At the end, the sleep duration more or less corresponds to the time you need to get into the netbox tool ;-)
  • slicelslicel March 2011
    I hoped that locating the script in local.sh might provide enough of a delay but maybe not or maybe not for your computer speed.  How many seconds of delay did your PII need?

    You were correct that the netbox button was more than restart.  Did you try the whole button code in local.sh?

             <action>echo -n "Stopping interface : \$INTERFACE... "</action>
              <action>ifconfig \$INTERFACE down</action>
              <action>killall -q udhcpc; echo "done"</action>
              <action>/etc/init.d/network.sh restart</action>

    I do not know if local.sh uses <action>, </action>, and $INTERFACE.

    Thank you
  • on4aaon4aa March 2011

    @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.

  • slicelslicel March 2011
    Thank you, the 25s and other information helps to build the knowledge base and documentation.
  • on4aaon4aa March 2011

    To keep things clear, total official boot time is now, according to cat /var/log/boot.log : SliTaz boot time: 33s.

    However, as stated before, in that time I already had the opportunity to log on to my desktop. 33s is the time it takes to get connected to WLAN.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

SliTaz Social