Chapter 3. The system initialization

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.

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/3.x 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.

	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.

title           Debian GNU/Linux
root            (hd0,2)
kernel          /vmlinuz root=/dev/hda3 ro
initrd          /initrd.img

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.

menuentry "Debian GNU/Linux" {
        set root=(hd0,3)
        linux /vmlinuz root=/dev/hda3
        initrd /initrd.img
}

For these examples, these GRUB parameters mean the following.

	Note
	The value of the partition number used by GRUB legacy program is one less than normal one used by Linux kernel and utility tools. GRUB 2 program fixes this problem.

	Tip
	UUID (see Section 9.5.3, “Accessing partition using UUID”) may be used to identify a block special device instead of its file name such as "/dev/hda3", e.g."root=UUID=81b289d5-4341-4003-9602-e254a17ac232 ro".

	Tip
	If GRUB is used, the kernel boot parameter is set in /boot/grub/grub.cfg. On Debian system, you should not edit /boot/grub/grub.cfg directly. You should edit the GRUB_CMDLINE_LINUX_DEFAULT value in /etc/default/grub and run update-grub(8) to update /boot/grub/grub.cfg.

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

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

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 init program is executed as the first program with PID=1 to perform the main boot process of starting many programs. The default file path for the init program is "/sbin/init" but it can be changed by the kernel boot parameter as "init=/path/to/init_program".

The default init program has been changing:

	Tip
	See Debian wiki: BootProcessSpeedup for the latest tips to speed up the boot process.

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

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

$ sudo telinit 4

	Caution
	The Debian system does not pre-assign any special meaning differences among the runlevels between 2 and 5. The system administrator on the Debian system may change this. (I.e., Debian is not Red Hat Linux nor Solaris by Sun Microsystems nor HP-UX by Hewlett Packard nor AIX by IBM nor …)

	Caution
	The Debian system does not populate directories for the runlevels between 7 and 9 during installation. Traditional Unix variants don't use these runlevels.

When init(8) or telinit(8) commands goes into the runlevel to "<n>", the system basically executes the initialization scripts as follows.

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

2. 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".

This simple sequential initialization system is the classical System V style boot system and was used up to the Debian lenny system.

The recent Debian system is optimized to execute the initialization scripts concurrently, instead.

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

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).

# cd /etc/rc2.d ; mv S21gdm3 K21gdm3
# cd /etc ; perl -i -p -e 's/^id:.:/id:3:/' inittab

Please note the "/etc/X11/default-display-manager" file is checked when starting the display manager daemons: xdm, gdm3, sddm, and wdm.

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.

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.

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.

• "/etc/init.d/mountkernfs.sh" for kernel filesystems in "/proc", "/sys", etc.

• "/etc/init.d/mountdevsubfs.sh" for virtual filesystems in "/dev"

• "/etc/init.d/mountall.sh" for normal filesystems using "/etc/fstab"

• "/etc/init.d/mountnfs.sh" for network filesystems using"/etc/fstab"

The mount options of special kernel filesystems (procfs, sysfs, and tmpfs for /proc, /sys, /tmp, /run, etc.) are set in "/etc/default/rcS". See rcS(5).

The mount options of normal disk and network filesystems are set in "/etc/fstab". See Section 9.5.7, “Optimization of filesystem by mount options”.

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.

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-server inetd (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.

Whenever a request for service arrives at super-server inetd , its protocol and service are identified by looking them up in the databases in "/etc/protocols" and "/etc/services". inetd then looks up a normal Internet service in the "/etc/inetd.conf" database, or a Open Network Computing Remote Procedure Call (ONC RPC)/Sun RPC based service in "/etc/rpc.conf".

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".

For system security, disable as much network service programs as possible. See Section 4.6.4, “Restricting access to some server services”.

See inetd(8), inetd.conf(5), protocols(5), services(5), tcpd(8), hosts_access(5), hosts_options(5), rpcinfo(8), portmap(8), and "/usr/share/doc/portmap/portmapper.txt.gz".

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”.

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).

You may directly change the error message level by the following.

# dmesg -n3

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.3, “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.

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.