Unit

GRUB 2.2: Linux Bootloader Concepts, Configuration, and Recovery

Learn how GRUB 2.2 fits into the Linux boot process, how configuration is generated, how to pass kernel parameters, and how to recover BIOS and UEFI systems safely.

GRUB, the GNU GRand Unified Bootloader, is software that starts after firmware initialization and loads an operating system. It can present a menu of Linux kernels and other operating systems, pass options to the Linux kernel, and provide recovery choices when a normal boot fails.

This lesson uses “GRUB 2.2” as the topic label for the modern GRUB 2 family. Distribution packages and documentation may call it GRUB 2, grub2, or simply grub. Exact commands, paths, and features depend on the distribution and firmware mode.

What GRUB Does

A bootloader is software that selects and loads an operating system kernel. GRUB sits between firmware and the Linux startup process:

1. BIOS or UEFI firmware initializes hardware and selects a boot target.
2. Firmware starts GRUB or a GRUB EFI executable.
3. GRUB reads its configuration and displays boot choices.
4. GRUB loads the Linux kernel and initramfs, then passes the kernel command line.
5. The kernel starts early userspace, discovers storage, and mounts the root filesystem.

The kernel is the core of the operating system. The initramfs is a temporary early-userspace filesystem containing tools and drivers needed to find and mount the real root filesystem, the filesystem eventually mounted as /.

• Boot Linux normally.
• Select an older kernel after a kernel or driver update.
• Choose a second operating system in a dual-boot installation.
• Pass diagnostic or recovery parameters to the kernel.
• Start a recovery entry or emergency target.

GRUB 2 Compared with Legacy GRUB

GRUB 2 is the modern GRUB architecture used by most Linux distributions. It differs significantly from legacy GRUB, sometimes called GRUB Legacy. In GRUB 2, the visible menu is normally generated from source settings and scripts rather than maintained as one hand-edited menu file.

Do not assume that a command or path from one GRUB generation applies to the other. Also confirm whether your distribution uses /boot/grub or /boot/grub2.

The Boot Process: BIOS and UEFI

BIOS is a legacy firmware environment. It commonly reads initial boot code from a disk's boot area and transfers control to GRUB. BIOS installations must place GRUB in a location that the firmware and partition layout support. With GPT partitioning, a BIOS Boot Partition may be required for embedded boot components.

UEFI is a modern firmware interface. It starts an EFI executable from an EFI System Partition (ESP), a small FAT-formatted partition that stores boot files. A UEFI GRUB installation normally places an EFI executable on the ESP and may also create a firmware boot entry in nonvolatile firmware storage.

Firmware mode must match the repair method. If the installed system was installed in UEFI mode, boot rescue media in UEFI mode; if it was installed for BIOS, use the BIOS-compatible repair path. Check the layout with tools such as lsblk, blkid, and the output of mount before changing boot files.

GRUB Files and Configuration Layout

The generated main configuration file is commonly /boot/grub/grub.cfg on Debian-family systems and /boot/grub2/grub.cfg on some Red Hat-family systems. This file contains generated menu definitions and commands.

Do not normally edit grub.cfg directly. Package updates, kernel installation, and configuration regeneration can overwrite manual edits. Instead, change the distribution's source settings and regenerate the file.

• /etc/default/grub commonly contains global settings such as timeout, default entry, menu visibility, and extra kernel parameters.
• /etc/grub.d/ commonly contains executable generator scripts. Their numeric prefixes influence ordering.
• grub.cfg is the generated result consumed by GRUB at boot.
• Kernel and initramfs files normally reside in /boot.
• The ESP is mounted at a path such as /boot/efi on many UEFI installations, but the mount point is not universal.

Menu Entries and Boot Selection

A menuentry block represents one bootable choice. It normally identifies a kernel, an initramfs, and the options passed to the kernel. A submenu groups related choices, such as older kernels and recovery entries. Distribution scripts commonly create these entries automatically when kernels are installed.

GRUB_DEFAULT controls the default choice. It may refer to a numeric menu position, a menu identifier, or a saved selection, depending on the distribution's syntax. GRUB_TIMEOUT controls how long the menu waits. GRUB_TIMEOUT_STYLE can show a menu, hide it, or display it only after a key is pressed. Saved selections require compatible saved-entry settings and should be tested carefully.

At boot, select an older kernel from the main menu or an Advanced Options submenu. Recovery entries may start a restricted target or provide repair tools. To inspect or temporarily modify an entry, highlight it and use the edit control shown by the menu. A temporary edit lasts for that boot only.

When operating-system detection is enabled and supported, GRUB can scan for another installation and generate a chainloading entry. Detection may be disabled for security or policy reasons, unsupported by the installed packages, or unable to access the other system's boot files.

Kernel Command-Line Parameters

The kernel command line is the set of parameters GRUB passes to the kernel. Parameters are separated by spaces and are interpreted by the kernel, initramfs, drivers, or the early userspace system.

init= can request a particular initial userspace program, but it is an advanced recovery parameter. An incorrect value can prevent startup. Validate every parameter against the installed distribution and system design, especially when encryption, RAID, LVM, or unusual storage drivers are involved.

Temporary Versus Persistent Changes

Editing a menu entry at boot changes only that boot attempt. To make a change persistent, edit the appropriate source, commonly /etc/default/grub, then regenerate the configuration. Preserve at least one known-good boot path before removing entries or adding experimental parameters.

# Example source settings; edit the distribution defaults file, not grub.cfg
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu
GRUB_DEFAULT=0
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

# Inspect commonly used active settings
grep -E '^(GRUB_DEFAULT|GRUB_TIMEOUT|GRUB_TIMEOUT_STYLE|GRUB_CMDLINE_LINUX)' /etc/default/grub

Safe Configuration Workflow

1. Record the current firmware mode, disk layout, mount points, and known-good menu entry.
2. Back up relevant configuration files and ensure bootable live or rescue media is available.
3. Edit source settings with administrative privileges.
4. Regenerate the configuration using the distribution's wrapper or generator.
5. Review the generated output and confirm that a normal kernel, an older kernel, and any required recovery path remain available.
6. Reboot during a maintenance window and test the intended entry.

sudo update-grub

On systems without that wrapper, a generic command may look like this, but the output path must be confirmed:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Device names such as /dev/sda, /dev/nvme0n1, and partition identifiers are not interchangeable. Confirm the whole disk, partition, UUID, firmware mode, and separate /boot or ESP mounts before installing or repairing GRUB.

Installing and Repairing GRUB

Installing GRUB for BIOS and UEFI are different operations. A BIOS installation targets suitable disk boot code. A UEFI installation targets an EFI executable and requires the ESP to be mounted. Neither command should be treated as universal without checking the installed layout and distribution.

A typical rescue workflow is:

1. Boot live or rescue media in the same BIOS or UEFI mode as the installed system.
2. Use lsblk, blkid, and filesystem inspection to identify the installed root, separate /boot, and ESP.
3. Mount the root filesystem at a temporary path such as /mnt, then mount separate boot filesystems beneath it.
4. Bind or mount /dev, /dev/pts, /proc, and /sys as required by the distribution.
5. Enter the installed environment with chroot.
6. Reinstall the correct BIOS or UEFI GRUB target, regenerate configuration, and inspect firmware entries when using UEFI.
7. Exit, unmount cleanly, reboot, and test the menu.

sudo mount /dev/ROOT_PARTITION /mnt
sudo mount /dev/BOOT_PARTITION /mnt/boot
sudo mount /dev/EFI_SYSTEM_PARTITION /mnt/boot/efi
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount -t proc proc /mnt/proc
sudo mount -t sysfs sys /mnt/sys
sudo chroot /mnt /bin/bash

Mount only partitions that exist in the target layout. The placeholder device names above must be replaced only after verification. In UEFI repair, firmware boot-entry repair may be necessary if the NVRAM entry was deleted or reset. Secure Boot policy can also affect whether a boot component is accepted.

GRUB Command Shell and Rescue Mode

The normal GRUB command shell is a relatively capable interactive environment. grub rescue is a more limited environment shown when GRUB cannot load normal modules or locate its configuration. The GRUB prefix is the location from which GRUB finds its configuration and modules.

• ls lists disks, partitions, and sometimes filesystem contents.
• set displays or changes variables such as root and prefix.
• insmod loads a GRUB module, such as normal or a filesystem driver.
• normal attempts to return to the standard menu.
• configfile loads a configuration file found on a selected filesystem.
• linux loads a Linux kernel and accepts its command line.
• initrd loads an initramfs.
• boot starts the loaded boot components.

ls
set
ls (hd0,gpt1)/
set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub
insmod normal
normal

Partition notation, module names, and directory locations vary. These commands are for discovery and temporary recovery, not a fixed repair recipe. Once the normal menu is reachable, permanently repair the installation from the installed system or rescue media.

Common Failure Modes and Diagnosis

No Bootable Device or Missing GRUB

Firmware may be using the wrong disk, boot mode, or boot entry. Disk replacement, partition changes, or a firmware reset can produce this symptom. Confirm whether the installation is BIOS or UEFI, inspect the disk layout, verify the ESP when applicable, and reinstall the matching GRUB target rather than using a copied command blindly.

The System Drops to grub rescue>

GRUB may have an incorrect prefix, missing modules, an unreadable filesystem, or a partition that was moved or reformatted. Use ls to inspect candidate partitions, identify the one containing the GRUB directory, set temporary root and prefix values, and try insmod normal followed by normal. Perform a permanent repair afterward.

Kernel Panic or Root Filesystem Failure

GRUB may load successfully while Linux fails to mount its root filesystem. Likely causes include an incorrect root= value, a damaged initramfs, or unavailable storage support for encryption, RAID, LVM, or a controller. Try an older kernel or recovery entry, compare its parameters with the failing entry, and use rescue media to verify UUIDs, storage configuration, and initramfs files.

Black Screen After Kernel Selection

A graphics driver or kernel mode-setting problem can prevent visible output. Temporarily remove quiet and splash to reveal messages. Where appropriate, test nomodeset for one boot. If an older kernel works, repair or update the graphics stack from the installed system.

Missing Dual-Boot Entry

Operating-system detection may be disabled, unsupported, unable to access the other system, or affected by incompatible BIOS and UEFI installation modes. Confirm that the other installation and its boot files are present, review the detection policy, regenerate the configuration, and inspect the generated entries. Firmware boot selection or a carefully designed chainloading entry may be appropriate in some layouts.

UEFI Starts Firmware Directly

The ESP may be missing, unmounted, damaged, or missing GRUB EFI files. The firmware NVRAM entry may also have been removed. Boot rescue media in UEFI mode, verify the ESP type and contents, reinstall the correct EFI target, inspect firmware boot entries, and check Secure Boot policy if boot components are rejected.

Security and Operations

Physical access to a GRUB menu can allow a person to edit kernel parameters, select recovery modes, or start another installed operating system. This can weaken local access controls, especially if disks are not encrypted.

GRUB supports password protection for administrative menu editing and selected commands. Password protection has limitations: it does not replace full-disk encryption, does not prevent firmware settings from being changed, and does not protect an attacker who can alter the disk or boot from external media. Secure Boot adds a UEFI verification layer by allowing firmware to trust signed boot components, but it must be planned together with the distribution's signed boot chain and any custom kernels or modules.

For production systems, back up configuration and important data, keep recovery media available, test changes on a noncritical system when possible, preserve a known-good kernel, and schedule bootloader work during a controlled maintenance window.

Practical Examples

Change the Menu Timeout

1. Edit /etc/default/grub and set a suitable GRUB_TIMEOUT and menu style.
2. Run the distribution's configuration generator, commonly sudo update-grub on Debian and Ubuntu systems.
3. Review the generated configuration and reboot during a maintenance window.

Boot an Older Kernel

Open the GRUB menu, choose the older kernel directly or through Advanced Options, and test whether the system starts normally. If it works, investigate the newer kernel, driver, initramfs, or kernel parameters before making the older entry the permanent default.

Diagnose a Graphics Failure

Highlight the Linux entry, use the temporary edit control, remove quiet and splash, and add nomodeset when suitable. Boot once and use the result to determine whether graphics mode-setting is implicated. Do not save the parameter permanently until its effect is understood.

Recover from Live Media

Identify partitions, mount the installed root and any separate boot or ESP filesystems, bind the required virtual filesystems, enter the installed system with chroot, reinstall the correct firmware-specific GRUB target, regenerate the configuration, and verify the firmware entry before rebooting.

Exam-Ready Summary

• Firmware initializes hardware and starts GRUB; GRUB loads the kernel and initramfs.
• BIOS and UEFI use different boot mechanisms and repair targets.
• The UEFI EFI System Partition stores EFI boot files.
• grub.cfg is generated output and should not normally be edited directly.
• /etc/default/grub stores common global settings; /etc/grub.d/ contains generator scripts.
• menuentry represents a boot choice; submenu groups choices.
• Kernel parameters can be edited temporarily at boot or stored persistently in source configuration.
• A GRUB prompt indicates a problem locating modules, the prefix, or configuration; a kernel panic indicates a later Linux startup problem.
• Always confirm firmware mode, device names, partition layout, mounts, and recovery options before reinstalling GRUB.