On Tue, Dec 2, 2008 at 23:04, Petter Reinholdtsen <[email protected]> wrote:
> Here are patches to add LSB headers to two of the four init.d scripts > in the nslu2-utils package. I am not sure I understood the > dependencies, so please review. Thanks very much for script patches. I've tested them out on the NSLU2 with the dependency based boot sequence (I installed insserv and ran 'dpkg-reconfigure insserv'), and the system boots without a problem. Below are slightly updated patches which have better descriptions. BTW, why did you specify $remote_fs and $all for the rmrecovery script? Surely, $all implies $remote_fs? --- nslu2-rtc.orig 2008-12-14 13:09:02.000000000 -0700 +++ nslu2-rtc 2008-12-14 20:37:07.000000000 -0700 @@ -1,2 +1,15 @@ #!/bin/sh + +### BEGIN INIT INFO +# Provides: nslu2-rtc +# Required-Start: +# Required-Stop: +# Should-Start: udev +# X-Start-Before: hwclock +# Default-Start: S +# Default-Stop: +# Short-Description: Load kernel module for the RTC device interface. +# Description: Load kernel module for the RTC device interface. +### END INIT INFO + modprobe rtc-dev --- rmrecovery.orig 2008-12-14 13:09:02.000000000 -0700 +++ rmrecovery 2008-12-14 20:37:20.000000000 -0700 @@ -1,5 +1,22 @@ #!/bin/sh -# Run to remove /.recovery if the boot seems to have succeeded + +### BEGIN INIT INFO +# Provides: rmrecovery +# Required-Start: $remote_fs $all +# Required-Stop: +# Default-Start: 1 2 3 4 5 +# Default-Stop: +# Short-Description: Remove OpenSlug recovery file if the boot seems to have +# succeeded +# Description: If instead of booting using the Debian initrd, you are +# using the OpenSlug firmware to boot Debian from a USB +# drive on your slug, then it creates a /.recovery file +# during boot, and unless this file is removed, the next +# boot will be back into the openslug system. This script +# removes this file on each boot, so that Debian will boot +# each time. +### END INIT INFO + RMRECOVERY=yes . /etc/default/rmrecovery || true if [ "$RMRECOVERY" != no ]; then > The last two scripts leds_startup and zleds, have such strange setup, > I was unable to come up with a proposal on how to get it working with > dependency based boot sequencing. Having both start and stop symlinks > in the same runlevel is not supposed to be working, and I do not > understand why leds_startup exist at all. It seem to talk about > settings only present when executed from rcS.d/, while being installed > in rc1.d/ .. rc5.d/. I hope these proposed headers can get you at > least a bit on the way to solving this bug. The following is written with the disclaimer that I'm still figuring out how leds_startup and zleds are supposed to work. It seems that the leds_startup is required to initialize the LEDs on the NSLU2 to a desired state on the transition from S to the user run level. I'm not sure what purpose setting 'previous' to S serves in the script, but wouldn't it make sense that the reason the script is installed in rc1.d/ .. rc5.d/ is simply so that the script is run on the transition form S to any of the user run levels? I'm still testing out a new version of the leds_startup script. As I understand the zleds script, it is designed to indicate the state of the system as the system boots _and_ is shutdown. The NSLU2 is a headless device, and the LEDs are the only status indicators available to typical users. The zleds changes the state of the LEDs to indicate the boot and shutdown state (see /usr/share/doc/nslu2-utils/README.Debian in the nslu2-utils package [1]). Therefore, the script needs to have both start and stop symlinks in the same run level, so how do we support such a feature with insserv? It seems like we shouldn't need to have separate init scripts because what was done before was working. Gordon [1] http://svn.debian.org/wsvn/pkg-nslu2-utils/trunk/debian/README.Debian?op=file&rev=0&sc=0 -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
