Silicon Soul

GRUB and the GNU/Linux Boot Process

Table of Contents

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 or initramfs 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.

GNU GRUB 2 — "GNU GRUB components.svg" by ScotXW is licensed under a CC BY-SA 3.0 license

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 addresses diskboot.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 of core.img identified by LBA sector numbers written by grub-install (Debian) or grub2-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 load normal.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 (¹, ²), 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.

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 or single: Boot system into single-user mode.
2, 3, 4, or 5: 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 set init 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, or K 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 than 0 causes the system to reboot immediately, a value of 0 causes the system to wait forever, and a value greater than 0 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 and Documentation/admin-guide/svga.rst for more information. Use vga=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

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.

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

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.

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 loads normal.mod.
Stage 4 bootloader (normal.mod) parses grub.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 compressed cpio archive) into a temporary root file system (i.e., a tmpfs 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's init via a call to boot scripts) and replaced with the real root file system via a chroot() 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:

Enjoyed this post?

Subscribe to the feed for the latest updates.

Page Body

Conscientious Technology Education