Arch boot process - ArchWiki https://wiki.archlinux.

org/title/Arch_boot_process#Boot_loader

Arch boot process

(Redirected from Boot loader)
In order to boot Arch Linux, a Linux-capable boot loader must be set up. The boot loader is Related articles
responsible for loading the kernel and initial ramdisk before initiating the boot process. The
procedure is quite different for BIOS and UEFI systems. A detailed description is given on this or Master Boot Record
linked pages. GUID Partition Table
Unified Extensible Firmware
1 Firmware types Interface
The firmware is the very first program that is executed once the system is switched on. mkinitcpio
init
Tip: The words BIOS and UEFI are often used instead of firmware.
systemd
fstab
1.1 UEFI Autostarting
The Unified Extensible Firmware Interface has support for reading both the partition table as
well as file systems. UEFI does not launch any boot code from the Master Boot Record (MBR) whether it exists or not, instead
booting relies on boot entries in the NVRAM.

The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.10,
section 13.3.1.1 (https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1)), but any conformant
vendor can optionally add support for additional file systems; for example, HFS+ or APFS in some Apple's firmwares. 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 directory. The
applications can be launched by adding a boot entry to the NVRAM or from the UEFI shell.

The UEFI specification has support for legacy BIOS booting with its Compatibility Support Module (CSM). If CSM is enabled in the
UEFI, the UEFI will generate CSM boot entries for all drives. If a CSM boot entry is chosen to be booted from, the UEFI's CSM will
attempt to boot from the drive's MBR bootstrap code.

Note: Intel is phasing out support for CSM, relying on the feature may not be feasible in the future.[1] (https://www.intel.com/co
ntent/dam/support/us/en/documents/intel-nuc/Legacy-BIOS-Boot-Support-Removal-for-Intel-Platforms.pdf)

1.2 BIOS
A BIOS or Basic Input-Output System is in most cases stored in a flash memory in the motherboard itself and independent of the
system storage. Originally created for the IBM PC to handle hardware initialization and the boot process, it has been replaced
progressively since 2010 by UEFI which does not suffer from the same technical limitations.

2 System initialization
System switched on, the power-on self-test (POST) is executed. See also Modern CPUs have a backstage cast (https://www.deveve
r.net/~hl/backstage-cast) by Hugo Landau.

2.1 UEFI
1. After POST, UEFI initializes the hardware required for booting (disk, keyboard controllers etc.).
2. 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).

▪ A boot entry could simply be a disk. In this case the firmware looks for an EFI system partition on that disk and tries to find an
EFI application in the fallback boot path \EFI\BOOT\BOOTx64.EFI ( BOOTIA32.EFI on systems with a IA32 (32-bit) UEFI).
This is how UEFI bootable removable media work.
3. Firmware launches the EFI application.

▪ This could be a boot loader or the Arch kernel itself using an EFI boot stub.
▪ It could be some other EFI application such as the UEFI shell or a boot manager like systemd-boot or rEFInd.
If Secure Boot is enabled, the boot process will verify authenticity of the EFI binary by signature.

Note: Some UEFI systems can only boot from the fallback boot path.

2.1.1 Multibooting

1 of 5 2/14/25, 11:53 AM
Arch boot process - ArchWiki https://wiki.archlinux.org/title/Arch_boot_process#Boot_loader

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 operating system's boot loader. This
removes the need for relying on the chain loading mechanisms of one boot loader to load another OS.

See also Dual boot with Windows.

2.2 BIOS
1. After POST, BIOS initializes the hardware required for booting (disk, keyboard controllers etc.).
2. BIOS launches the first 440 bytes (the Master Boot Record bootstrap code area) of the first disk in the BIOS disk order.
3. The boot loader's first stage in the MBR boot code then launches its second stage code (if any) from either:

▪ next disk sectors after the MBR, i.e. the so called post-MBR gap (only on a MBR partition table),
▪ a partition or a partitionless disk volume boot record (VBR),
▪ for GRUB on a GPT partitioned disk—a GRUB-specific BIOS boot partition (it is used in place of the post-MBR gap that does
not exist in GPT).
4. The actual boot loader is launched.
5. The boot loader then loads an operating system by either chain-loading or directly loading the operating system kernel.

3 Boot loader
A boot loader is a piece of software started by the firmware (BIOS or UEFI). It is responsible for loading the kernel with the wanted
kernel parameters and any external initramfs images. In the case of UEFI, the kernel itself can be directly launched by the UEFI
using the EFI boot stub. A separate boot loader or boot manager can still be used for the purpose of editing kernel parameters
before booting.

Warning: To successfully boot Arch, the boot loader needs access to the kernel and initramfs image(s) which typically reside in
the /boot directory. That means the boot loader must have support for everything starting from the block devices, stacked block
devices (LVM, RAID, dm-crypt, LUKS, etc.) and ending with the file system on which the kernel(s) and initramfs image(s) reside.
Since almost no boot loader supports such stacked block devices and since file systems can introduce new features which may
not yet be supported by any boot loader (e.g. archlinux/packaging/packages/grub#7 (https://gitlab.archlinux.org/archlinux/pa
ckaging/packages/grub/-/issues/7), FS#79857 (https://bugs.archlinux.org/task/79857), FS#59047 (https://bugs.archlinux.org/ta
sk/59047), FS#58137 (https://bugs.archlinux.org/task/58137), FS#51879 (https://bugs.archlinux.org/task/51879), FS#46856 (htt
ps://bugs.archlinux.org/task/46856), FS#38750 (https://bugs.archlinux.org/task/38750), FS#21733 (https://bugs.archlinux.org/
task/21733) and fscrypt encrypted directories), using a separate /boot partition with a universally supported file system, such as
FAT32, is oftentimes more feasible.

3.1 Feature comparison

Note:

▪ 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 (https://www.rodsbooks.com/gdisk/hybrid.html), or the new GPT-only (https://repo.or.c
z/syslinux.git/blob/HEAD:/doc/gpt.txt) protocol. This protocol may however cause issues with certain BIOS implementations;
see rodsbooks (https://www.rodsbooks.com/gdisk/bios.html#bios) for details.
▪ As Secure Boot is part of the UEFI specification, all UEFI boot loaders support it, although some have limitations.

2 of 5 2/14/25, 11:53 AM
Arch boot process - ArchWiki https://wiki.archlinux.org/title/Arch_boot_process#Boot_loader

Firmware Partition table Multi-

Name File systems Notes
BIOS UEFI MBR GPT boot

Clover Yes Yes No Yes Yes – Can emulate UEFI on legacy BIOS systems.

The kernel is a valid EFI executable which can

EFI boot Inherited from
– Yes1 Yes Yes – be directly launched from UEFI or from
stub firmware2
another UEFI boot loader.

Supports RAID, LUKS (but not Argon2

PBKDFs) and LVM (but not thin provisioned
GRUB Yes Yes3 Yes Yes Yes Built-in
volumes). See GRUB for setup-specific
limitations.

Limine Yes Yes3 Yes Yes Yes Limited

Supports auto-detecting kernels and

parameters without explicit configuration,
rEFInd No Yes Yes Yes Yes4 Extensible2,5
and supports fastboot [2] (https://bbs.archli
nux.org/viewtopic.php?id=258805).

No support for certain file system features.

Syslinux Yes Partial1 Yes Yes Partial Limited Can only access the file system it was
installed to.

Can only launch binaries from the ESP it is

Manual (http
installed to or from the Extended Boot
s://github.com/
systemd- Loader Partition (XBOOTLDR partition) on the
No Yes3 systemd/syste Yes Yes4 Extensible2,5
boot same disk.
md/issues/112
Automatically detects unified kernel images
5)
placed in esp/EFI/Linux/ .

systemd-stub(7) (https://man.archli
Unified nux.org/man/systemd-stub.7), a kernel,
Inherited from
kernel – Yes3 Yes Yes – initramfs and kernel command line packed
firmware2
image into EFI executable to be loaded directly from
UEFI firmware or another boot loader.

Discontinued (https://www.gnu.org/softw
GRUB
Yes No Yes No Yes Limited are/grub/grub-legacy.html) in favor of
Legacy
GRUB.

Partial (https://salsa.de
bian.org/joowie-guest/ Discontinued (https://web.archive.org/we
upstream_lilo/-/commi b/20180323163248/http://lilo.alioth.debia
LILO Yes No Yes Yes Limited
t/29a64e6b92cac22d47 n.org/) due to limitations (e.g. with Btrfs,
2f4b352de5b1535e4afc GPT, RAID, encryption).
5f)

1. While the binary can be signed for Secure Boot, it does no following verification, thus breaking the chain of trust.
2. File system support is inherited from the firmware. The UEFI specification mandates support for the FAT12, FAT16 and FAT32 file
systems[3] (https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1), but vendors can
optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system. If the
firmware provides an interface for loading UEFI drivers on startup, then support for additional file systems can be added by
loading (independently acquired) file system drivers.
3. Supports mixed mode booting. I.e. it can boot a 64-bit x86_64 Linux kernel on 32-bit IA32 UEFI.
4. A boot manager (https://www.rodsbooks.com/efi-bootloaders/principles.html). It can only launch other EFI applications, for
example, Linux kernel images built with CONFIG_EFI_STUB=y and Windows Boot Manager (https://learn.microsoft.com/en-u
s/windows-hardware/drivers/bringup/boot-and-uefi#understanding-the-windows-boot-manager) ( bootmgfw.efi ).
5. Supports loading UEFI file system drivers.
See also Wikipedia:Comparison of boot loaders.

4 Kernel
The boot loader boots the vmlinux image containing the kernel.

The kernel functions on a low level (kernelspace) interacting between the hardware of the machine and the programs. The kernel
initially performs hardware enumeration and initialization before continuing to userspace. See Wikipedia:Kernel (operating
system) and Wikipedia:Linux kernel for a detailed explanation.

5 initramfs
The root file system at / starts out as an empty rootfs (https://docs.kernel.org/filesystems/ramfs-rootfs-initramfs.html), which
is a special instance of ramfs or tmpfs. This is the temporary root file system where the initramfs (initial RAM file system) images
will be unpacked to.

The main purpose of the initramfs is to bootstrap the system to the point where it can access the root file system (see FHS for
details). This includes setting up the storage stack where the root file system may be lying on, e.g. through dm-crypt, dm-verity,

3 of 5 2/14/25, 11:53 AM
Arch boot process - ArchWiki https://wiki.archlinux.org/title/Arch_boot_process#Boot_loader

systemd-repart(8) (https://man.archlinux.org/man/systemd-repart.8), etc. It also resolves the persistent block device

names to real device through udev. It does not need to contain every module one would ever want to use; it should only have
modules required for the root device like NVMe, SATA, SAS, eMMC or USB (if booting from an external drive) and encryption. The
majority of modules will be loaded later on by udev after switching root into the root file system, during the init process.

First, the kernel unpacks its builtin initramfs into the temporary root. Arch Linux's official kernels use an empty archive for the
builtin initramfs, which is the default when building Linux. Then, the kernel unpacks external initramfs files specified by the
command line passed by the boot loader, overwriting any files from the embedded initramfs. These external initramfs images can
be generated with mkinitcpio, dracut or booster, and are Arch's preferred method for setting up for early userspace.

Note that the initramfs serves more than setting up the root file system. There are tasks that can only be performed before the root
file system is mounted, such as fsck and resuming from hibernation.

Also, the Linux kernel pins (https://github.com/torvalds/linux/blob/1b907d0507354b74a4f2c286380cd6059af79248/fs/namespac

e.c#L4222) the original root it is started from. If an initramfs is not used, the real root file system could end up failing to be cleanly
unmounted during shutdown.

6 Early userspace
The early userspace stage takes place while the temporary rootfs is mounted, operating on the files provided by the #initramfs.

The function of early userspace is configurable, but generally does the following:

▪ systemd-modules-load(8) (https://man.archlinux.org/man/systemd-modules-load.8) loads kernel modules, such as

any block device modules needed to mount the real root file system.
▪ Handle decryption of the real root file system, if applicable.
▪ Load the DRM module, as early KMS is enabled by default for in-tree modules.
At the final stage of early userspace, the real root is mounted at /sysroot/ (in case of a systemd-based initramfs) or at
/new_root/ (in case of a busybox-based one), and then switched to by using systemctl switch-root when using systemd-
based initramfs or switch_root(8) (https://man.archlinux.org/man/switch_root.8) when using busybox-based
initramfs. The late userspace starts by executing the init program from the real root file system.

7 Late userspace
The startup of late userspace is executed by the init process. Arch officially uses systemd which is built on the concept of units and
services, but the functionality described here largely overlaps with other init systems.

7.1 getty
The init process calls getty once for each virtual terminal (typically six of them). getty initializes each terminal and protects it from
unauthorized access. When the username and password are provided, getty checks them against /etc/passwd and
/etc/shadow , then calls login(1) (https://man.archlinux.org/man/login.1).

7.1.1 Login
The login program begins a session for the user by setting environment variables and starting the user's shell, based on
/etc/passwd . 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.

7.1.2 Shell
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. Jump to #Graphical
session (Xorg) for the end.

7.2 Display manager

Additionally, init can be configured to start a display manager instead of getty on a specific virtual terminal. This requires
manually enabling its systemd service file. The display manager then starts a graphical session.

7.2.1 Graphical session (Xorg)

xinit runs the user's xinitrc runtime configuration file, which normally starts a window manager or a desktop environment.
When the user is finished and exits, xinit, startx, the shell, and login will terminate in that order, returning to getty or the display
manager.

8 See also
▪ Wikipedia:Booting process of Linux
▪ Inside the Linux boot process (https://web.archive.org/web/20230313210814/https://developer.ibm.com/articles/l-linuxboo

4 of 5 2/14/25, 11:53 AM
Arch boot process - ArchWiki https://wiki.archlinux.org/title/Arch_boot_process#Boot_loader

t/)
▪ Rod Smith - Managing EFI Boot Loaders for Linux (https://www.rodsbooks.com/efi-bootloaders/)
▪ NeoSmart: The BIOS/MBR Boot Process (https://neosmart.net/wiki/mbr-boot-process/)
▪ Lennart Poettering - Linux Boot Partitions and How to Set Them Up (https://0pointer.net/blog/linux-boot-partitions.html)
▪ Wikipedia:initrd
▪ Early Userspace in Arch Linux (https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-
userspace-in-arch-linux/)
▪ Kernel Newbie Corner: initrd and initramfs (https://www.linux.com/learn/kernel-newbie-corner-initrd-and-initramfs-what
s)
▪ bootup(7) (https://man.archlinux.org/man/bootup.7) (mostly about the systemd initrd + userspace portion)

Retrieved from "https://wiki.archlinux.org/index.php?title=Arch_boot_process&oldid=826889#Boot_loader"

5 of 5 2/14/25, 11:53 AM