The GRUB rescue prompt, explained and recovered

Landing at a black screen with grub rescue> (often preceded by “error: no such device” or “unknown filesystem”) means the machine's firmware found GRUB's first stage, but GRUB cannot locate the partition holding the rest of itself, its configuration, and the menu. The operating system itself is almost always intact; the map to it is what broke. Typical triggers are a deleted or resized partition (frequently from a dual-boot change in Windows), a moved disk, or a cloned drive. Recovery has two phases: boot the system once from the rescue prompt, then repair GRUB so the next boot is normal.

Phase one: find the Linux partition from the prompt

  1. List what GRUB can see: at the prompt, type ls to get devices like (hd0) and (hd0,msdos1) or (hd0,gpt2).
  2. Probe each partition for the boot files: ls (hd0,gpt2)/boot/grub (adjusting the partition) succeeds on the partition containing GRUB's modules; one containing a Linux root shows /boot with kernel files (vmlinuz-...).
  3. Point GRUB at it and load the normal module: set prefix=(hd0,gpt2)/boot/grub, then set root=(hd0,gpt2), then insmod normal and normal. The familiar menu should appear and the system boots. (If the partition has a separate /boot, the prefix path omits nothing; if root holds /boot, the same commands apply with that partition.)

Phase two: make it permanent (after booting)

  1. Reinstall and rebuild GRUB from the running system: on UEFI systems, sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB (distributions wrap this; the plain sudo grub-install /dev/sdX suits BIOS/MBR), followed by sudo update-grub (or grub2-mkconfig on Fedora/RHEL family) to regenerate the menu with the current partition layout.
  2. If the system will not boot even manually, use a live USB of the same distribution family: mount the installed root (and boot/EFI partitions), chroot into it, and run the same install and config commands there. Distribution installers often include a “repair bootloader” path that automates exactly this.

Why it happened, so it does not repeat

  1. Partition changes: deleting the Linux partition from another OS, shrinking partitions, or disk utilities renumbering them, GRUB's stored prefix points at a partition that moved or vanished.
  2. Disk order changes: adding or removing drives, or switching SATA/NVMe modes, can renumber hd0 and friends.
  3. An interrupted system update that rewrote GRUB's configuration against a layout that then changed again before reboot.

Common questions

Is my Linux installation gone? Almost certainly not. The rescue prompt means the loader lost its map; the probing commands above usually reveal the intact system within a minute. “Unknown filesystem” for a partition can also mean that specific partition is not the Linux one, keep probing the others.

grub rescue differs from grub> , does it matter? Yes. The plain grub> prompt has the normal module loaded and more commands available. The rescue prompt is the minimal fallback; the insmod normal step is what promotes it to the full shell, which is why it comes first.

It happened after a Windows update on a dual-boot machine, why? Windows updates occasionally rewrite the UEFI boot order or the disk layout assumptions, promoting Windows Boot Manager or invalidating GRUB's pointers. Repairing GRUB (phase two) and, in the firmware settings, restoring the GRUB entry's priority addresses it.

Related errors

Kernel panic: not syncing · No such file or directory · dpkg returned an error code