Arch boot process
In order to boot Arch Linux, a Linux-capable boot loader must be set up. The boot loader is responsible for loading the kernel and initial ramdisk before initiating the boot process. The procedure is quite different for BIOS and UEFI systems, the detailed description is given on this or linked pages.
A BIOS or Basic Input-Output System is the very first program (firmware) that is executed once the system is switched on. In most cases it is stored in a flash memory in the motherboard itself and independent of the system storage.
Unified Extensible Firmware Interface has support for reading both the partition table as well as file systems. UEFI does not launch any boot code in the MBR whether it exists or not, instead booting relies on boot entries in NVRAM.
The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.7, section 188.8.131.52), but any conformant vendor can optionally add support for additional filesystems; for example, Apple Macs support (and by default use) their own HFS+ filesystem drivers. UEFI implementations also support ISO-9660 for optical discs.
UEFI launches EFI applications, e.g. boot loaders, boot managers, UEFI shell, etc. These applications are usually stored as files in the EFI system partition. Each vendor can store its files in the EFI system partition under the
/EFI/vendor_name folder. The applications can be launched by adding a boot entry to the NVRAM or from the UEFI shell.
- System switched on, the power-on self-test (POST) is executed.
- After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.).
- BIOS launches the first 440 bytes (the Master Boot Record bootstrap code area) of the first disk in the BIOS disk order.
- The boot loader's first stage in the MBR boot code then launches its second stage code (if any) from either:
- The actual boot loader is launched.
- The boot loader then loads an operating system by either chain-loading or directly loading the operating system kernel.
- System switched on, the power-on self-test (POST) is executed.
- UEFI initializes the hardware required for booting.
- Firmware reads the boot entries in the NVRAM to determine which EFI application to launch and from where (e.g. from which disk and partition).
- Firmware launches the EFI application.
If Secure Boot is enabled, the boot process will verify authenticity of the EFI binary by signature.
Multibooting in UEFI
Since each OS or vendor can maintain its own files within the EFI system partition without affecting the other, multi-booting using UEFI is just a matter of launching a different EFI application corresponding to the particular OS's boot loader. This removes the need for relying on chainloading mechanisms of one boot loader to load another OS.
See also Dual boot with Windows.
- Boot loaders only need to support the file system on which kernel and initramfs reside (the file system on which
- As GPT is part of the UEFI specification, all UEFI boot loaders support GPT disks. GPT on BIOS systems is possible, using either "hybrid booting" with Hybrid MBR, or the new GPT-only protocol. This protocol may however cause issues with certain BIOS implementations; see rodsbooks for details.
- Encryption mentioned in file system support is filesystem-level encryption, it has no bearing on block-level encryption.
|EFISTUB||–||Yes||–||–||–||–||ESP only||–||Kernel turned into EFI executable to be loaded directly from UEFI firmware or another boot loader.|
|Clover||emulates UEFI||Yes||Yes||No||without encryption||No||Yes||No||Fork of rEFIt modified to run macOS on non-Apple hardware.|
|GRUB||Yes||Yes||Yes||without zstd compression||Yes||Yes||Yes||Yes||On BIOS/GPT configuration requires a BIOS boot partition. |
Supports RAID, LUKS1 and LVM (but not thin provisioned volumes).
|rEFInd||No||Yes||Yes||without: encryption, zstd compression||without encryption||without tail-packing feature||Yes||No||Supports auto-detecting kernels and parameters without explicit configuration.|
|Syslinux||Yes||Partial||Partial||without: multi-device volumes, compression, encryption||without encryption||No||Yes||v4 on MBR only||No support for certain file system features |
|systemd-boot||No||Yes||Yes||No||No||No||ESP only||No||Cannot launch binaries from partitions other than ESP.|
|GRUB Legacy||without GPT||No||Yes||No||No||Yes||Yes||v4 only||Discontinued in favor of GRUB.|
|LILO||without GPT||No||Yes||No||without encryption||Yes||Yes||MBR only ||Discontinued due to limitations (e.g. with Btrfs, GPT, RAID).|
See also Wikipedia:Comparison of boot loaders.
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 of many tasks being executed simultaneously.
After the kernel is loaded, it unpacks the initramfs (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes
/init as the first process. The early userspace starts.
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, SATA, USB/FW (if booting from an external drive) must be loadable from the initramfs if not built into the kernel; once the proper modules are loaded (either explicitly via a program or script, or implicitly via udev), the boot process continues. For this reason, the initramfs 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.
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem.
/sbin/init is executed, replacing the
/init process. Arch uses systemd as the default init.
init calls getty once for each virtual terminal (typically six of them), which initializes each tty and asks for a username and password. Once the username and password are provided, getty checks them against
/etc/shadow, then calls login. Alternatively, getty may start a display manager if one is present on the system.
A display manager can be configured to replace the getty login prompt on a tty.
The login program begins a session for the user by setting environment variables and starting the user's shell, based on
The login program displays the contents of /etc/motd (message of the day) after a successful login, just before it executes the login shell. It is a good place to display your Terms of Service to remind users of your local policies or anything you wish to tell them.
Once the user's shell is started, it will typically run a runtime configuration file, such as bashrc, before presenting a prompt to the user. If the account is configured to Start X at login, the runtime configuration file will call startx or xinit.
GUI, xinit or wayland
xinit runs the user's xinitrc runtime configuration file, which normally starts a window manager. When the user is finished and exits the window manager, xinit, startx, the shell, and login will terminate in that order, returning to getty.