It is wise for you as the system administrator to know roughly how the Debian system is started and configured. Although the exact details are in the source files of the packages installed and their documentations, it is a bit overwhelming for most of us.

I did my best to provide a quick overview of the key points of the Debian system and their configuration for your reference, based on the current and previous knowledge of mine and others. Since the Debian system is a moving target, the situation over the system may have been changed. Before making any changes to the system, you should refer to the latest documentation for each package.

3.1. An overview of the boot strap process

The computer system undergoes several phases of boot strap processes from the power-on event until it offers the fully functional operating system (OS) to the user.

For simplicity, I limit discussion to the typical PC platform with the default installation.

The typical boot strap process is like a four-stage rocket. Each stage rocket hands over the system control to the next stage one.

Of course, these can be configured differently. For example, if you compiled your own kernel, you may be skipping the step with the mini-Debian system. So please do not assume this is the case for your system until you check it yourself.

Note

For non-legacy PC platform such as the SUN or the Macintosh system, the BIOS on ROM and the partition on the disk may be quite different (Section 9.3.2, “Disk partition configuration”). Please seek the platform specific documentations elsewhere for such a case.

3.2. Stage 1: the BIOS

The BIOS is the 1st stage of the boot process which is started by the power-on event. The BIOS residing on the read only memory (ROM) is executed from the particular memory address to which the program counter of CPU is initialized by the power-on event.

This BIOS performs the basic initialization of the hardware (POST: power on self test) and hands the system control to the next step which you provide. The BIOS is usually provided with the hardware.

The BIOS startup screen usually indicates what key(s) to press to enter the BIOS setup screen to configure the BIOS behavior. Popular keys used are F1, F2, F10, Esc, Ins, and Del. If your BIOS startup screen is hidden by a nice graphics screen, you may press some keys such as Esc to disable this. These keys are highly dependent on the hardware.

The hardware location and the priority of the code started by the BIOS can be selected from the BIOS setup screen. Typically, the first few sectors of the first found selected device (hard disk, floppy disk, CD-ROM, …) are loaded to the memory and this initial code is executed. This initial code can be any one of the following.

Typically, the system is booted from the specified partition of the primary hard disk partition. First 2 sectors of the hard disk on legacy PC contain the master boot record (MBR). The disk partition information including the boot selection is recorded at the end of this MBR. The first boot loader code executed from the BIOS occupies the rest of this MBR.

3.3. Stage 2: the boot loader

The boot loader is the 2nd stage of the boot process which is started by the BIOS. It loads the system kernel image and the initrd image to the memory and hands control over to them. This initrd image is the root filesystem image and its support depends on the bootloader used.

The Debian system normally uses the Linux kernel as the default system kernel. The initrd image for the current 2.6 Linux kernel is technically the initramfs (initial RAM filesystem) image. The initramfs image is a gzipped cpio archive of files in the root filesystem.

The default install of the Debian system places first-stage GRUB boot loader code into the MBR for the PC platform. There are many boot loaders and configuration options available.

This is free software which substitutes MSDOS MBR. This only understands disk partitions.

Warning

Do not play with boot loaders without having bootable rescue media (CD or floppy) created from images in the grub-rescue-pc package. It makes you boot your system even without functioning bootloader on the hard disk.

For GRUB Legacy, the menu configuration file is located at "/boot/grub/menu.lst". For example, it has entries as the following.

For GRUB 2, the menu configuration file is located at "/boot/grub/grub.cfg". It is automatically generated by "/usr/sbin/update-grub" using templates from "/etc/grub.d/*" and settings from "/etc/default/grub". For example, it has entries as the following.

You can start a boot loader from another boot loader using techniques called chain loading.

See "info grub" and grub-install(8).

3.4. Stage 3: the mini-Debian system

The mini-Debian system is the 3rd stage of the boot process which is started by the boot loader. It runs the system kernel with its root filesystem on the memory. This is an optional preparatory stage of the boot process.

Note

The term "the mini-Debian system" is coined by the author to describe this 3rd stage boot process for this document. This system is commonly referred as the initrd or initramfs system. Similar system on the memory is used by the Debian Installer.

The "/init" script is executed as the first program in this root filesystem on the memory. It is a shell script program which initializes the kernel in user space and hands control over to the next stage. This mini-Debian system offers flexibility to the boot process such as adding kernel modules before the main boot process or mounting the root filesystem as an encrypted one.

You can interrupt this part of the boot process to gain root shell by providing "break=init" etc. to the kernel boot parameter. See the "/init" script for more break conditions. This shell environment is sophisticated enough to make a good inspection of your machine's hardware.

Commands available in this mini-Debian system are stripped down ones and mainly provided by a GNU tool called busybox(1).

Caution

You need to use "-n" option for mount command when you are on the readonly root filesystem.

All boot mechanisms are compatible through "/etc/init.d/rc", "/etc/init.d/rcS", "/usr/sbin/update-rc.d", and "/usr/sbin/invoke-rc.d" scripts.

Tip

The readahead-fedora package can speed up starting of a system with decent amount of DRAM.

The normal Debian system is the 4th stage of the boot process which is started by the mini-Debian system. The system kernel for the mini-Debian system continues to run in this environment. The root filesystem is switched from the one on the memory to the one on the real hard disk filesystem.

The "/sbin/init" program is executed as the first program and performs the main boot process. The Debian normally uses the traditional sysvinit scheme with the sysv-rc package. See init(8), inittab(5), and "/usr/share/doc/sysv-rc/README.runlevels.gz" for the exact explanation. This main boot process essentially goes through the following.

The Debian system goes into runlevel N (none) to initialize the system by following the "/etc/inittab" description.

The Debian system goes into runlevel S to initialize the system under the single-user mode to complete hardware initialization etc.

The Debian system goes into one of the specified multi-user runlevels (2 to 5) to start the system services.

The initial runlevel used for multi-user mode is specified with the "init=" kernel boot parameter or in the "initdefault" line of the "/etc/inittab". The Debian system as installed starts at the runlevel 2.

All actual script files executed by the init system are located in the directory "/etc/init.d/".

3.5.1. The meaning of the runlevel

Each runlevel uses a directory for its configuration and has specific meaning as the following.

Table 3.4. List of runlevels and description of their usage

runlevel

directory

description of runlevel usage

N

none

system bootup (NONE) level (no "/etc/rcN.d/" directory)

0

/etc/rc0.d/

halt the system

S

/etc/rcS.d/

single-user mode on boot (alias: "s")

1

/etc/rc1.d/

single-user mode switched from multi-user mode

2

/etc/rc2.d/

multi-user mode

3

/etc/rc3.d/

,,

4

/etc/rc4.d/

,,

5

/etc/rc5.d/

,,

6

/etc/rc6.d/

reboot the system

7

/etc/rc7.d/

valid multi-user mode but not normally used

8

/etc/rc8.d/

,,

9

/etc/rc9.d/

,,

You can change the runlevel from the console to, e.g., 4 by the following.

The Debian system does not populate directories for the runlevels between 7 and 9 when the package is installed. Traditional Unix variants don't use these runlevels.

3.5.2. The configuration of the runlevel

Note

In Debian squeeze, dependency based boot order provided by the insserv package is used instead of classical alphabetical one. The "CONCURRENCY" value in "/etc/default/rcS" controls its concurrency: "none" for no concurrency, "startpar" for concurrency within the same sequence number, or "makefile" for full concurrency. See "/usr/share/doc/insserv/README.Debian".

The name of the symlink in each runlevel directory has the form "S<2-digit-number><original-name>" or "K<2-digit-number><original-name>". The 2-digit-number is used to determine the order in which to run the scripts. "S" is for "Start" and "K" is for "Kill".

For "CONCURRENCY=none", when init(8) or telinit(8) commands goes into the runlevel to "<n>", it execute following scripts.

The script names starting with a "K" in "/etc/rc<n>.d/" are executed in alphabetical order with the single argument "stop". (killing services)

The script names starting with an "S" in "/etc/rc<n>.d/" are executed in alphabetical order with the single argument "start". (starting services)

For example, if you had the links "S10sysklogd" and "S20exim4" in a runlevel directory, "S10sysklogd" which is symlinked to "../init.d/sysklogd" would run before "S20exim4" which is symlinked to "../init.d/exim4".

For "CONCURRENCY=makefile" (new default), package dependency defined in the header of init scripts are used to order them.

Warning

It is not advisable to make any changes to symlinks in "/etc/rcS.d/" unless you know better than the maintainer.

3.5.3. The runlevel management example

For example, let's set up runlevel system somewhat like Red Hat Linux as the following.

init starts the system in runlevel=3 as the default.

init does not start gdm3(1) in runlevel=(0,1,2,6).

init starts gdm3(1) in runlevel=(3,4,5).

This can be done by using editor on the "/etc/inittab" file to change starting runlevel and using user friendly runlevel management tools such as sysv-rc-conf or bum to edit the runlevel. If you are to use command line only instead, here is how you do it (after the default installation of the gdm3 package and selecting it to be the choice of display manager).

You can still start X from any console shell with the startx(1) command.

3.5.4. The default parameter for each init script

The default parameter for each init script in "/etc/init.d/" is given by the corresponding file in "/etc/default/" which contains environment variable assignments only. This choice of directory name is specific to the Debian system. It is roughly the equivalent of the "/etc/sysconfig" directory found in Red Hat Linux and other distributions. For example, "/etc/default/cron" can be used to control how "/etc/init.d/cron" works.

The "/etc/default/rcS" file can be used to customize boot-time defaults for motd(5), sulogin(8), etc.

If you cannot get the behavior you want by changing such variables then you may modify the init scripts themselves. These are configuration files editable by system administrators.

3.5.5. The hostname

The kernel maintains the system hostname. The init script in runlevel S which is symlinked to "/etc/init.d/hostname.sh" sets the system hostname at boot time (using the hostname command) to the name stored in "/etc/hostname". This file should contain only the system hostname, not a fully qualified domain name.

To print out the current hostname run hostname(1) without an argument.

3.5.6. The filesystem

Although the root filesystem is mounted by the kernel when it is started, other filesystems are mounted in the runlevel S by the following init scripts.

The actual mounting of network filesystems waits for the start of the network interface.

Warning

After mounting all the filesystems, temporary files in "/tmp", "/var/lock", and "/var/run" are cleaned for each boot up.

3.5.7. Network interface initialization

Network interfaces are initialized in runlevel S by the init script symlinked to "/etc/init.d/ifupdown-clean" and "/etc/init.d/ifupdown". See Chapter 5, Network setup for how to configure them.

3.5.8. Network service initialization

Many network services (see Chapter 6, Network applications) are started under multi-user mode directly as daemon processes at boot time by the init script, e.g., "/etc/rc2.d/S20exim4" (for RUNLEVEL=2) which is a symlink to "/etc/init.d/exim4".

Some network services can be started on demand using the super-serverinetd (or its equivalents). The inetd is started at boot time by "/etc/rc2.d/S20inetd" (for RUNLEVEL=2) which is a symlink to "/etc/init.d/inetd". Essentially, inetd allows one running daemon to invoke several others, reducing load on the system.

Sometimes, inetd does not start the intended server directly but starts the TCP wrapper program, tcpd(8), with the intended server name as its argument in "/etc/inetd.conf". In this case, tcpd runs the appropriate server program after logging the request and doing some additional checks using "/etc/hosts.deny" and "/etc/hosts.allow".

3.5.9. The system message

The system message can be customized by "/etc/default/rsyslog" and "/etc/rsyslog.conf" for both the log file and on-screen display. See rsyslogd(8) and rsyslog.conf(5). See also Section 9.2.2, “Log analyzer”.

3.5.10. The kernel message

The kernel message can be customized by "/etc/default/klogd" for both the log file and on-screen display. Set "KLOGD='-c 3'" in this file and run "/etc/init.d/klogd restart". See klogd(8).

If "/lib/modules/<kernel-version>/modules.dep" was not generated properly by depmod(8) for some reason, modules may not be loaded as expected by the udev system. Execute "depmod -a" to fix it.

The name of device nodes can be configured by udev rule files in "/etc/udev/rules.d/". Current default rules tend to create dynamically generated names resulting non-static device names except for cd and network devices. By adding your custom rules similar to what cd and network devices do, you can generate static device names for other devices such as USB memory sticks, too. See "Writing udev rules" or "/usr/share/doc/udev/writing_udev_rules/index.html".

Since the udev system is somewhat a moving target, I leave details to other documentations and describe the minimum information here.

3.5.12. The kernel module initialization

The modprobe(8) program enables us to configure running Linux kernel from user process by adding and removing kernel modules. The udev system (see Section 3.5.11, “The udev system”) automates its invocation to help the kernel module initialization.

There are non-hardware modules and special hardware driver modules as the following which need to be pre-loaded by listing them in the "/etc/modules" file (see modules(5)).

The configuration files for the modprobe(8) program are located under the "/etc/modprobes.d/" directory as explained in modprobe.conf(5). (If you want to avoid some kernel modules to be auto-loaded, consider to blacklist them in the "/etc/modprobes.d/blacklist" file.)

The "/lib/modules/<version>/modules.dep" file generated by the depmod(8) program describes module dependencies used by the modprobe(8) program.

Note

If you experience module loading issues with boot time module loading or with modprobe(8), "depmod -a" may resolve these issues by reconstructing "modules.dep".

The modinfo(8) program shows information about a Linux kernel module.

The lsmod(8) program nicely formats the contents of the "/proc/modules", showing what kernel modules are currently loaded.