GRUB Rescue - Boot Failure Recovery

Recover a server that won't boot due to GRUB errors, missing initramfs, or wrong fstab entries.

A server that fails to boot usually lands in a GRUB rescue prompt or drops to emergency mode. This guide covers the most common scenarios and how to fix them.

Most VPS providers (including VirtFusion) offer a rescue/recovery mode from the control panel. Boot into it to access your disk without GRUB intervention.

Scenario 1: `grub rescue>` Prompt

This appears when GRUB cannot find its own files. You're dropped into a minimal shell.

# List available partitions
ls

# Try each to find the one with /boot/grub
ls (hd0,1)/
ls (hd0,1)/boot/grub/

# Once found, set the correct partition
set prefix=(hd0,1)/boot/grub
set root=(hd0,1)

# Load normal module and boot
insmod normal
normal

After booting successfully, fix GRUB permanently (see reinstall section below).

Scenario 2: `error: unknown filesystem` or Missing `/boot`

# In grub rescue prompt, try to load linux module
insmod linux
insmod ext2

# Find and set root
ls (hd0,gpt2)/
set root=(hd0,gpt2)

# Load kernel and initrd manually
linux /vmlinuz root=/dev/sda2 ro
initrd /initrd.img
boot

Scenario 3: Edit Kernel Line at Boot

When the GRUB menu appears, press e to edit the boot entry:

Find the linux line
Append init=/bin/bash to boot into a shell
Press Ctrl+X to boot

Once in the shell:

# Remount root as read-write
mount -o remount,rw /

# Make your fixes (fstab, etc.)
# Then reboot
exec /sbin/init
# or
/sbin/reboot -f

Scenario 4: Reinstall GRUB from Live ISO / Rescue Mode

Boot from a live ISO or your provider's rescue mode, then:

# Identify partitions
lsblk
fdisk -l

# Mount root partition
mount /dev/sda2 /mnt

# Mount /boot if it's a separate partition
mount /dev/sda1 /mnt/boot

# Bind-mount required virtual filesystems
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts

# Chroot into the system
chroot /mnt

# Reinstall GRUB to the disk (not partition)
grub-install /dev/sda
update-grub

# Regenerate initramfs
update-initramfs -u -k all

# Exit and reboot
exit
umount -R /mnt
reboot

Scenario 5: Wrong UUID in /etc/fstab

A common cause of boot failure after disk changes. The system drops to emergency mode with "Failed to mount /data".

# In emergency shell, list block device UUIDs
blkid

# Edit fstab with correct UUIDs
nano /etc/fstab

# Example correct fstab entry:
# UUID=abc123-... /data ext4 defaults 0 2

# Remount all
mount -a

Always use UUIDs (not /dev/sdX device names) in /etc/fstab. Device names can change after disk additions or reboots.

Fix Broken initramfs

Missing or corrupted initramfs causes a kernel panic at boot:

# From chroot (see Scenario 4 above)
update-initramfs -c -k all     # recreate for all kernels
update-initramfs -u -k $(uname -r)  # update for current kernel
update-grub

GRUB Configuration

Main config file, do not edit directly:

# /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_TIMEOUT_STYLE=menu       # show menu (useful for recovery)
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Apply changes:

update-grub

Keep a Previous Kernel

After a bad kernel update, boot with an older kernel from the GRUB menu:

# List installed kernels
dpkg --list | grep linux-image

# Remove a broken kernel
apt-get remove linux-image-6.x.x-xx-generic

# Hold a kernel version to prevent upgrades
apt-mark hold linux-image-$(uname -r)

Prevent Future Issues

# Test fstab before rebooting
mount -a --fake -v

# Keep at least 2 kernels installed
# /etc/apt/apt.conf.d/01autoremove-kernels
# Unattended-Upgrade::Remove-Unused-Kernel-Packages "false";

GRUB Rescue - Boot Failure Recovery

On this page