Oralux and Tracing the rc2.d Scripts

[Martin McCormick]

	I only have one problem left to solve, but it is a
killer so far. I got Oralux installed as Debian on a Dell laptop
and the speech works after you get it started, but that is one
symptom of this strange problem I have. The distribution has
secure shell or ssh and there is no default rc2.d script to
start ssh on boot. I figured this is a security feature so it
doesn't come up when you don't need it.

	I put the S20ssh link in /etc/rc2.d and pointed it at
/etc/init.d/ssh which is the pattern for all other daemons.

	I also built a script in /etc/init.d that starts
speechd-up and it works if you call it manually. So does the ssh
start script.

	When the system boots, both new scripts are ignored but
scripts below and above it in the priority number sequences are
run.

	I have been working all week to try to capture the
running of this phase of the boot process to attempt to get some
idea as to why these scripts get passed by. The scripts do have
echo statements and it is my guess that this all goes to the
screen. Syslog is all but useless. If I run klogd with the -c 1
flag, it produces about 300 lines while booting but nothing
related to runlevel 2. The system in question has no RS-232
ports although it does have a USB port. I am just not sure if
the USB port will do me any good at boot time.

	The initab script has a debug line you can uncomment but
that causes the script to simply echo what it would do if
running for real without actually doing it. It runs perfectly
and finds all the scripts in the right order if you run it after
bootup. I need to know as much as possible what happens in a
true booting situation to figure out why sshd and speechd-up
refuse to come up.

	The ssh daemon is started in the same priority number
that I have seen on all other Linux systems.

	Also, speech-dispatcher starts with no problem at all.
It starts at S20. The documentation states that speechd-up must
start after speech-dispatcher so I gave speechd-up S25 in the
rc2.d sequence.

	Any other suggestions as to how to make this system tell
me what is doing are greatly appreciated.

	Sorry for the length of this message, but I figured you
would want to know what I already did. The two scripts are owned
by root and executable.

Martin McCormick WB5AGZ  Stillwater, OK 
Systems Engineer
OSU Information Technology Department Network Operations Group