Arch Boot Process
From ArchWiki
This is intended to give a brief, chronological overview of the Arch boot process and the system files and processes involved and provide links to the relevant wiki articles. Arch famously follows the BSD init convention as opposed to the distro-standard SysV. What this means, is that there is little distinction between runlevels, since the system by default is set up to use the same modules and run the same processes on all runlevels. The advantage is that you have a simple way to configure your startup process (see rc.conf), the disadvantage is that you lose some finegrained configuration options that SysV offers. See Adding Runlevels for a way to hack some SysV-like capabilities into Arch. See the wikipedia article on init for more on the distinctions between SysV and BSD style.
Contents |
Before init
The BIOS will locate the preferred boot medium and transfer control to the Master Boot Record of this device. On a Linux setup this usually means that either GRUB or LILO is loaded. Either of these will present you with a range of options for boot, e.g. Arch Linux and Microsoft Windows on a dual-boot setup. Once you select Arch in GRUB/LILO, the kernel image in your /boot folder, currently kernel26.img, is decompressed and loaded into memory along with basic memory management. For more about the kernel image in Arch, see initramfs and Configuring mkinitcpio. The goal of this part of the startup process is simply to gain the ability to read and run the main startup process, init. Once the kernel is operational and has handed over control to init, it is then allowed to go idle, subject to calls from other processes.
Init: The Arch boot scripts
The main Arch startup process is run by the program init, that on Unix and Unix-like systems spawns all other processes. It takes its cues from the /etc/inittab file. We can therefore see what happens by looking at the following lines from the default inittab:
rc::sysinit:/etc/rc.sysinit rs:S1:wait:/etc/rc.single rm:2345:wait:/etc/rc.multi
When the kernel calls init,
- First, Arch starts up its main startup script, /etc/rc.sysinit, a Bash script.
- If it's started in single user mode (runlevel 1 or S), it will then run the script /etc/rc.single.
- If it's any other runlevel (2-5), /etc/rc.multi is run instead.
/etc/rc.sysinit
rc.sysinit is a huge startup script that basically takes care of all hardware configuration plus a number of general initialiazation tasks. You can identify it by it's 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
- Display a welcome message
- Mounts various virtual file systems
- Creates dummy device files
- Starts minilogd
- Outputs messages from dmesg
- Configures the hardware clock
- Empty the /proc/sys/kernel/hotplug file
- Starts Udev and checks for Udev events
- Starts the loopback interface
- Load modules from the MODULES array defined in rc.conf
- Configures RAID and encrypted filesystem mappings
- Runs that annoying forced check of your partitions (fsck) if your /etc/fstab file mounts them with instructions to do so.
- Mounts your 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/*
- Configure the locale, console and keyboard mappings
- Sets the console font
- Write 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 colours, 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. By default, your settings files should be insured against overwrites by pacman updates but rc.sysinit will be overwritten with updates.
/etc/rc.single
Single user mode will boot straight into the root user account and should only be used if you cannot boot into your ordinary setup. Where the standard rc.multi script is about starting processes, the rc.single script is mainly concerned with shutting them down to get as barebones a startup as possible. A standard Arch GRUB setup does not include a singe user entry but setting it up is fairly easy (see link below). In single user mode, you can continue with the standard (multi-user) boot by entering 'exit' at the prompt.
/etc/rc.multi
/etc/rc.multi is run on any multiuser runlevel, i.e. 2, 3. 4 and 5, which basically means any ordinary boot. Typically, you will not notice the jump from rc.sysinit to rc.multi as rc.multi also uses the functions file to produce output, and its only functional distinction from the routines of rc.sysinit is that (since loading daemons is not required on a single user user boot) it is not run on runlevel 1. It sources your rc.conf to see your daemons settings. It 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 runs the daemons, as per the DAEMONS array in your rc.conf.
- Finally, it will run /etc/rc.local.
/etc/rc.local
rc.local is a 100% personal script that can contain anyting you want it to and nothing by default. Most startup routines have a rightful place, daemons and modules in rc.conf, X related program in .xinitrc or files specific to your desktop enironment or window manager, etc. rc.local is sort of the doesn't-belong-anywhere-else-file. When editing this file, keep in mind that it is run after your basic setup (modules/daemons), as the root user, and whether or not X starts. Here is an example which just unmutes 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' 74% unmute &> /dev/null
Another common usage for rc.local is to apply various hacks when you cannot make the ordinary initialization work correctly.
Init: Starting a user interface
Once the basic configuration is done, init should launch a user interface (otherwise, what's the point). This is typically either a command line login prompt (also known as a virtual console or a tty) or the X server. Your options here are also specified in the /etc/inittab file.
Command line
If you're not running X, your default inittab will start login prompts on all of the virtual consoles, using agetty. Other options include mingetty which allows for autologin and rungetty which allows for autologin and autmatically running commands and programs, e.g. the always useful htop.
X
The process and scripts involved in starting the X Window System can be somewhat confusing. To simplify, either you have inittab start a display manager, or you use the program xinit to start X directly. The startx script is a front end to xinit that provides a somewhat nicer user interface for running a single session of X. Note that the .xinitrc file is only used when starting X by using xinit/startx, not when X is started indirectly, i.e. by means of a display manager. See DE startup files for startup files specific to various desktop environments.
External resources
- Inside the linux boot process
- Wikipedia: Linux startup process
- Wikipedia: Initramfs
- Boot with GRUB
- Prasetya's guide to tweaking rc.sysinit
- Booting into single user mode from GRUB
- About.com on sysctl.conf
- Search the forum for rc.local examples
- Virtual Consoles in Linux
- xinit manual page
- startx manual page