Linux System Boot Failure and GRUB Repair: Command-Line Recovery¶

A Linux system boot failure can feel daunting, presenting you with an enigmatic grub rescue> prompt, an emergency (initramfs) shell, a frozen splash screen, or an emergency systemd maintenance prompt. Unlike Windows, which obscures underlying processes behind graphical recovery wizards, Linux provides direct, low-level access to the system kernel and boot configuration through command-line shells. Most Linux boot failures stem from four common causes: corrupted GRUB 2 bootloader configurations, dirty root filesystems that fail automated filesystem checks, an exhausted storage drive filled to 100 percent capacity, or misconfigured drive UUIDs in the file system table. Understanding how to diagnose each boot stage, execute emergency repairs, and perform a chroot rescue from live installation media restores full bootability without data loss.

Understanding the Linux Boot Stages and Failure Points¶

To resolve a boot crash efficiently, identify exactly which stage of the boot sequence failed.

BIOS / UEFI Firmware
       │
       ▼
Stage 1: GRUB Bootloader ──> [Fails here: "grub rescue>" or "error: unknown filesystem"]
       │
       ▼
Stage 2: Linux Kernel & Initramfs ──> [Fails here: "(initramfs)" or "dracut:/#" shell]
       │
       ▼
Stage 3: systemd (PID 1) & fstab ──> [Fails here: "Give root password for maintenance"]
       │
       ▼
Stage 4: Display Manager (GDM/LightDM) ──> [Fails here: Black screen with blinking cursor]

Failure Symptom	Active Boot Stage	Root Cause	Immediate Action
`grub rescue>` prompt	GRUB Stage 1 (MBR/EFI)	GRUB cannot locate its modules or `/boot/grub` directory; changed partition numbering	Manually specify root and prefix variables, load normal module
`(initramfs)` or `dracut` shell	Kernel initialization	Root partition dirty or damaged; missing storage controller driver in initramfs	Run manual `fsck` on root drive partition
"Emergency Mode" / Maintenance Prompt	systemd target execution	Non-essential secondary disk in `/etc/fstab` failed to mount or has corrupted UUID	Remount root as read-write; comment out failed drives in fstab
Hangs at manufacturer logo	Filesystem mounting	Root partition `/` is 100 percent full; system cannot write temporary PID lock files	Boot into rescue target; clean system logs and package caches
Black screen with blinking cursor	Graphical display manager	Proprietary graphics driver (Nvidia) crash; broken Wayland/Xorg configuration	Switch to TTY console (Ctrl+Alt+F3); purge broken graphics drivers

Phase 1: Escaping the `grub rescue>` Prompt¶

When GRUB displays error: no such partition followed by grub rescue>, the computer's firmware loaded GRUB's initial stage, but GRUB cannot find its secondary configuration files or filesystem drivers. This frequently happens after resizing disk partitions, installing a second operating system, or cloning drives.

grub rescue>
     │
     ▼
Type "ls" to Display All Storage Devices and Partitions
     │
     ▼
Inspect Each Partition: "ls (hd0,gpt2)/" Until Linux Directory Tree Appears
     │
     ▼
Set Environment Variables: "set root=(hdX,gptY)" and "set prefix=(hdX,gptY)/boot/grub"
     │
     ▼
Load Module: "insmod normal" Followed by "normal" to Launch Graphical GRUB Menu

Manual GRUB Rescue Commands¶

Execute this sequence at the grub rescue> prompt:

List all visible drives and partitions:
```
ls
```
GRUB will return a list of devices, such as (hd0), (hd0,gpt1), (hd0,gpt2), (hd1,msdos1).
Probe each partition to locate your Linux filesystem: Run the ls command against each partition individually until you find the one containing your operating system:
```
ls (hd0,gpt1)/
ls (hd0,gpt2)/
ls (hd0,gpt3)/
```
If a partition is unreadable or formatted as swap, GRUB returns: error: unknown filesystem.
When you hit the correct Linux partition, GRUB displays directory listings containing bin/, boot/, etc/, home/, usr/, and var/.
Configure GRUB pointers: Assuming your Linux root installation was discovered on (hd0,gpt2):
```
set root=(hd0,gpt2)
set prefix=(hd0,gpt2)/boot/grub
```
(Note: If your system uses a separate dedicated /boot partition, for example on (hd0,gpt1), set prefix=(hd0,gpt1)/grub instead).
Load the normal boot module:
```
insmod normal
normal
```
If the commands were entered correctly, the standard graphical GRUB boot menu will appear instantly. Select your normal Linux kernel and boot into your desktop. Once logged in, you must permanently reinstall GRUB to storage so the error does not recur on the next reboot.

Phase 2: Resolving `initramfs` and `dracut` Emergency Shells¶

If your computer passes the GRUB menu but halts at an (initramfs) or dracut:/# prompt, the Linux kernel loaded successfully, but it was unable to mount the root filesystem. This is almost always caused by an unclean shutdown (such as sudden power loss) that left the filesystem marked "dirty," exceeding the kernel's tolerance for automated mounting.

Running Manual File System Check (fsck)¶

In the emergency shell, automated repairs are paused to prevent silent data corruption. You must authorize filesystem repairs manually:

Identify the root partition device identifier: At the (initramfs) prompt, type:
```
blkid
```
Look for the partition formatted as ext4, xfs, or btrfs with the label or UUID corresponding to your root mount point (for example, /dev/sda2 or /dev/nvme0n1p2). If blkid is unavailable, check device nodes:
```
ls /dev/sd*
ls /dev/nvme*
```
Execute fsck with automatic confirmation: Run fsck directly against the unmounted root partition:
```
fsck -y /dev/nvme0n1p2
```
The -y flag answers "yes" to all repair prompts, allowing fsck to automatically fix corrupted inode counts, orphaned file pointers, and unlinked directory structures.
If the drive is heavily damaged, fsck will scroll hundreds of lines of corrected block allocations.
Reboot the system: Once fsck reports: FILE SYSTEM WAS MODIFIED and returns to the command prompt, type:
```
exit
```
If the prompt remains, execute a hard system restart:
```
reboot
```
The operating system will mount the repaired filesystem cleanly and proceed into the standard graphical login.

Phase 3: The Live USB Chroot Rescue Workflow¶

When GRUB is completely missing, the EFI bootloader partition was accidentally erased by a Windows update, or a kernel upgrade failed mid-installation, you cannot repair the system from local storage. You must boot from a live Linux USB installer and execute a chroot (change root) operation.

Boot from Live Linux USB Drive
              │
              ▼
Open Terminal: Identify Partitions Using "lsblk -f"
              │
              ▼
Mount Root Partition to /mnt (and EFI Partition to /mnt/boot/efi)
              │
              ▼
Bind System Virtual Filesystems (/dev, /proc, /sys, /run) into /mnt
              │
              ▼
Enter "chroot /mnt" (Your Shell is Now Operating Inside Your Broken OS)
              │
              ▼
Rebuild Initramfs and Reinstall GRUB to the Storage Drive

Complete Chroot Command Execution¶

Boot your computer using any standard Live Linux USB (such as an Ubuntu, Linux Mint, or Fedora live desktop).
Open a terminal window and identify your partition structure:
```
sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
```
Identify your primary Linux root partition (e.g., /dev/nvme0n1p2) and your small FAT32 EFI system partition (e.g., /dev/nvme0n1p1).
Mount the root filesystem:
```
sudo mount /dev/nvme0n1p2 /mnt
```
Mount the EFI partition (for modern UEFI systems):
```
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
```
(Note: On legacy BIOS systems using MBR partition tables, skip this step).
Bind system virtual directories: The Linux kernel requires access to virtual filesystem devices to configure bootloaders:
```
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
```
Enter the chroot environment:
```
sudo chroot /mnt /bin/bash
```
Your terminal prompt will change. You are now operating directly inside your installed operating system with full root administrative privileges.
Rebuild the initial ramdisk (initramfs): If a broken kernel update caused the boot failure, regenerate the ramdisk images:
Debian, Ubuntu, and Linux Mint:
```
update-initramfs -u -k all
```
Fedora, RHEL, and CentOS:
```
dracut --regenerate-all --force
```
Arch Linux:
```
mkinitcpio -P
```
Reinstall and update GRUB:

For UEFI systems:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB --recheck
update-grub

For legacy BIOS/MBR systems:
```
grub-install /dev/sda
update-grub
```
(Note: On Fedora/RHEL, use grub2-mkconfig -o /boot/grub2/grub.cfg instead of update-grub).

Exit and unmount cleanly:

exit
for i in /run /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
sudo umount /mnt/boot/efi
sudo umount /mnt
sudo reboot

Remove the USB flash drive when prompted. Your system will boot normally into GRUB.

Phase 4: Recovering from 100 Percent Full Root Disks¶

When a Linux system's root storage partition reaches 100 percent capacity, standard background system services cannot create temporary UNIX domain sockets, PID lock files, or temporary cache files in /tmp. This causes the system to freeze during the display manager launch, showing a black screen with a blinking cursor.

Booting into Emergency Mode to Free Disk Space¶

Turn on the PC and hold the physical Shift key (on BIOS systems) or tap the Esc key (on UEFI systems) to reveal the GRUB boot menu.
Highlight your default Linux kernel entry and press e on your keyboard to enter the GRUB configuration editor.
Locate the line beginning with linux or linux16 (this line contains kernel boot parameters such as quiet splash).
Use the arrow keys to scroll to the very end of that line, add a space, and append:
```
systemd.unit=emergency.target
```
(Alternatively, on older sysvinit systems, append single or init=/bin/bash).
Press Ctrl+X or F10 to boot with these temporary parameters.
The system will drop directly into an emergency root maintenance console without starting graphical interfaces or background daemons. Press Enter to access the shell.

Cleaning Disk Space and System Logs¶

Check disk utilization:
```
df -h
```
Verify whether /dev/root or / displays Use% 100%.
Purge oversized systemd journal logs: Systemd journal logs can silently grow to dozens of gigabytes if a malfunctioning background service encounters continuous errors:
```
journalctl --vacuum-size=100M
journalctl --vacuum-time=7d
```
Clean package manager download caches: Downloaded .deb or .rpm package archives linger indefinitely in system caches:

Ubuntu/Debian:

apt-get clean
apt-get autoremove --purge

Fedora/RHEL:
```
dnf clean all
```
Arch Linux:
```
pacman -Scc
```
Identify and delete runaway log files: Scan /var/log for massive log files created by runaway processes:
```
du -sh /var/log/* | sort -hr | head -n 10
```
If a log file (such as syslog or kern.log) has grown to 20 GB or larger, truncate it safely without deleting the file handle:
```
truncate -s 0 /var/log/syslog
```
Once disk utilization drops below 90 percent, type reboot to boot into your standard graphical desktop.

Phase 5: Fixing `/etc/fstab` Mount Errors¶

If your system displays: Give root password for maintenance (or press Control-D to continue) during boot, a secondary storage drive defined in your filesystem configuration table (/etc/fstab) failed to mount.

Editing fstab in Read-Write Mode¶

By default, the maintenance shell mounts the root partition in read-only mode to prevent file corruption. You must remount it as read-write before you can edit files:

Remount root as read-write:
```
mount -o remount,rw /
```
Inspect the system journal to identify the failing mount:
```
journalctl -xb | grep -i mount
```
Look for red error lines indicating which drive failed (for example: Timed out waiting for device /dev/disk/by-uuid/XXXX).
Edit the fstab configuration: Open /etc/fstab using a command-line editor:
```
nano /etc/fstab
```
Locate the line corresponding to the failing drive (often a secondary backup hard drive, external USB drive, or network NFS mount).
Temporary fix: Add a # character at the beginning of the line to comment it out completely.
Permanent safe fix: Add nofail and x-systemd.device-timeout=5 to the mount options column. The nofail flag instructs systemd to continue booting normally even if that specific drive is physically disconnected or powered off.
Save the file in nano by pressing Ctrl+O, press Enter, and exit with Ctrl+X.
Type reboot to restart the computer.

Summary Checklist for Linux Boot Recovery¶

Note the exact error prompt: grub rescue>, (initramfs), or maintenance shell.
In grub rescue>, use ls to find the Linux partition, set root and prefix, and load normal.
At the (initramfs) prompt, run fsck -y /dev/[partition] to repair dirty filesystems.
Boot a live Linux USB and use chroot /mnt to reinstall GRUB and rebuild initramfs.
Append systemd.unit=emergency.target to the GRUB kernel line to resolve 100% full root disks.
Clean system logs with journalctl --vacuum-size=100M and clear package caches.
Remount root as read-write with mount -o remount,rw / to fix broken /etc/fstab entries.
Add nofail to secondary drives in /etc/fstab to prevent boot hangs.