Fixing a Linux System Stuck at 'grub rescue>'

Instead of GRUB’s normal menu or a booting kernel, you get a bare grub rescue> prompt — GRUB’s own minimal fallback shell, which means it couldn’t locate its normal configuration or the files it needs to boot anything at all.

Understanding what grub rescue actually means

Reaching grub rescue> specifically (as opposed to the fuller grub> prompt) means GRUB’s core image loaded, but it couldn’t find its own /boot/grub directory — usually because it doesn’t know which disk/partition holds it, its stored partition UUID reference is stale (after a disk swap, a partition resize, or a dual-boot OS install overwriting the boot sector), or that partition’s filesystem itself is damaged.

Step 1: find out what GRUB can actually see

grub rescue> ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd1) (hd1,gpt1)

This lists every disk and partition GRUB’s rescue environment can detect at all — if your expected disk isn’t listed here, this is a hardware/BIOS detection issue, not something GRUB configuration alone can fix.

Step 2: find which partition actually holds your Linux filesystem

grub rescue> ls (hd0,gpt2)/

Try each partition until one lists a familiar Linux root directory structure (etc, bin, boot, and so on). Once found, note it — this is the partition GRUB needs pointed at correctly.

Step 3: manually set the root and boot the kernel directly

This gets you booted this one time, without yet fixing the underlying configuration:

grub rescue> set root=(hd0,gpt2)
grub rescue> set prefix=(hd0,gpt2)/boot/grub
grub rescue> insmod normal
grub rescue> normal

This last step, if the located partition genuinely has a valid /boot/grub, should bring up the full GRUB menu — from which you can select and boot Linux normally, exactly as if this whole rescue detour hadn’t happened.

Step 4: fix it permanently from inside the booted system

Once actually booted, the real fix is regenerating GRUB’s configuration and reinstalling its boot sector so the next boot doesn’t repeat the same rescue-mode detour:

sudo grub-install /dev/sda
sudo update-grub          # Debian/Ubuntu
# or
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # Fedora/RHEL

If you can’t boot even with manual root-setting

If no partition in the ls output contains a recognizable /boot/grub, boot from a live USB/rescue image instead, mount your actual root partition, and reinstall GRUB from there — chrooting into the real system to run grub-install and update-grub with full access to the actual filesystem and package tools:

sudo mount /dev/sda2 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt
grub-install /dev/sda
update-grub
exit

Why this happens most often

The most common triggers are installing a second OS (especially Windows after Linux, since Windows’ installer overwrites the boot sector unconditionally without any awareness of GRUB), resizing or reordering partitions with a partition already referenced by UUID that no longer matches, and swapping or cloning a disk without updating GRUB’s stored device references afterward. Reinstalling GRUB (step 4) after any of these operations, proactively, avoids ever needing the rescue prompt in the first place.