Index of /software/debian-fast-boot

	Name	Last modified	Size
	Parent Directory		-
	README.html	28-Jan-2010 02:16	3.6K
	S16startx	28-Jan-2010 02:11	902
	xsession.txt	28-Jan-2010 02:01	925

Fast bootup on a Debian system by starting X early

In order to decrease boot time (or, more accurately, time to login) on my Debian laptop, I experimented with starting X as soon as possible in the boot process. On my particular system, I was able to get X started at 'S16' in the sysv init scheme by moving four other scripts earlier in the boot process (specifically these scripts: x11-common screen-cleanup console-screen.kbd.sh sudo) and by loading two Linux kernel modules within the S16startx script (specifically psmouse and nvram).

Only x11-common and console-screen.kbd.sh absolutely must be run before X starts: console-screen.kbd.sh will kill your X session by making some Linux kernel call to alter the console, while X cannot start without some directories created by x11-common. On my system, psmouse must be loaded for X to start as well, since that's the driver for my mouse.

The reason screen and sudo are included is that they will malfunction if you run their init scripts while you are using them. Similarly, the nvram module is only used for tpb (the ThinkPad button daemon) which is started by my .xsession.

I found out all of this by trial and error. I have not experienced any other problems with parts of the system breaking because I start using them too early, or any other dependencies besides these. However, your system might be somewhat different: you might use different programs or a different X configuration requiring different modules. You should especially be sure that you list in the script any mouse and video drivers that X requires on your hardware.

Right now, I start up the network within my .xsession. It generally takes a few seconds after my xterms pop up for the network to start working (at which point I am automatically logged in via ssh to my main work server's screen session, and I am greeted with my already-running programs. It's a pretty neat effect: if I reboot while I'm using screen, it seems as if the computer has saved and restored all state. (Unfortunately, it hasn't, but since I run almost everything but firefox through the remote shell, it's almost as good from a practical standpoint.)

The S16startx script available here has a mechanism to pause the startup process for up to 1 minute or until a signal is received from the user for whom X was started. The purpose of this is to give priority to starting up user processes in the X session -- particularly, to give priority to KDE startup, which takes quite a while -- before the rest of the system comes up. (I don't use KDE on my own machine, but I used this same configuration on a couple KDE machines I set up for other people.) On my own system, I use this to delay the rest of startup until the network is started (from within .xsession). I've included a copy of my .xsession here for reference, if it's unclear how this works.

TODO

Some day I will make a simple installer script that will reorder the init scripts and maybe even check the X11 configuration to find out the mouse driver. It should also be able to configure an .xsession for GNOME or KDE that will properly resume ordinary bootup after the GUI is fully loaded.