- Grand Unified Boot Loader (GRUB)
- The Boot Process
- Troubleshooting
- Documentation
Boot-related problems can be difficult to resolve. Having a better understanding of the boot process will help you troubleshoot and address these issues.
Note: If you are not familiar with the GNU/Linux command line interface, review the Conventions page before proceeding.
Grand Unified Boot Loader (GRUB)
A bootloader is the program that is responsible for booting up a system, i.e., bootstrapping it. It does this my accessing the device that contains an operating system and data, and loading it into memory (RAM).
The GNU Grand Unified Boot Loader (GRUB) is the dominant bootloader for GNU/Linux systems.
Bootloaders Versus Boot Managers
Besides from being a bootloader, GRUB is also a boot manager, i.e., it offers the end user the ability to launch various Linux kernels or operating systems, and to configure how they are launched. A boot manager is a kind of bootloader.
GRUB can directly load and start most UNIX-like operating systems for x86 computers, including:
Chainloading
GRUB can start multi-boot incompatible systems (e.g., Windows) by invoking the bootloader of the operating system in question via chain loading.
For example, the following GRUB menu entry is for a Windows installation on the third partition of a disk:
menuentry "Windows" {
insmod chain
insmod ntfs
set root=(hd0,msdos3)
chainloader +1
}
The +1
option to chainloader
tells it to load whatever is at the first sector of a partition. You can also tell GRUB to directly load a file by using a line like this to load the io.sys
MS-DOS loader:
menuentry "DOS" {
insmod chain
insmod fat
set root=(hd0,msdos3)
chainloader /io.sys
}
Booting From CD-ROMS and USB Keys
Booting off of CD-ROMs follows different rules than booting off of hard disks. The El Torito standard defines these rules using two approaches:
- Floppy Emulation Mode Boot information is stored in an image file of a FAT-formatted floppy disk, which the firmware finds and boots from the CD, and then behaves as a virtual floppy disk. This mode uses SYSLINUX.
- Hard Disk Emulation Mode Boot information is stored in an image file of a FAT-formatted hard disk, which the firmware finds and boots from the CD, and then behaves as a virtual hard disk. This mode uses SYSLINUX.
- No Emulation Mode Boot information is stored directly on the CD (not in a floppy image) and the firmware boots directly off of the CD. This mode uses ISOLINUX.
Often, SYSLINUX is also used for the creation of live USB keys.
Network Boot
With the correct hardware and software (which is usually integrated into a system's firmware), a computer can boot via the network. The kernel, root file system, and everything else can reside on a remote server, and the computer can be diskless.
GRUB Disk/Partition Addressing Scheme
The GRUB addressing scheme for disks and partitions is distinct from the GNU/Linux addressing scheme. In GRUB, disk numbering starts at 0
(e.g., hd0
, hd1
) and partition numbering starts at 1
(msdos1
, msdos2
).
GRUB Boot Volume
The GRUB boot volume (also referred to as the GRUB root or the GRUB core) is the location where GRUB searches for the kernel and the initial ramdisk (initrd for Debian or initramfs for Fedora) image files. Usually, the GRUB boot volume is located at /boot/
.
For every Linux kernel located in /boot/
, there will be four files:
vmlinuz
The compressed Linux kernel.initrd
orinitramfs
The initial ramdisk.config
The kernel configuration file. Used for debugging and bookkeeping.System.map
The kernel symbol table. Used for debugging.
/boot/
is also where GRUB's directory is located. The exact location of GRUB's directory will differ depending on your GNU/Linux distribution. For example, Debian has it located at /boot/grub/
, while Fedora has it located at /boot/grub2/
. This directory contains, among other objects, GRUB's configuration file, /boot/grub/grub.cfg
(Debian) or /boot/grub2/grub.cfg
(Fedora; /boot/efi/EFI/fedora/grub.cfg
for UEFI-based systems).
How GRUB bootstraps a system depends on its firmware type (e.g., Basic Input Output System (BIOS), Unified Extensible Firmware Interface (UEFI)) and whether the disk in question is a Master Boot Record (MBR) disk or a GUID Partition Table (GPT) disk.
The GRUB boot volume can be located in one of three places:
- Partially located between the MBR and the beginning of the first partition (this is the Stage 2 bootloader in a MBR disk; the Stage 1 bootloader is the first 446 bytes of the MBR; the rest of the MBR is the partition table)
- In a regular partition
- In a special boot partition (e.g., a GPT Boot Partition, EFI System Partition (ESP), or elsewhere)
BIOS-Based GRUB Boot
On both a MBR and GPT disk, GRUB is broken up into 4 stages.

- The Stage 1 bootloader (
/boot/grub/ex_architecture/boot.img
for Debian or/boot/grub2/ex_architecture/boot.img
for Fedora) is stored inside the MBR or a partition's boot sector, and addressesdiskboot.img
via a 64-bit logical block addressing (LBA) address.ex_architecture
's value will depend on your system's processor architecture (e.g.,i386-pc
). - The Stage 2 bootloader is the first sector of
/boot/grub/ex_architecture/core.img
(Debian) or/boot/grub2/ex_architecture/core.img
(Fedora), i.e.,diskboot.img
, and is either stored between the MBR and the first partition (MBR disks) or inside the GPT Boot Partition (GPT disks). It loads the rest ofcore.img
identified by LBA sector numbers written bygrub-install
(Debian) orgrub2-install
(Fedora).core.img
itself consists of the kernel of GRUB (this provides device and file access, processing a command line, arbitrary list of modules, etc.) and file system modules to reach/boot/grub/
(Debian) or/boot/grub2/
(Fedora). -
The Stage 3 bootloader is when
/boot/grub/ex_architecture/core.img
(Debian) or/boot/grub2/ex_architecture/core.img
(Fedora) enters 32-bit protected mode, uncompresses itself, and loads/boot/grub/ex_architecture/normal.mod
(Debian) or/boot/grub2/ex_architecture/normal.mod
(Fedora).If the partition index has changed, GRUB will not be able to find
normal.mod
and will present you with the GRUB Rescue prompt, where you will have the opportunity to find and loadnormal.mod
or the Linux kernel. -
The Stage 4 bootloader (
/boot/grub/ex_architecture/normal.mod
for Debian or/boot/grub2/ex_architecture/normal.mod
for Fedora) parses/boot/grub/grub.cfg
(Debian) or/boot/grub2/grub.cfg
(Fedora;/boot/efi/EFI/fedora/grub.cfg
for UEFI-based systems), optionally loads modules for advanced functionality, and displays the GRUB menu. The modules can be found in/boot/grub/ex_architecture/
(Debian) or/boot/grub2/ex_architecture/
(Fedora).
UEFI-Based GRUB Boot
Unified Extensible Firmware Interface (UEFI) systems do not use boot sectors. Instead, the UEFI firmware itself contains a boot manager that uses information about operating systems held in non-volatile RAM (NVRAM). Bootloaders for different operating systems are stored as regular files on an EFI System Partition (ESP), which is a special file system that is usually mounted at /boot/efi/
.
The ESP contains a /boot/efi/EFI/
directory, where each bootloader has its own identifier and a corresponding subdirectory (e.g., /boot/efi/EFI/microsoft/
, /boot/efi/EFI/apple/
). The UEFI firmware can read and start the bootloaders stored in /boot/efi/EFI/
.
For systems using GRUB, the UEFI firmware directly loads /boot/efi/EFI/ex_distribution/grubx64.efi
. If the system does not find the name of the desired bootloader in NVRAM, it falls back to the default name, /boot/efi/EFI/BOOT/BOOTX64.EFI
(where X64
stands for 64-bit Intel-style PC).
The ESP must officially contain a FAT32 file system. Generall, a size of 100 mebibytes is sufficient, but some UEFI implementations have trouble with FAT32 ESPs that are smaller than 512 mebibytes. Therefore, it is best to have an ESP of around 550 mebibytes.
Some UEFI-based systems allow BIOS-style booting from MBR-partitioned disks, i.e., those with a boot sector. This is called Compatibility Support Module (CSM). This mode may be automatically used if a traditional MBR is found on the first recognized hard disk, which precludes a UEFI boot from an ESP on a MBR-partitioned disk. Intel is in the process of phasing out CSM.
It is possible to produce CD-ROMs that boot via UEFI on UEFI-based systems, as well.
UEFI Secure Boot
UEFI Secure Boot is an attempt to prevent computers from being infected with root kits, i.e., malware that usurps the bootstrap process and takes control before the operating system is started. It was promulgated by Microsoft in 2011 prior to their release of Windows 8.
In this paradigm, the firmware (i.e., the UEFI) refuses to start bootloaders that have not been cryptographically signed using an appropriate key. In turn, approved bootloaders are responsible for only launching operating system kernels that have been cryptographically signed using an appropriate key, and approved operating system kernels are expected to insist that dynamically loadable drivers are signed with the correct digital signatures.
GNU/Linux distributions support UEFI Secure Boot in various ways. Distributions like Debian and Fedora work with UEFI Secure Boot by default.
A way to use Secure Boot, but mitigate Microsoft involvement, is provided by Shim (1, 2), which is a Stage 1 bootloader for UEFI systems. Shim can be signed by Microsoft, but does not have to be. UEFI starts Shim and Shim starts another bootloader or operating system kernel, which can be signed or unsigned. Also, you can install your own keys and sign your own self-compiled kernels.
An alternative to Secure Boot is Purism's PureBoot, which uses Free/Libre Open Source Software (FLOSS). Specifically, PureBoot uses:
- coreboot FLOSS firmware meant to replace proprietary BIOS and UEFI implementations. coreboot can be used with both BIOS and UEFI payloads, like SeaBIOS and TianoCore, respectively.
- Heads A secure FLOSS BIOS loaded by coreboot in the PureBoot process.
Secure Boot alternatives like PureBoot can also neutralize vulnerabilities associated with the Secure Boot process.
The GRUB Configuration File
Your GNU/Linux distribution's GRUB configuration file will likely be located at either /boot/grub/grub.cfg
(Debian) or /boot/grub2/grub.cfg
(Fedora; /boot/efi/EFI/fedora/grub.cfg
for UEFI-based systems). This file should not be directly modified. Instead, there are two options:
- Create a
/boot/grub/custom.cfg
(Debian) or/boot/grub2/custom.cfg
(Fedora;/boot/efi/EFI/fedora/custom.cfg
for UEFI-based systems) file and add your customizations there. - Add your customizations to the extant
/etc/grub.d/40_custom
or/etc/grub.d/41_custom
file.
After you do one of the above, run # grub-mkconfig -o /boot/grub/grub.cfg
(Debian) or # grub2-mkconfig -o /boot/grub2/grub.cfg
(Fedora; # grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
for UEFI-based systems) to regenerate the system's GRUB configuration file (the -o
option is used to specify the output file for the command; by default, grub-mkconfig
and grub2-mkconfig
send their output to the standard output). The grub-mkconfig
and grub2-mkconfig
commands use the /etc/default/grub
file and the files in /etc/grub.d/
as inputs.
This is an example entry from a GRUB configuration file:
menuentry 'Linux' --class gnu-linux --class os {
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
linux /vmlinuz root=/dev/sda1 ro
initrd /initrd.img
}
The GRUB modules for decompression (gzio
), MS-DOS-like partitioning support part_msdos
, and the ext2
file system must be explicitly loaded. root=/dev/sda1
is the path to the root file system (this is the file system that will be mounted at /
) and ro
tells GRUB to boot the file system as read-only.
Installing GRUB
To install GRUB on a BIOS-based system, run:
# grub-install ex_device
(Debian)
Or:
# grub2-install ex_device
(Fedora)
By default, GRUB will be installed to /boot/grub/
(Debian) or /boot/grub2/
(Fedora), but you can specify an installation directory with the --boot-directory
option (e.g., # grub2-install --boot-directory=/mnt/ex_directory ex_device
).
To install GRUB on a UEFI-based system, run:
# grub-install --efi-directory=ex_efi_directory --bootloader-id=ex_bootloader_name ex_device
(Debian)
Or:
# grub2-install --efi-directory=ex_efi_directory --bootloader-id=ex_bootloader_name ex_device
(Fedora)
For the commands above, ex_efi_directory
is the directory to serve as the ESP root (e.g., /boot/efi/
). ex_bootloader_name
is an identifier for the bootloader (e.g., fedora
or apple
).
Working With GRUB
The Linux kernel can accept a custom command line and evaluate it during the kernel start procedure. The parameters on this custom command line can configure device drivers and change different kernel options. You can create this custom command line in GRUB by appending parameters to the linux
specification (e.g., linux /vmlinuz root=/dev/sda1 ro
).
There are numerous types of kernel parameters. The first group overwrites hard-coded defaults (e.g., root
or rw
). Another group of parameters serves to configure device drivers within the kernel. There are also parameters governing general settings, e.g., init
or reserve
.
If one of these parameters occurs on the command line, the initialization function for the device driver in question is called with the arguments specified there, rather than the built-in default values. If there are problems with a built-in driver during system boot, you can usually disable the driver by specifying a 0
as the parameter for the corresponding boot parameter.
Most GNU/Linux distributions use modular kernels that have only a few device drivers built into the kernel. Modular device drivers cannot be configured from the command line.
GRUB Menu Keyboard Shortcuts
Some of the most helpful GRUB menu keyboard shortcuts include:
- c
- Brings you to the GRUB command line.
- e
- Edit a GRUB menu entry.
- Esc
- Temporarily prevent GRUB from automatically booting a menu entry after a set timeout period.
- Shift (right-side)
- Access the GRUB menu. Some GNU/Linux distributions hide this menu during system startup, so you can hold down this key to access it.
Kernel Command Line Parameters
GRUB allows you to modify boot menu items at system startup to customize how the system boots. Also, you can interactively create new boot menu items by accessing the grub>
command line interface (CLI) prompt.
These are some of the parameters that can be passed to the Linux kernel via GRUB:
1
orsingle
- Boot system into single-user mode.
2
,3
,4
, or5
- Boot system to specified runlevel.
apm=on
- Enable Advanced Power Management.
apm=off
- Disable Advanced Power Management.
init=ex_program
- Run
ex_program
instead of the customary/sbin/init
. For example, this can be used to setinit
to/bin/bash
when troubleshooting a non-booting system. maxcpus=ex_num
- On a multi-processor system, use only as many CPUs as specified. Useful for troubleshooting or performance measurements.
mem=ex_size
- Set amount of accessible memory.
ex_size
is a number, optionally followed by a unit (e.g.,G
for gibibytes,M
for mebibytes, orK
for kibibytes). This only takes effect during boot time. noapic
- Disable Advanced Programmable Interrupt Controllers present in the system.
usbcore.nousb
- Disable the USB subsystem.
panic=ex_num
- Determines the kernel's behavior after a kernel panic. An
ex_num
value of less than0
causes the system to reboot immediately, a value of0
causes the system to wait forever, and a value greater than0
causes the system to reboot after the specified number of seconds. ro
- Mount the root file system as read-only on boot.
rw
- Mount the root file system as read-write on boot.
vga=
- Set framebuffer resolution to a given mode. See
Documentation/x86/boot.rst
andDocumentation/admin-guide/svga.rst
for more information. Usevga=ask
for a menu.
A complete list of available parameters is given in Documentation/kernel-parameters.txt
, which is part of the Linux source code and is available at kernel.org.
The Linux kernel notices command line options that do not correspond to kernel parameters. It passes them to the init
process as environment variables.
GRUB Command Line Commands
ls
- View devices known to GRUB. Add
-l
to view file system UUIDs. echo $root
- Display the GRUB Boot Volume. If the GRUB Boot Volume was installed in its own partition, GRUB will display that partition (e.g.,
hd0,msdos1
). If the GRUB Boot Volume does not have its own partition, GRUB will display its path (e.g.,/boot
). echo $prefix
- Display the file system location where GRUB expects to find its configuration and auxilliary support (e.g.,
hd0,msdos1/grub
or/boot/grub2
). ls ($root)/
- Display the contents for the root of the GRUB Boot Volume (e.g.,
/boot
or/
). set
- Display all set GRUB variables.
clear
- Clear the screen.
help
- View GRUB help.
GRUB supports using the Tab key for filename completion (e.g., ls (hd0,msdos1)/vml<TAB>
).
To boot a specific Linux kernel and initial RAM disk at the GRUB command line, you need to specify each, and then issue the boot
command.
grub> linux (hd0,msdos1)/vmlinuz-5.5.5-200.fc31.x86_64 root=/dev/mapper/fedora-root ro
grub> initrd (hd0,msdos1)/initramfs-5.5.5-200.fc31.x86_64.img
grub> boot
If you need to exit the GRUB CLI, you should be able to do so by pressing Esc.
Securing GRUB
If full disk encryption is not employed, the GRUB shell allows access to a disk's file system without the usual access control mechanism. Therefore, it may be wise to secure GRUB, depending on your threat model.
You can secure three different components of GRUB with password protection:
- Editing of GRUB menu entries
- Loading of a specific GRUB menu entry
- GRUB CLI access
How you go about doing this will depend on your GNU/Linux distribution.
Debian
Set a Password For Menu Entry Loading, Menu Entry Editing, and Command Line Interface (CLI) Access
First, generate an encrypted password:
grub-mkpasswd-pbkdf2
The grub-mkpasswd-pbkdf2
command will prompt you to enter a password (you will need to enter this value twice). Afterwards, the command will generate a PBKDF2 hash of the password that you entered. Copy this.
Second, run the following command to add user and password information to /etc/grub.d/40_custom
:
# {
echo -e '\n# Set superusers'
echo -e "set superusers='ex_username'\n"
echo '# Set users and their passwords'
echo 'password_pbkdf2 ex_username ex_password'
} >> '/etc/grub.d/40_custom'
Multiple superusers can be specified by separating them with a comma (e.g., set superusers='ex_username_1,ex_username_2'
). Each new superuser will need to have their own username/password entry in /etc/grub.d/40_custom
(e.g., password_pbkdf2 ex_username_2 ex_password_2
).
Also, you can add additional username/password entries in /etc/grub.d/40_custom
for users that are not superusers. These users will be able to load any unprotected menu entries and entries for which they have been specifically assigned to.
Finally, update the GRUB configuration file to incorporate your changes:
# grub-mkconfig -o '/boot/grub/grub.cfg'
After rebooting the system, you will be prompted for a username and password if you attempt to load a GRUB menu entry, modify a GRUB menu entry, or access the GRUB CLI. Only a superuser specified in /etc/grub.d/40_custom
will have the required permissions for these functions.
Customize the Loading Behavior For a Specific Menu Entry
After you set up a superuser and their associated password (and any additional users and their passwords) in /etc/grub.d/40_custom
, you can also customize the loading behavior for specific GRUB menu entries.
For the menu entry in question, you will need to find and modify its corresponding menuentry
line in the /etc/grub.d/10_linux
file.
For example, here is the line that controls the Debian GNU/Linux
menu entry:
echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
Adding --unrestricted
removes password protection for loading this menu entry (i.e., any user can now load the menu entry):
echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} \$menuentry_id_option 'c-$boot_device_id' --unrestricted {" | sed "s/^/$submenu_indentation/"
Adding --users ex_username
allows both superusers
and ex_username
to boot the entry in question, after entering their username and password credentials (which were previously specified in /etc/grub.d/40_custom
).
After your modifications have been made to /etc/grub.d/10_linux
, you will need to recreate the GRUB configuration file to see your changes take effect:
# grub-mkconfig -o /boot/grub/grub.cfg
Fedora
Set a Password For Menu Entry Loading, Menu Entry Editing, and Command Line Interface (CLI) Access
First, replace GRUB_ENABLE_BLSCFG=true
with GRUB_ENABLE_BLSCFG=false
in the /etc/default/grub
file:
# sed -i 's/GRUB_ENABLE_BLSCFG=true/GRUB_ENABLE_BLSCFG=false/' '/etc/default/grub'
This disables the use of Boot Loader Specification-style configuration files.
Second, replace CLASS="--class gnu-linux --class gnu --class os" --unrestricted
with CLASS="--class gnu-linux --class gnu --class os"
in the /etc/grub.d/10_linux
file:
# sed -i 's/CLASS="--class gnu-linux --class gnu --class os --unrestricted"/CLASS="--class gnu-linux --class gnu --class os"/' '/etc/grub.d/10_linux'
Third, generate an encrypted password:
grub2-mkpasswd-pbkdf2
The grub2-mkpasswd-pbkdf2
command will prompt you to enter a password (you will need to enter this value twice). Afterwards, the command will generate a PBKDF2 hash of the password that you entered. Copy this.
Run the following command to add user and password information to /etc/grub.d/01_users
:
# {
echo -e '\ncat <<EOF'
echo -e '# Set superusers'
echo -e "set superusers='ex_username'\n"
echo '# Set users and their passwords'
echo -e 'password_pbkdf2 ex_username ex_password'
echo 'EOF'
} >> '/etc/grub.d/01_users'
As under Debian, multiple superusers can be specified by separating them with a comma (e.g., set superusers='ex_username_1,ex_username_2'
). Each new superuser will need to have their own username/password entry in /etc/grub.d/01_users
(e.g., password_pbkdf2 ex_username_2 ex_password_2
).
Also, you can add additional username/password entries in /etc/grub.d/01_users
for users that are not superusers. These users will be able to load any unprotected menu entries and entries for which they have been specifically assigned to.
Finally, update the GRUB configuration file:
UEFI
# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Or:
BIOS
# grub2-mkconfig -o /boot/grub2/grub.cfg
After rebooting the system, you will be prompted for a username and password if you attempt to load a GRUB menu entry, modify a GRUB menu entry, or access the GRUB CLI. Only a superuser specified in /etc/grub.d/01_users
will have the required permissions for these functions.
Customize the Loading Behavior For a Specific Menu Entry
After you set up a superuser and their associated password (and any additional users and their passwords) in /etc/grub.d/01_users
, you can also customize the loading behavior for GRUB menu entries.
To do so, you will need to find and modify the CLASS
variable value in the /etc/grub.d/10_linux
file.
CLASS="--class gnu-linux --class gnu --class os"
For example, adding --users ex_username
allows both superusers
and ex_username
to boot the entry in question, after entering their username and password credentials (which were previously specified in /etc/grub.d/01_users
).
CLASS="--class gnu-linux --class gnu --class os" --users ex_username
After your modifications have been made to /etc/grub.d/10_linux
, you will need to recreate the GRUB configuration file to see your changes take effect:
UEFI
# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Or:
BIOS
# grub2-mkconfig -o /boot/grub2/grub.cfg
The Boot Process
The GNU/Linux boot process differs depending on whether your system firmware is BIOS or UEFI. In general, the process goes like this.
Basic Input Output System (BIOS)
- Firmware performs a power-on self test (POST).
- Firmware consults its settings to identify its bootable disks.
- Stage 1 bootloader (
boot.img
) searches the partition table for a bootable partition. - Stage 1 bootloader loads the Stage 2 bootloader (
diskboot.img
) into RAM. - Stage 2 bootloader loads the rest of
core.img
into RAM. - Stage 3 bootloader (
core.img
) enters 32-protected mode, uncompresses itself, and loadsnormal.mod
. - Stage 4 bootloader (
normal.mod
) parsesgrub.cfg
, optionally loads modules for advanced functionality, and displays the GRUB menu.
Unified Extensible Firmware Interface (UEFI)
- Firmware performs a POST.
- Firmware consults its settings to identify its bootable disks.
- Firmware reads bootloader data at
/boot/efi/
(i.e., the EFI System Partition, ESP) to determine which UEFI application in/boot/efi/EFI/
it should launch and from where, and launches it (here, GRUB is the UEFI application and is located at/boot/efi/EFI/ex_distribution/grubx64.efi
).
BIOS and UEFI
- GRUB screen displays, allowing you to change boot options.
- After a selection, GRUB loads the kernel and initrd/initramfs images into memory, starts the kernel, and passes the kernel the memory address of the initrd/initramfs image.
- Either the kernel decompresses itself, or GRUB decompresses it.
- The kernel initializes and configures the system's memory and all attached hardware with hardware device drivers built into the kernel.
- For systems that use an initrd image, the initrd image is made available in a special block device (
/dev/ram
) and mounted as the temporary root file system (the driver for this file system is built into the kernel). Once the temporary root file system is up, the kernel executes/linuxrc
as its first process. For systems that use an initramfs image, the kernel unpacks the initramfs image (which is a compressedcpio
archive) into a temporary root file system (i.e., atmpfs
pseudo file system). - The kernel performs maintenance tasks on the temporary root file system. Processes that must continue are hoisted into the temporary root file system.
- The temporary root file system's
mount
program instructs the kernel that a file system is ready to use and associates the real root file system with a mount point. - For systems that use an initrd image, the real root file system that was mounted at a temporary mount point is rotated into place with
pivot_root
. The temporary root file system (usually mounted at a location like/initrd
) is later unmounted by normal boot scripts. For systems that use an initramfs image, the temporary root file system is switched (by the temporary root file system'sinit
via a call to boot scripts) and replaced with the real root file system via achroot()
system call. - For systems that use an initrd image, once
/linuxrc
exits, the kernel executes/sbin/init
on the real root file system. For systems that use an initramfs image, the initramfs is cleared from memory, all files in the temporary root file system root are deleted, and/sbin/init
on the real root file system is executed.
User Space Start
If no early user space exists, the kernel makes the storage medium named on its command line using the root=
option available as the root file system and starts the program given by the init=
option, by default /sbin/init
.
User space start proceeds as follows:
init
- Essential low-level services (e.g.,
journald
,rsyslogd
) - Network configuration
- Mid- and high-level services (e.g., cron, printing)
- Login prompts, Graphical User Interfaces (GUIs), and other high-level applications
Logging
For logging purposes, the boot process can be divided into two phases:
- The early phase begins with the initial activity of the kernel and continues up to the instant where the system logging service (e.g.,
journald
,rsyslogd
) is activated. - The late phase begins just then and finishes when the computer is shut down.
The kernel writes early phase messages into an internal buffer that can be displayed using the dmesg
command. Various GNU/Linux distributions arrange for these messages to be passed on to the system logging service as soon as possible, so they will show up in the official log.
The system logging service runs during the late phase. The majority of GNU/Linux distributions place most messages sent to the system logging service into the /var/log/messages
file. This is also where messages from the boot process end up if they have been sent before the logging service was started.
It is possibly for messages that were sent after init
was started, but before the system logging service was launched, to get lost. This is why the system logging service is usually among the first services started after init
.
Troubleshooting
The solution for most bootloader problems (if they cannot be easily reduced to disk or firmware errors) consists of booting the system from live media and reinstalling the bootloader. In situations like this, the chroot
command can be used to run a command or interactive shell with a special root directory.
For example, you can use chroot
when working off of a live USB key and you are mounting a damaged system partition that needs to be repaired:
# mount -o rw '/dev/sda1' '/mnt'
# chroot '/mnt'
After you run the chroot
command above, you will be placed into a prompt where you are working in your installed GNU/Linux distribution.
If you have a ruined partition table on your disk, you can restore a backup using the dd
command (provided that you have a partition table backup to work with) or re-instate the partitioning using a tool like TestDisk, and rewrite the bootloader.
Documentation
You can find more information on firmware, GRUB, and the GNU/Linux boot process here: