🚨 Linux Error: grub rescue> ... no such device — Cause, Fix, and Troubleshooting Guide

Summary

error: no such device: <uuid> followed by a grub rescue> prompt means GRUB’s first-stage code loaded, but it cannot find the partition that holds its modules and configuration (/boot/grub). The disk layout GRUB memorized at install time no longer matches reality — a partition was moved, resized, renumbered, its UUID changed, or the disk order shifted. From the grub rescue> prompt you can point GRUB at the real boot partition, load the normal module, boot once, and then reinstall GRUB so the fix is permanent.

Common Symptoms

• Boot ends at a bare grub rescue> prompt with almost no commands available.
• The screen shows error: no such device: and a UUID or (hdX,gptY) reference.
• It appeared after resizing/moving a partition, restoring an image, adding/removing a disk, or a partial GRUB update.

On the console:

error: no such device: 8f3a1c2e-1234-4d56-9abc-0f1e2d3c4b5a.
Entering rescue mode...
grub rescue>

(A related variant, error: unknown filesystem, is fixed the same way.)

Most Likely Causes of the ‘grub rescue> no such device’ Error

Common production causes first:

1. Partition UUID/location changed — a resize, mkfs, or clone changed the boot partition so GRUB’s embedded prefix/root is stale.
2. Disk reordering — adding, removing, or re-cabling disks changed (hd0) vs (hd1), so GRUB looks on the wrong drive.
3. /boot overwritten or partition renumbered by a partition-table edit or restore.
4. Broken GRUB install — an interrupted grub-install/grub2-install or a /boot on an unsupported/uninstalled filesystem module.
5. Bootloader on the wrong disk after imaging, where firmware boots a disk whose GRUB points elsewhere.

Quick Triage

# At the grub rescue> prompt (limited command set)

# What did GRUB memorize?
set

# What disks/partitions does GRUB actually see?
ls

# Probe each partition for a Linux root / /boot
ls (hd0,gpt2)/
ls (hd0,gpt2)/boot/grub

Walk ls (hdX,gptY)/ across the listed partitions until you find the one containing /boot/grub (or /grub if /boot is its own partition). That partition is your new root.

Diagnostic Commands

# --- From grub rescue> ---
set                       # shows prefix= and root= GRUB is using
ls                        # lists (hd0), (hd0,gpt1), (hd0,gpt2), ...
ls (hd0,gpt2)/boot/grub   # find where grub modules actually live

# --- After booting, or from a live USB chroot ---
sudo grub-probe -t device /boot/grub     # Debian/Ubuntu: which device holds /boot
sudo grub2-probe -t device /boot         # RHEL/Rocky
lsblk -f
sudo blkid
cat /etc/fstab
# EFI systems: verify the boot entry points at the right disk
sudo efibootmgr -v

set shows what GRUB thinks; ls shows what exists. Reconcile the two.

Fix / Remediation

Step 1 — boot once from the grub rescue> prompt

Point GRUB at the partition that actually holds /boot/grub, then load normal.

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

If /boot is a separate partition, prefix is (hdX,gptY)/grub (no /boot). If insmod normal reports “no such device”, your root is wrong — go back and ls more partitions. This gets you into a normal GRUB menu; boot your usual entry.

Step 2 — make the fix permanent (reinstall GRUB)

Once booted (or from a live USB chroot), reinstall GRUB and regenerate its config so the correct prefix/UUID is embedded again.

Warning: grub-install/grub2-install writes to a disk’s boot area. Installing to the wrong disk (/dev/sdb instead of /dev/sda) can make the machine unbootable. Confirm the boot disk with lsblk and efibootmgr -v before running it, and pass the whole disk (/dev/sda), not a partition (/dev/sda1), for BIOS installs.

BIOS (legacy) systems:

# Debian / Ubuntu
sudo grub-install /dev/sda
sudo update-grub

# RHEL / Rocky
sudo grub2-install /dev/sda
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

UEFI systems (do NOT pass a disk device; the EFI partition target is implied):

# Debian / Ubuntu (EFI partition mounted at /boot/efi)
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
sudo update-grub

# RHEL / Rocky
sudo grub2-install --target=x86_64-efi --efi-directory=/boot/efi
sudo grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg

Step 3 — if you must chroot from a live USB

sudo mount /dev/sda2 /mnt            # root
sudo mount /dev/sda1 /mnt/boot       # separate /boot, if any
sudo mount /dev/sda1 /mnt/boot/efi   # EFI partition, if UEFI
for d in dev proc sys; do sudo mount --bind /$d /mnt/$d; done
sudo chroot /mnt
# then run the Step 2 commands for your firmware/distro

Validation

sudo grub-probe -t device /boot/grub   # resolves to the correct device
sudo efibootmgr -v                     # (UEFI) boot entry points at the right disk
lsblk -f

Reboot and confirm you reach the GRUB menu and then the OS with no grub rescue> prompt.

Prevention

• Avoid renumbering or resizing the boot partition without reinstalling GRUB afterward.
• After adding/removing disks, verify boot order in firmware and re-run grub-install/update-grub (or grub2-install/grub2-mkconfig) if the boot disk moved.
• Keep /boot on a filesystem GRUB supports (ext4 is safest) and reference partitions by UUID.
• On UEFI, keep a healthy EFI system partition and confirm efibootmgr -v entries after imaging.
• Snapshot before partition surgery, and enable a serial/remote console so you can drive the grub rescue> prompt on headless hosts.

Related Errors

• ALERT! UUID=… does not exist. Dropping to a shell!
• Kernel panic - not syncing: VFS: Unable to mount root fs
• mount: wrong fs type, bad option, bad superblock
• Dependency failed for mountpoint
• UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Final Notes

grub rescue> looks fatal but is one of the most recoverable boot failures: ls to find /boot/grub, set root/set prefix, insmod normal, normal to boot once, then reinstall GRUB to bake the fix in. The only real hazard is grub-install — always confirm the target disk before you run it.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.