Disabling graphical boot and starting applications early

[NoOp]

On 12/11/2012 3:20 AM, Daniel Dalton wrote:
> On Mon, Dec 10, 2012 at 11:52:27AM -0800, NoOp wrote:
>> > Theoretically, set "START_IN_INITRAMFS=true" and "RUN_BRLTTY=yes" in
>> > "/etc/default/brltty" and run "update-initramfs -u -k $(uname -r)".
>> > 
>> 
>> Isn't brltty a service that is run on boot via the symlink in
>> /etc/rcS.d/ to /etc/init.d/?
> 
> Well, I'm not entirely sure. Disabling this by making it Kbrltty25 has
> no effect, as in brltty still starts. 

Interesting. I first set it for S20 (S20brltty from S25brltty) and
verified that it starts and runs as S20. I then put the 'K' in front per
the README (KS20brltty), rebooted, and when I check via BUM (Boot Up
Manager) and 'sudo service brltty status, I show that brltty is not running.

Note: in order to get it to start on boot I only modified
/etc/default/brltty to 'RUN_BRLTTY=yes'. I did not run brltty.conf etc.

$ ls /etc/rcS.d
KS20brltty  README  S37apparmor  S55urandom  S70x11-common

$ sudo service brltty status
 * brltty is not running

Change to drop the 'K':
$ ls /etc/rcS.d
README  S20brltty  S37apparmor  S55urandom  S70x11-common

reboot (I'm sure there is a better way to do this without rebooting, but
I'm using a VM to do this so it's easy to reboot).

~$ sudo service brltty status
 * brltty is running



> 
> Making it S11brltty does not seem to start brltty any earlier either,
> sigh. 

Perhaps this is were Tom H's initramfs comes in.

/etc/default/brltty
...
# If true (or yes) BRLTTY will be started during initramfs execution.
# If you change this setting, you have to run "update-initramfs -u" to
have it
# take effect.  If this setting is on, "update-initramfs -u" also needs
to be
# run if /etc/brltty.conf gets changed.
START_IN_INITRAMFS=false

Change to true:
START_IN_INITRAMFS=true
and then
$ sudo update-initramfs -U

and see if that works for you.

> 
>> The scripts in this directory whose names begin with an 'S' are
>> executed once when booting the system, even when booting directly into
>> single user mode.
> 
> Ok, so maybe this is where that link is important then, say if the
> system drops into single-user mode. however, is this always guaranteed, if
> we at least get far enough to access the root fs? 
> If the answer is "yes", perhaps I would still be able to correct my
> system is something goes wrong, so it may be ok. 
> 
>> with a 'K' and run 'update-rc.d script defaults' to update the order
>> using the script dependencies.
> 
> Hmm, did not experiment with that, although, rcconf probably does that.

I didn't either because changing per the above worked (for me).

> 
> Thanks,
> Dan
>