Introduction

Recovery is a sequence of checkpoints: firmware, bootloader, kernel, initramfs, root filesystem, and userspace. Identify the last successful checkpoint before choosing a repair.

What you should be able to do after this lesson:

Distinguish BIOS/MBR and UEFI/ESP boot paths.
Temporarily edit GRUB parameters and use its shell.
Enter rescue or emergency mode.
repair filesystems from a safe environment.
Rebuild an initramfs or reinstall a bootloader.

Big Idea: Repair the First Broken Checkpoint

Recovery commands are safest when they target the first failed stage. Reinstalling GRUB cannot repair a filesystem that the kernel already found but could not mount. Running fsck cannot create a missing UEFI boot entry. Read the last successful message and test the next boundary before changing disk state.

Map the Boot Path

A typical path is:

firmware -> bootloader -> kernel -> initramfs -> real root -> init system

Symptoms suggest the failed stage:

no boot entry: firmware or bootloader registration
GRUB prompt: missing or incorrect GRUB configuration
kernel panic before root mount: kernel, initramfs, storage, or root identifier
emergency target: mount or userspace dependency failure

BIOS and UEFI

Legacy BIOS commonly loads boot code from an MBR. UEFI loads an EFI executable from a FAT-formatted EFI System Partition, usually mounted at /boot/efi.

findmnt /boot/efi
efibootmgr -v
ls /sys/firmware/efi

If /sys/firmware/efi exists, the running system normally booted through UEFI.

Temporary GRUB Recovery

In the GRUB menu, edit a boot entry temporarily to:

select an older kernel
correct a root device
append systemd.unit=rescue.target
append systemd.unit=emergency.target
append init=/bin/sh for a minimal recovery path

Temporary edits are lost after boot and are safer for testing. At a GRUB shell, commands such as ls, set, insmod, linux, and initrd help locate and start a system manually.

GRUB Legacy and GRUB 2 use different configuration syntax and files. Modern systems normally use GRUB 2, but the exam expects recognition of both. Avoid editing generated grub.cfg permanently when the distribution provides a source file and generation command.

Rescue and Emergency Targets

systemctl rescue
systemctl emergency

Rescue mode provides more services and mounted filesystems than emergency mode. Emergency mode offers the smallest environment. From the kernel command line, use systemd.unit=rescue.target or systemd.unit=emergency.target.

The root filesystem may be read-only:

mount -o remount,rw /

Filesystem and Mount Failures

Use a live or rescue environment when the filesystem being repaired must be unmounted.

lsblk -f
blkid
fsck -f /dev/<device>

Do not run a destructive filesystem repair against an actively mounted filesystem. Check /etc/fstab for wrong UUIDs, unavailable network mounts, and missing nofail where an optional device should not block boot.

Chroot Repair

A live system can mount the installed root and enter it:

mount /dev/<root> /mnt
mount /dev/<boot> /mnt/boot
mount /dev/<esp> /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

Exact mounts depend on the layout. Inside the chroot, rebuild initramfs, reinstall packages, reset passwords, or repair GRUB.

Rebuild Boot Components

Typical operations include:

grub-install <target-device>
grub-mkconfig -o /boot/grub/grub.cfg
update-initramfs -u -k all
dracut --force

Commands and output paths are distribution-specific. Verify before rebooting and keep another recovery session available when working remotely.

Guided Practice: Build a Recovery Map

On a healthy lab system, collect read-only recovery information:

lsblk -f
findmnt / /boot /boot/efi
cat /proc/cmdline
ls -lh /boot
test -d /sys/firmware/efi && echo UEFI || echo BIOS-or-unknown
sudo efibootmgr -v

Some commands legitimately return no data on BIOS systems or layouts without separate boot filesystems. Record:

root filesystem device and UUID
boot and ESP locations
current kernel and initramfs names
firmware mode
known-good boot entry

Then identify the live or rescue media you would use and write the exact mount order for a chroot. Preparing this map while the system works removes guesswork during an outage.

Troubleshooting Scenario

The kernel starts but reports that UUID=... does not exist. lsblk -f in rescue media shows that the filesystem has a different UUID after being recreated.

Temporarily boot with the correct root parameter if possible. Then update every persistent reference that used the old UUID, including /etc/fstab and bootloader configuration, rebuild the initramfs when required, and verify with findmnt --verify. Reinstalling the bootloader to the disk would not correct a stale root identifier.

Exam Focus

Know the BIOS/MBR and UEFI/ESP boot paths, including NVMe device names.
Use temporary GRUB edits before making permanent changes.
Distinguish rescue mode, emergency mode, and a live-media chroot.
mount, fsck, grub-install, efibootmgr, initrd, and initramfs solve different recovery stages.

Recap

Locate the failed boot stage before repairing it.
UEFI uses an ESP and EFI boot entries; BIOS commonly relies on MBR boot code.
Temporary kernel parameters are valuable diagnostic tools.
Repair mounted filesystems and remote bootloaders with particular care.

202.2 System recovery