🚨 Linux Error: 'error: no such partition.' — Cause, Fix, and Troubleshooting Guide

Overview

error: no such partition. followed by a grub rescue> prompt means GRUB’s first-stage code loaded, but the specific partition it memorized as holding its modules and configuration (/boot/grub) is no longer at the location it expects. GRUB records a saved root — a (hdX,gptY) partition plus a UUID — at install time. If that partition is renumbered, its UUID changes, or the disk order shifts after a clone, restore, or resize, GRUB looks for a partition that no longer exists and drops to rescue.

error: no such partition.
Entering rescue mode...
grub rescue>

This is distinct from error: no such device, where GRUB cannot find the whole disk it expects. Here GRUB found the disk but the partition number or UUID no longer matches. If you are seeing the device variant instead, use the grub rescue> … no such device guide. The recovery pattern below is similar, but the emphasis is on re-locating the partition that holds /boot/grub rather than the disk.

Symptoms

• Boot ends at a bare grub rescue> prompt with only a handful of commands available.
• The screen shows error: no such partition. (note: partition, not device).
• It appeared after cloning a disk, restoring an image to different hardware, resizing/renumbering partitions, or reordering/adding disks.
• Only ls, set, insmod, unset, and a few other commands respond; linux/initrd are not yet available because the normal module has not loaded.

Common Root Causes

Common production causes first:

1. Partition renumbered — a partition-table edit, delete/recreate, or GParted operation shifted the boot partition from, say, (hd0,gpt2) to (hd0,gpt3), so GRUB’s embedded prefix points at the wrong slot.
2. UUID changed — a mkfs, restore, or filesystem recreation gave the boot partition a new UUID that no longer matches GRUB’s saved root.
3. Disk cloned or imaged — the clone landed on a disk with a different partition layout, or the source and target disagree on numbering.
4. Disk reordered — adding, removing, or re-cabling drives changed which disk is (hd0) vs (hd1), so GRUB probes the wrong disk’s partitions.
5. Partial GRUB update — an interrupted grub-install left the core image pointing at a stale partition prefix.

How to diagnose

At the grub rescue> prompt the command set is limited, but enough to locate the real boot partition.

# What partition did GRUB memorize?
set
# look at prefix=(hdX,gptY)/boot/grub and root=(hdX,gptY)

# What disks and partitions actually exist right now?
ls
# lists (hd0), (hd0,gpt1), (hd0,gpt2), (hd0,gpt3), ...

# Probe each listed partition until you find /boot/grub
ls (hd0,gpt2)/
ls (hd0,gpt2)/boot/grub
ls (hd0,gpt3)/boot/grub

set shows the partition GRUB thinks it lives on; ls shows the partitions that exist. When those disagree, you have found the cause. Walk ls (hdX,gptY)/boot/grub across each partition until one lists the GRUB module files (*.mod, normal.mod, grub.cfg). That partition is your new root.

If /boot is on its own partition, the modules live at (hdX,gptY)/grub (no /boot prefix). Check both paths.

Fixes

Fix 1 — boot once from the grub rescue> prompt

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

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

If /boot is a separate partition, use set prefix=(hd0,gpt3)/grub instead. If insmod normal returns error: no such partition. again, your root guess is wrong — go back and ls the other partitions. Once normal runs you land in the regular GRUB menu; boot your usual entry.

If the menu does not appear but you have a working shell-like GRUB, you can also load the kernel by hand:

grub rescue> set root=(hd0,gpt3)
grub rescue> insmod normal
grub rescue> insmod linux
grub rescue> linux /boot/vmlinuz-6.8.0-40-generic root=UUID=1111-2222 ro
grub rescue> initrd /boot/initrd.img-6.8.0-40-generic
grub rescue> boot

Replace the kernel/initrd filenames with the ones present in ls (hd0,gpt3)/boot/ and the UUID with the real root filesystem UUID.

Fix 2 — make the fix permanent (reinstall GRUB)

Booting from rescue is temporary; the stale prefix returns on the next boot. Once you are in the OS (or in a live-USB chroot), reinstall GRUB so the correct partition and UUID are embedded again, then regenerate the config.

Warning: grub-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, on UEFI, efibootmgr -v before running it. For BIOS installs, pass the whole disk (/dev/sda), not a partition (/dev/sda2).

# Confirm which partition holds /boot/grub
sudo grub-probe -t device /boot/grub     # Debian/Ubuntu
sudo blkid
lsblk -f

# BIOS (legacy) — Debian/Ubuntu
sudo grub-install /dev/sda
sudo update-grub

# BIOS (legacy) — RHEL/Rocky
sudo grub2-install /dev/sda
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# UEFI — Debian/Ubuntu (do NOT pass a disk device)
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
sudo update-grub

Fix 3 — chroot from a live USB (if you cannot boot at all)

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 Fix 2 commands for your firmware/distro

After grub-install + update-grub, the regenerated grub.cfg references the current partition and UUID, so the next boot skips rescue entirely.

What to watch out for

• Partition vs device: no such partition and no such device look alike but point at different layers. If ls shows the disk ((hd0)) but not your partition, this partition guide applies; if ls shows no matching disk at all, use the device guide.
• Wrong disk target: the single biggest hazard is grub-install /dev/sdb when the boot disk is /dev/sda. Always verify with lsblk first.
• Separate /boot: forgetting the /grub (vs /boot/grub) prefix path is the most common reason insmod normal keeps failing.
• UUID drift after clone: after imaging, run blkid and confirm /etc/fstab and GRUB agree on UUIDs; reinstall GRUB rather than hand-editing grub.cfg, which is overwritten on the next update.
• UEFI boot entries: on UEFI, a stale efibootmgr entry can point firmware at the wrong disk even after a good GRUB install; check efibootmgr -v.

Related

• grub rescue> … no such device
• Kernel panic - not syncing: VFS: Unable to mount root fs
• ALERT! UUID=… does not exist. Dropping to a shell!

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