[Gllug] Getting a script to run at boot time on Debian Squeeze

['lesleyb']

On Sat, Feb 19, 2011 at 04:16:10PM +0000, John Winters wrote:
> I have a SheevaPlug running Debian and I've recently updated it from  
> Lenny to Squeeze.  This has led to a problem.
>
> The system has its root fs on an SDHC card and then various data  
> directories on an external USB HDD with the space being managed by lvm.
>
> At boot time, the external drive takes a few seconds to be noticed and  
> ready, so when I first set it up I put a little script called "dosleep"  
> in /etc/init.d and linked it from /etc/rcS.d.  It sleeps for 5 seconds  
> and is in the boot sequence just before the lvm stuff.  Like this:
>
> john at sheeva:/etc/init.d$ ls /etc/rcS.d
> README		     S20module-init-tools      S40networking
> S02hostname.sh	     S24dosleep		       S43portmap
> S02mountkernfs.sh    S25mdadm-raid	       S44nfs-common
> S03udev		     S26lvm2		       S45mountnfs.sh
> S04mountdevsubfs.sh  S30checkfs.sh	       S46mountnfs-bootclean.sh
> S05bootlogd	     S30procps		       S47lm-sensors
> S07hdparm	     S35mountall.sh	       S48console-screen.sh
> S08hwclockfirst.sh   S36mountall-bootclean.sh  S55bootmisc.sh
> S10checkroot.sh      S36udev-mtab	       S55urandom
> S11hwclock.sh	     S37mountoverflowtmp       S70screen-cleanup
> S12mtab.sh	     S38pppd-dns	       S70x11-common
> S18ifupdown-clean    S39ifupdown	       S99stop-bootlogd-single
>
> This used to work fine, but since the upgrade to Squeeze, my little  
> script doesn't seem to get called at all.  The boot sequence has not  
> been converted to dependency based booting - largely because of the  
> existence of this script.
>
> Looking at the Debian policy manual, it says one now can't rely on just  
> having the symbolic link there, but it doesn't say what the mechanism  
> actually is.
>
> I'm intending to add the necessary headers to my script to allow  
> dependency based booting, just as soon as I work out why it doesn't get  
> called.
>
> Incidentally, the dosleep script currently contains:
>
> #!/bin/sh
> /usr/bin/logger "Sleeping for 5 seconds"
> /bin/sleep 5
> /usr/bin/logger "Finished sleeping"
>
> I know this is horribly out of date, but I don't see why it doesn't get  
> called at all.
>
> Any ideas?

If you've done a successful update you'll find insserv has been added and
'breaks' the old sysv-rc system. Leastways that's what I had when I first
attempted an upgrade from lenny to squeeze.  

aptitude why-not insserv and 
aptitude why-not sysv-rc may help you determine what is exactly on your 
system.

I used 
aptitude --purge-unused -v full-upgrade  to upgrade and then 
apt-get install sysv-rc followed by by
apt-get autoremove

insserv was developed to order the boot scripts in a different way.
There is now a block required at the top of any init.d script. An example is

### BEGIN INIT INFO
# Provides:          killprocs
# Required-Start:    $local_fs
# Required-Stop:
# Default-Start:     1
# Default-Stop:
# Short-Description: executed by init(8) upon entering runlevel 1 (single).
### END INIT INFO

I'm in a similar situation with some of my boot scripts.  Basically you have to
write an INIT INFO block for your custom boot scripts.  You're in a prime position
to improve your script.

man 8 insserv is your friend

I always use the -s flag on apt-get and aptitude upgrades of any type, 
redirecting the output to file if necessary, to check exactly what is 
proposed in any update or upgrade to my system.  Given the extent of the 
data in a full- or dist-upgrade, it's worth checking what will break before 
committing the upgrade.

Regards

Lesley
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug