Arch Boot Process
From ArchWiki
This article is intended to give a chronological overview of the Arch boot process and the system files and processes involved, providing links to relevant wiki articles where necessary. Arch famously follows the BSD init convention as opposed to the more common SysV. What this means is that there is little distinction between runlevels, since the system by default is configured to use the same modules and run the same processes on all runlevels. The advantage is that users have a simple way to configure the startup process (see rc.conf); the disadvantage is that some fine-grained configuration options that SysV offers are lost. See Adding Runlevels for a way to hack some SysV-like capabilities into Arch. See Wikipedia:init for more on the distinctions between SysV and BSD style.
Contents |
Before init
After the system is powered-on and the POST is completed, the BIOS will locate the preferred boot medium and transfer control to the Master Boot Record of this device. On a GNU/Linux machine, often a bootloader such as GRUB or LILO is found and loaded from the MBR. The bootloader will present the user with a range of options for boot, e.g. Arch Linux and Windows on a dual-boot setup. Once Arch is selected, the kernel image in the /boot directory (currently kernel26.img) is decompressed and loaded into memory.
The kernel is the core of an operating system. It functions on a low level (kernelspace) interacting between the hardware of the machine, and the programs which use the hardware to run. To make efficient use of the CPU, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion (to human perception) of many tasks being executed simultaneously.
After the kernel is loaded, it reads from the initramfs (initial RAM filesystem). The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem (see FHS for details). This means that any modules that are required for devices like IDE, SCSI, or SATA drives (or USB/FW, if booting off a USB/FW drive) must be loaded. Once the initramfs loads the proper modules, either manually or through udev, it passes control to the kernel and the boot process continues. For this reason, the initrd only needs to contain the modules necessary to access the root filesystem; it does not need to contain every module one would ever want to use. The majority of modules will be loaded later on by udev, during the init process.
The kernel then looks for the program init which resides at /sbin/init. init relies on glibc, the GNU C library. Libraries are collections of frequently used program routines and are readily identifiable through their filename extension of *.so. They are essential for basic system functionality. This part of the boot process is called early userspace.
init: The Arch boot scripts
The main Arch startup process is initiated by the program init, which spawns all other processes. The purpose of init is to bring the system into a usable state, using the boot scripts to do so. As previously mentioned, Arch uses BSD-style boot scripts. init reads the file /etc/inittab; the default inittab begins with the following:
... # Boot to console id:3:initdefault: # Boot to X11 #id:5:initdefault: rc::sysinit:/etc/rc.sysinit rs:S1:wait:/etc/rc.single rm:2345:wait:/etc/rc.multi rh:06:wait:/etc/rc.shutdown su:S:wait:/sbin/sulogin ...
The first uncommented line defines the default system runlevel (3). When the kernel calls init:
- First, the main initialization script is run, /etc/rc.sysinit (a Bash script).
- If started in single user mode (runlevel 1 or S), the script /etc/rc.single will be run.
- If in any other runlevel (2-5), /etc/rc.multi is run instead.
- The last script to run will be /etc/rc.local, which is empty by default.
/etc/rc.sysinit
rc.sysinit is a huge startup script that basically takes care of all hardware configuration plus a number of general initialization tasks. It can be identified by its first task, printing the lines:
Arch Linux http://www.archlinux.org Copyright 2002-2007 Judd Vinet Copyright 2007-2009 Aaron Griffin Distributed under the GNU General Public License (GPL)
A rough overview of its tasks:
- Sources the /etc/rc.conf script
- Sources the /etc/rc.d/functions script
- Displays a welcome message
- Mounts various virtual file systems
- Creates dummy device files
- Starts minilogd
- Outputs messages from dmesg
- Configures the hardware clock
- Empties the /proc/sys/kernel/hotplug file
- Starts udev and checks for udev events
- Starts the loopback interface
- Loads modules from the MODULES array defined in rc.conf
- Configures RAID and encrypted filesystem mappings
- Runs a forced check of partitions (fsck) if the /etc/fstab file contains instructions to do so
- Mounts local partitions and swap (networked drives are not mounted before a network profile is up)
- Activates swap areas
- Sets the hostname, locale and system clock as defined in rc.conf
- Removes various leftover/temporary files, such as /tmp/*
- Configures the locale, console and keyboard mappings
- Sets the console font
- Writes output from dmesg to /var/log/dmesg.log
/etc/rc.sysinit is a script and not a place for settings. It sources (i.e. reads and inherits variables and functions) rc.conf for settings and /etc/rc.d/functions for the functions that produce its graphical output (nice colors, alignments, switching 'busy' to 'done', etc.) There is no particular need to edit this file, although some may wish to do so in order to speed up the boot process.
/etc/rc.single
Single-user mode will boot straight into the root user account and should only be used if one cannot boot normally. This script ensures no daemons are running except for the bare minimum: syslog-ng and udev. The single-user mode is useful for system recovery where preventing remote users from doing anything that might cause data loss or damage is necessary. In single-user mode, users can continue with the standard (multi-user) boot by entering 'exit' at the prompt.
/etc/rc.multi
/etc/rc.multi is run on any multi-user runlevel (i.e. 2, 3. 4 and 5) which basically means any ordinary boot. Typically, users will not notice the transition from rc.sysinit to rc.multi as rc.multi also uses the functions file to produce output. This script has three tasks:
- First, it runs sysctl (to modify kernel parameters at runtime) which applies the settings in /etc/sysctl.conf. Arch has very few of these by default; mainly networking settings.
- Secondly, and most importantly, it starts daemons, as per the DAEMONS array in rc.conf.
- Finally, it will run /etc/rc.local.
/etc/rc.local
rc.local is the local multi-user startup script. Empty by default, it is a good place to put any last-minute commands the system should run at the very end of the boot process. Most common system configuration tasks (like loading modules, changing the console font, or setting up devices) usually have a dedicated place where they belong. To avoid confusion, ensure that whatever one intends to add to rc.local is not already residing in /etc/profile.d, or any other existing configuration location instead.
When editing this file, keep in mind that it is run after the basic setup (modules/daemons), as the root user, and whether or not X starts. Here is an example which just un-mutes the ALSA sound settings:
#!/bin/bash # /etc/rc.local: Local multi-user startup script. amixer sset 'Master Mono' 50% unmute &> /dev/null amixer sset 'Master' 50% unmute &> /dev/null amixer sset 'PCM' 75% unmute &> /dev/null
Another common usage for rc.local is to apply various hacks when one cannot make the ordinary initialization work correctly.
init: Login
By default, after the Arch boot scripts are completed, the agetty program prompts users for a login name. After a login name is received, agetty calls login to prompt for the login password.
Finally, with a successful login, the login program starts the user's default shell. The default shell and environment variables may be globally defined within /etc/profile. All variables within a users home directory shall take precedence over those globally defined under /etc. For instance, if two conflicting variables are specified within /etc/profile and ~/.bashrc, the one dictated by ~/.bashrc shall prevail.
Other options include mingetty which allows for auto-login and rungetty which allows for auto-login and automatically running commands and programs, e.g. the always useful htop.
The majority of users wishing to start an X server during the boot process will want to install a display manager, and see Display Manager for details. Alternatively, Start X at Boot outlines methods that do not involve a display manager.