Difference between revisions of "Arch boot process"

From ArchWiki
Jump to: navigation, search
(Getty: login detailes removed, are in login section already.)
(Under UEFI: wording)
 
(53 intermediate revisions by 8 users not shown)
Line 7: Line 7:
 
[[it:Arch boot process]]
 
[[it:Arch boot process]]
 
[[ja:Arch ブートプロセス]]
 
[[ja:Arch ブートプロセス]]
 +
[[pt:Arch boot process]]
 
[[ru:Arch boot process]]
 
[[ru:Arch boot process]]
 
[[zh-hans:Arch boot process]]
 
[[zh-hans:Arch boot process]]
 
{{Related articles start}}
 
{{Related articles start}}
{{Related|Boot loaders}}
 
 
{{Related|Master Boot Record}}
 
{{Related|Master Boot Record}}
 
{{Related|GUID Partition Table}}
 
{{Related|GUID Partition Table}}
Line 21: Line 21:
 
{{Related articles end}}
 
{{Related articles end}}
  
In order to boot Arch Linux, a Linux-capable [[boot loader]] such as [[GRUB]] or [[Syslinux]] must be installed to the [[Master Boot Record]] or the [[GUID Partition Table]]. The boot loader is responsible for loading the kernel and [[initial ramdisk]] before initiating the boot process. The procedure is quite different for [[Wikipedia:BIOS|BIOS]] and [[UEFI]] systems, the detailed description is given on this or linked pages.
+
In order to boot Arch Linux, a Linux-capable [[#Boot loader|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 [[Wikipedia:BIOS|BIOS]] and [[UEFI]] systems, the detailed description is given on this or linked pages.
  
 
== Firmware types ==
 
== Firmware types ==
 +
 
=== BIOS ===
 
=== BIOS ===
  
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.  
+
{{Expansion|Add information about [[Wikipedia:Unified Extensible Firmware Interface#CSM booting|CSM]].}}
  
The BIOS loads the beginning 512 bytes ([[Master Boot Record]]) of the first valid disk in the BIOS disk order. Of these 512 bytes, the first 440 contains the first stage of a boot loader like [[GRUB]], [[Syslinux]] or [[LILO]]. Since very little can be achieved by a program of this size, the second stage (residing on the next disk sectors) is loaded from here and looks up a file stored on the partition itself (the actual bootloader). This then loads an operating system by either chain-loading or directly loading the operating system kernel.
+
A [[Wikipedia:BIOS|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.
  
 
=== UEFI ===
 
=== UEFI ===
UEFI has support for reading both the partition table as well as understanding filesystems. Hence it is not limited by 440 byte code limitation (MBR boot code) as in BIOS systems. It does not use the MBR boot code at all.
 
  
The commonly used UEFI firmwares support both MBR and GPT [[partition table]]. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Intel Macs can also access HFS/HFS+ filesystems, in addition to the mentioned ones.
+
[[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.
  
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called '''EFI System Partition''' in which files required to be launched by the firmware are stored. Each vendor can store its files under {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32 or (less commonly) FAT16.
+
The UEFI specification mandates support for the [[FAT|FAT12, FAT16, and FAT32]] file systems (see [http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G17.1019485 UEFI specification version 2.7, section 13.3.1.1]), but any conformant vendor can optionally add support for additional filesystems; for example, Apple [[Mac]]s 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 loader|boot loaders]], boot managers, [[Unified Extensible Firmware Interface#UEFI Shell|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 {{ic|/EFI/''vendor_name''}} folder. The applications can be launched by adding a boot entry to the NVRAM or from the UEFI shell.
  
 
== System initialization ==
 
== System initialization ==
Line 41: Line 43:
 
=== Under BIOS ===
 
=== Under BIOS ===
  
# System switched on - [[Wikipedia:Power-on self-test|Power-on self-test]] or POST process
+
# System switched on, the [[Wikipedia:Power-on self-test|power-on self-test (POST)]] is executed.
# After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.)
+
# After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.).
# BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order
+
# BIOS launches the first 440 bytes ([[Partitioning#Master Boot Record (bootstrap code)|the Master Boot Record bootstrap code area]]) of the first disk in the BIOS disk order.
# The MBR boot code then takes control from BIOS and launches its next stage code (if any) (mostly [[boot loader]] code)
+
# The boot loader's first stage in the MBR boot code then launches its second stage code (if any) from either:
# The launched actual boot loader
+
#* next disk sectors after the MBR, i.e. the so called post-MBR gap (only on a MBR partition table).
 +
#* a partition's or a partitionless disk's [[Wikipedia:Volume boot record|volume boot record (VBR)]].
 +
#* the [[BIOS boot partition]] ([[GRUB]] on BIOS/GPT only).
 +
# The actual [[#Boot loader|boot loader]] is launched.
 +
# The boot loader then loads an operating system by either chain-loading or directly loading the operating system kernel.
  
 
=== Under UEFI ===
 
=== Under UEFI ===
  
# System switched on. The Power On Self Test (POST) is executed.
+
# System switched on, the [[Wikipedia:Power-on self-test|power-on self-test (POST)]] is executed.
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.
+
# UEFI initializes the hardware required for booting.
# Firmware reads the boot entries in the firmware's boot manager to determine which UEFI application to be launched and from where (i.e. from which disk and partition).
+
# 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 UEFI application.
+
#* 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 a EFI application in the fallback boot path {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} on [[Unified Extensible Firmware Interface#UEFI firmware bitness|systems with a IA32 (32-bit) UEFI]]). This is how UEFI bootable removable media work.
#* This could be the Arch kernel itself (since [[EFISTUB]] is enabled by default).
+
# Firmware launches the EFI application.
#* It could be some other application such as a shell or a graphical boot manager.
+
#* This could be a [[#Boot loader|boot loader]] or the Arch [[kernel]] itself using [[EFISTUB]].
#* Or the boot entry could simply be a disk. In this case the firmware looks for an [[EFI System Partition]] on that disk and tries to run the fallback UEFI application {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} on 32-bit systems). This is how UEFI bootable thumb drives work.
+
#* It could be some other EFI application such as a UEFI shell or a [[#Boot loader|boot manager]] like [[systemd-boot]] or [[rEFInd]].
  
 
If [[Secure Boot]] is enabled, the boot process will verify authenticity of the EFI binary by signature.
 
If [[Secure Boot]] is enabled, the boot process will verify authenticity of the EFI binary by signature.
  
{{Note|On some (poorly-designed) UEFI systems the only way to boot is using a disk boot entry with the fallback UEFI application path.}}
+
{{Note|Some UEFI systems can only boot from the fallback boot path.}}
  
 
=== Multibooting in UEFI ===
 
=== 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 UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one [[boot loader]] to load another OS.
+
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|boot loader]] to load another OS.
  
 
See also [[Dual boot with Windows]].
 
See also [[Dual boot with Windows]].
Line 69: Line 75:
 
== Boot loader ==
 
== Boot loader ==
  
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] based on config files.  
+
{{Expansion|Explain the difference between a boot loader and a boot manager.}}
 +
 
 +
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] based on config files.
 +
 
 +
{{Note|Loading [[Microcode]] updates requires adjustments in boot loader configuration. [https://www.archlinux.org/news/changes-to-intel-microcodeupdates/]}}
 +
 
 +
=== Feature comparison ===
 +
 
 +
{{Note|
 +
* Boot loaders only need to support the file system on which kernel and initramfs reside (the file system on which {{ic|/boot}} is located).
 +
* 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 [https://www.rodsbooks.com/gdisk/hybrid.html Hybrid MBR], or the new [http://repo.or.cz/syslinux.git/blob/HEAD:/doc/gpt.txt GPT-only] protocol. This protocol may however cause issues with certain BIOS implementations; see [http://www.rodsbooks.com/gdisk/bios.html#bios rodsbooks] for details.
 +
* Encryption mentioned in file system support is [[wikipedia:Filesystem-level encryption|filesystem-level encryption]], it has no bearing on [[dm-crypt|block-level encryption]].
 +
}}
 +
 
 +
{| class="wikitable sortable"
 +
! rowspan="2"| Name
 +
! colspan="2"| Firmware
 +
! rowspan="2"| Multi-boot
 +
! colspan="5"| [[File systems]]
 +
! rowspan="2"| Notes
 +
|-
 +
! BIOS !! [[UEFI]]
 +
! [[Btrfs]] !! [[ext4]] !! ReiserFS v3 !! [[VFAT]] !! [[XFS]]
 +
|-
 +
! [[EFISTUB]]
 +
| {{-}} || {{Yes}}
 +
| {{-}}
 +
| {{-}} || {{-}} || {{-}} || {{Y|ESP only}} || {{-}}
 +
| Kernel turned into EFI executable to be loaded directly from [[UEFI]] firmware or another boot loader.
 +
|-
 +
! [[Clover]]
 +
| {{G|emulates UEFI}} || {{Yes}}
 +
| {{Yes}}
 +
| {{No}} || {{Y|without encryption}} || {{No}} || {{Yes}} || {{No}}
 +
| Fork of rEFIt modified to run [[wikipedia:Hackintosh|macOS on non-Apple hardware]].
 +
|-
 +
! [[GRUB]]
 +
| {{Yes}} || {{Yes}}
 +
| {{Yes}}
 +
| {{Y|without zstd compression}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
 +
| On BIOS/GPT configuration requires a [[BIOS boot partition]]. <br/>Supports RAID, LUKS1 and LVM (but not thin provisioned volumes).
 +
|-
 +
! [[rEFInd]]
 +
| {{No}} || {{Yes}}
 +
| {{Yes}}
 +
| {{Y|without: encryption, zstd compression}} || {{Y|without encryption}} || {{Y|without tail-packing feature}} || {{Yes}} || {{No}}
 +
| Supports auto-detecting kernels and parameters without explicit configuration.
 +
|-
 +
! [[Syslinux]]
 +
| {{Yes}} || {{Y|[[Syslinux#Limitations_of_UEFI_Syslinux|Partial]]}}
 +
| {{Y|[[Syslinux#Chainloading|Partial]]}}
 +
| {{Y|without: multi-device volumes, compression, encryption}} || {{Y|without encryption}} || {{No}} || {{Yes}} || {{Y|v4 on [[MBR]] only}}
 +
| No support for certain [[file system]] features [http://www.syslinux.org/wiki/index.php?title=Filesystem]
 +
|-
 +
! [[systemd-boot]]
 +
| {{No}} || {{Yes}}
 +
| {{Yes}}
 +
| {{No}} || {{No}} || {{No}} || {{Y|ESP only}} || {{No}}
 +
| Cannot launch binaries from partitions other than [[ESP]].
 +
|-
 +
! {{Grey|[[GRUB Legacy]]}}
 +
| {{Y|without GPT}} || {{No}}
 +
| {{Yes}}
 +
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Y|v4 only}}
 +
| [https://www.gnu.org/software/grub/grub-legacy.html Discontinued] in favor of [[GRUB]].
 +
|-
 +
! {{Grey|[[LILO]]}}
 +
| {{Y|without GPT}} || {{No}}
 +
| {{Yes}}
 +
| {{No}} || {{Y|without encryption}} || {{Yes}} || {{Yes}} || {{Y|MBR only [http://xfs.org/index.php/XFS_FAQ#Q:_Does_LILO_work_with_XFS.3F]}}
 +
| [http://web.archive.org/web/20180323163248/http://lilo.alioth.debian.org/ Discontinued] due to limitations (e.g. with Btrfs, GPT, RAID).
 +
|}
 +
 
 +
See also [[Wikipedia:Comparison of boot loaders]].
  
 
== Kernel ==
 
== Kernel ==
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.
+
 
 +
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.
  
 
== initramfs ==
 
== initramfs ==
 +
 
After the kernel is loaded, it unpacks the [[initramfs]] (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes {{ic|/init}} as the first process. The ''early userspace'' starts.
 
After the kernel is loaded, it unpacks the [[initramfs]] (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes {{ic|/init}} as the first process. The ''early userspace'' starts.
  
Line 80: Line 161:
  
 
== Init process ==
 
== Init process ==
 +
 
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem. {{ic|/sbin/init}} is executed, replacing the {{ic|/init}} process. Arch uses [[systemd]] as the default [[init]].
 
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem. {{ic|/sbin/init}} is executed, replacing the {{ic|/init}} process. Arch uses [[systemd]] as the default [[init]].
  
 
== Getty ==
 
== Getty ==
 +
 
[[init]] calls [[getty]] once for each [[Wikipedia:Virtual console|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 {{ic|/etc/passwd}} and {{ic|/etc/shadow}}, then calls [[#Login|login]]. Alternatively, getty may start a display manager if one is present on the system.
 
[[init]] calls [[getty]] once for each [[Wikipedia:Virtual console|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 {{ic|/etc/passwd}} and {{ic|/etc/shadow}}, then calls [[#Login|login]]. Alternatively, getty may start a display manager if one is present on the system.
  
 
== Display Manager ==
 
== Display Manager ==
 +
 +
{{Style|A display manager is also a GUI, see [[#GUI, xinit or wayland]]}}
 +
 
A [[display manager]] can be configured to replace the getty login prompt on a tty.
 
A [[display manager]] can be configured to replace the getty login prompt on a tty.
  
 
== Login ==
 
== Login ==
 +
 
The ''login'' program begins a session for the user by setting environment variables and starting the user's shell, based on {{ic|/etc/passwd}}.
 
The ''login'' program begins a session for the user by setting environment variables and starting the user's shell, based on {{ic|/etc/passwd}}.
  
=== Message of the day ===
+
The ''login'' program displays the contents of [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) 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.
  
The ''login'' program displays the contents of [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) after a successful login, just before it executes the login shell.
+
== 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]].
  
== Shell ==
+
== GUI, xinit or wayland ==
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]].
 
  
== xinit ==
 
 
[[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.
 
[[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.
  
 
== See also ==
 
== See also ==
 +
 
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]
 
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]
 
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]
 
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]
 
 
* [[Wikipedia:Linux startup process]]
 
* [[Wikipedia:Linux startup process]]
 
* [[Wikipedia:initrd]]
 
* [[Wikipedia:initrd]]
 
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]
 
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]
 
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]
 
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]
 +
* [https://www.linux.com/learn/kernel-newbie-corner-initrd-and-initramfs-whats Kernel Newbie Corner: initrd and initramfs]
 +
* [http://www.rodsbooks.com/efi-bootloaders/ Rod Smith - Managing EFI Boot Loaders for Linux]

Latest revision as of 09:12, 11 November 2018

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.

Firmware types

BIOS

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Add information about CSM. (Discuss in Talk:Arch boot process#)

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.

UEFI

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 13.3.1.1), 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 initialization

Under BIOS

  1. System switched on, the power-on self-test (POST) is executed.
  2. After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.).
  3. BIOS launches the first 440 bytes (the Master Boot Record bootstrap code area) of the first disk in the BIOS disk order.
  4. The boot loader's first stage in the MBR boot code then launches its second stage code (if any) from either:
  5. The actual boot loader is launched.
  6. The boot loader then loads an operating system by either chain-loading or directly loading the operating system kernel.

Under UEFI

  1. System switched on, the power-on self-test (POST) is executed.
  2. UEFI initializes the hardware required for booting.
  3. 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 a 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.
  4. Firmware launches the EFI application.

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.

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 loader

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Explain the difference between a boot loader and a boot manager. (Discuss in Talk:Arch boot process#)

The boot loader is the first piece of software started by the BIOS or UEFI. It is responsible for loading the kernel with the wanted kernel parameters, and initial RAM disk based on config files.

Note: Loading Microcode updates requires adjustments in boot loader configuration. [1]

Feature comparison

Note:
  • Boot loaders only need to support the file system on which kernel and initramfs reside (the file system on which /boot is located).
  • 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.
Name Firmware Multi-boot File systems Notes
BIOS UEFI Btrfs ext4 ReiserFS v3 VFAT XFS
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 [2]
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 [3] Discontinued due to limitations (e.g. with Btrfs, GPT, RAID).

See also Wikipedia:Comparison of boot loaders.

Kernel

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.

initramfs

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.

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.

Getty

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/passwd and /etc/shadow, then calls login. Alternatively, getty may start a display manager if one is present on the system.

Display Manager

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Reason: A display manager is also a GUI, see #GUI, xinit or wayland (Discuss in Talk:Arch boot process#)

A display manager can be configured to replace the getty login prompt on a tty.

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.

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.

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.

See also