Recovering From a Broken Bootloader

grub1-4 covered the light rescue scenario — the system still boots, just to a minimal shell. This chapter is the heavy one: GRUB itself is broken, and the system never reaches a kernel at all. This assumes real comfort with the command line, the same prerequisite linux1-11's own Essential Terminal Skills chapter established — worth naming honestly up front.

Recognizing a Broken Bootloader

Three genuinely different symptoms: a grub rescue> prompt (a minimal fallback shell GRUB itself drops into when core.img ran successfully but couldn't find /boot/grub — distinct from grub1-4's own full menu editor); the system booting straight past GRUB into another OS with no menu at all (grub1-6's own gotcha); or a firmware-level "no bootable device" / "operating system not found" error, meaning firmware couldn't find any bootloader whatsoever. The first means GRUB partially loaded; the last means firmware never found GRUB in the first place — genuinely different failures.

Step 1 — Boot From a Live USB

The same installation media linux1-4 described creating doubles as the rescue tool here — boot it, but choose "Try" or live mode rather than "Install."

Step 2 — Identify and Mount the Broken System's Partitions

From the live environment, lsblk or fdisk -l identifies which partition holds the broken system's root filesystem, and — if kept separate per grub1-8's own advice — its dedicated /boot partition. Mount them under a temporary mountpoint.

Step 3 — chroot Into the Broken System

chroot temporarily makes the mounted broken system's own root filesystem be the root filesystem for a new shell — commands from this point on run against the broken system's own binaries, libraries, and configuration, as though it had actually booted normally. Bind-mounting /dev, /proc, and /sys first gives that chrooted environment working device and process access, without which most repair commands would fail outright.

Step 4 — Reinstall GRUB with grub-install

Now run from inside the chroot, using the broken system's own grub-install — as if executed from a normal boot. On BIOS, the target is the whole disk device, never a specific partition (grub1-5's own material on why boot code needs the MBR itself). On UEFI, the syntax is genuinely different, because the installation mechanism itself differs — writing an EFI binary into the EFI System Partition and registering a fresh NVRAM boot entry, rather than writing directly to an MBR.

Step 5 — Exit, Unmount, Reboot

exit leaves the chroot; unmount everything in reverse order; reboot; remove the live USB; confirm the menu is back.

A Real Walkthrough — Recovering From Chapter 6's Own Gotcha

Applied directly to grub1-6's own scenario — a Windows Update reset the boot order or overwrote the MBR: boot the live USB, mount the Linux root partition, chroot in, run grub-install (and update-grub, or efibootmgr to restore the boot order on UEFI), reboot. The same five-step procedure, resolving the exact problem named three chapters earlier.

Hands-On Exercises