Fix GRUB Rescue Unknown Filesystem Error

You reboot after a routine update or a dead battery and your screen dumps you into a black terminal reading error: unknown filesystem. followed by Entering rescue mode... grub rescue>. No desktop, no menu, just a blinking prompt that looks like your machine forgot how to boot entirely.

Nine times out of ten this is GRUB losing track of where its config lives — usually because a partition UUID changed, a disk got reordered, or an OS install overwrote the boot sector without touching GRUB’s map. The actual filesystem is almost always fine. GRUB just can’t find it anymore.

This is fixable from that same rescue prompt, no live USB required in most cases. Give it about five minutes and you’ll be back at a login screen.

sudo fdisk -l

What the Unknown Filesystem Error Means and When It Hits

The exact message is error: unknown filesystem, followed by GRUB dropping you at grub rescue> instead of loading a menu. This isn’t a filesystem corruption message despite the wording — it means GRUB’s boot loader stage can’t identify the partition it’s pointed at, so it never gets far enough to read your actual OS.

GRUB stores a hardcoded reference to where its grub.cfg and core modules live. That reference is a device pointer like hd0,gpt2, not a filesystem type. When the disk layout changes underneath GRUB — a resized partition, a swapped drive order in BIOS, a cloned disk with different UUIDs — that pointer goes stale. GRUB tries to mount whatever’s sitting at that address, fails to recognize it, and throws the error.

You’ll hit this most often after:

• A kernel or GRUB package update that ran update-grub against the wrong device map
• Cloning or resizing a disk with tools like dd, Clonezilla, or a VM snapshot restore
• Deleting or shrinking a partition in GParted or fdisk without regenerating GRUB afterward
• A dual-boot Windows update that rewrote the boot sector and left Linux’s GRUB entry pointing at nothing
• A failed or interrupted apt upgrade that touched grub-pc or grub-efi mid-write

Whatever the cause, the effect is the same: the system stops dead before it ever reaches init, systemd, or a login prompt. No SSH, no logs to pull, nothing but that rescue shell. That’s actually good news — it means the fix lives in the same fifteen keystrokes you’re about to type, not in a data recovery tool.

Rebuild GRUB from Live USB (Most Common Fix)

This fixes the problem about 70% of the time, and it does not touch any of your files. You’re reinstalling a boot loader, not reformatting a disk. Boot any live image — Ubuntu 24.04 LTS, Debian 12, or Fedora 41 all work — and pick “Try Ubuntu” / “Try/Install” rather than the actual installer.

Identify Your Boot Mode and Root Partition

Once you’re at a desktop, open a terminal and run:

lsblk -f

This lists every partition with its filesystem type and label. Look for the one with an ext4 or btrfs filesystem that’s clearly your root — often labeled or sized like your main install (50GB+), not the 512MB-1GB EFI partition.

sudo fdisk -l /dev/sda

Replace /dev/sda with your actual disk (NVMe drives show up as /dev/nvme0n1, with partitions like /dev/nvme0n1p1). Check for a partition flagged EFI System — that confirms UEFI. Run:

efibootmgr

If this returns a boot list instead of EFI variables are not supported, you’re on UEFI. No output or an error means legacy BIOS.

Mount and Chroot Into Your System

Mount your root partition first:

sudo mount /dev/sda2 /mnt

No output means success. If you’re on UEFI, also mount the EFI partition:

sudo mount /dev/sda1 /mnt/boot/efi

Now bind the live environment’s kernel interfaces into the mount so chroot behaves like a real boot:

for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done

Chroot into it:

sudo chroot /mnt

Verify you’re actually inside your installed system, not the live environment:

ls /

You should see your normal directory tree — etc, home, var, usr — with your actual usernames under /home, not the live user’s.

Reinstall GRUB and Regenerate Config

Refresh package lists inside the chroot:

apt update

For BIOS systems, install and target the disk itself, not a partition:

apt install --reinstall grub-pc
grub-install /dev/sda

Expect Installing for i386-pc platform. followed by Installation finished. No error reported.

For UEFI systems, use the EFI package instead:

apt install --reinstall grub-efi-amd64
grub-install /dev/sda

Expect Installing for x86_64-efi platform. then done.

Either way, finish with:

update-grub

You’ll see a list like Found linux image: /boot/vmlinuz-6.11.0-... and Found initrd image: /boot/initrd.img-..., ending in done. This step rewrites grub.cfg with correct partition UUIDs — skip it and you’ll boot straight back into rescue mode with the same error. Exit the chroot with exit, unmount with sudo umount -R /mnt, and reboot.

Repair Corrupted Filesystem Metadata (Second Most Likely)

If GRUB reinstall completed clean but you still land in grub rescue> with unknown filesystem, the partition table and boot files were fine — the filesystem sitting on top of them isn’t. A handful of corrupted inodes or a broken superblock is enough to make GRUB refuse to mount the volume even though everything else checks out. This is the cause in roughly 15-20% of cases that survive the first fix.

Run Non-Destructive Filesystem Check First

Boot from a live USB (Ubuntu 22.04+, Debian 11+, or Fedora 35+ install media all work) and do not mount the target partition. Then run a dry-run check depending on filesystem type:

sudo fsck.ext4 -n /dev/sdXY

The -n flag means “answer no to every repair prompt” — it reports problems without touching the disk. For Btrfs:

sudo btrfs filesystem show /dev/sdXY

For XFS:

sudo xfs_repair -n /dev/sdXY

A corrupted filesystem typically shows something like Inodes that were part of a corrupted orphan linked list found or Pass 1: Checking inodes, blocks, and sizes followed by mismatched block counts. If any of these commands report clean output with no “Fix?” prompts, the filesystem is healthy and your problem lies elsewhere — likely stale UUIDs in grub.cfg.

Execute Repair if Errors Found

⚠️ Destructive command warning: the commands below write changes to disk and can move or delete inodes that fsck decides are unrecoverable. Back up anything critical first if you have another way to access the drive.

sudo fsck.ext4 -y /dev/sdXY

The -y flag auto-answers “yes” to every repair prompt instead of stopping to ask. Expect output ending in lines like Inode 131074 ref count is 3, should be 2. Fixed. and a summary block showing inode/block counts. For Btrfs:

sudo btrfs filesystem repair /dev/sdXY

For XFS:

sudo xfs_repair /dev/sdXY

On a 500GB+ drive, expect this to run for 3-10 minutes. Do not interrupt it — a killed repair mid-write is the one thing that turns recoverable corruption into a dead filesystem.

Remount and Verify Filesystem Health

sudo mount /dev/sdXY /mnt

If this succeeds with no output, the filesystem is mountable again. Check space and confirm data survived:

df -h /mnt

You should see a used/available split that roughly matches what you remember, not 0 across the board. Then check the kernel ring buffer:

dmesg | tail -20

Healthy output shows no I/O error or EXT4-fs error lines. If both checks are clean, proceed to reinstalling GRUB as covered above.

Fix Partition Table Mismatch (MBR vs GPT Confusion)

This one shows up after cloning a drive with dd or clonezilla, or after someone flips a motherboard’s boot mode from Legacy to UEFI (or back) without checking the disk first. GRUB looks for a filesystem where the partition table says there should be one, finds a structure it doesn’t recognize, and drops you to grub rescue> with error: unknown filesystem. This isn’t the most common cause of the error — that’s usually a missing grub.cfg or a botched fsck — but when it is the cause, the fix is less forgiving.

Detect Partition Table Type and Boot Mode

sudo parted /dev/sdX print

Look at the Partition Table: line. Partition Table: msdos means MBR. Partition Table: gpt means GPT. Now check what mode the system actually booted in:

sudo efibootmgr

If you get a real listing with BootCurrent: 0000 and boot entries, you’re in UEFI mode. If you get EFI variables are not supported on this system, you’re in legacy BIOS mode. A UEFI system paired with an msdos table (no EFI system partition) is the classic mismatch. You can confirm firmware mode independently with:

cat /sys/firmware/efi/fw_platform_size

Output of 64 or 32 means UEFI firmware is active; No such file or directory means legacy BIOS.

Convert MBR to GPT if Needed

If you’ve confirmed a UEFI system sitting on an MBR disk with no ESP, boot a live USB (Ubuntu 24.04 or SystemRescue 11 work fine) and run:

sudo gdisk /dev/sdX

Type p to print the current layout first — gdisk will show MBR: MBR only and a note that it found protective/hybrid entries. Review the partitions, then type w to write the GPT conversion. You’ll see a prompt like:

Found invalid GPT and valid MBR; converting MBR to GPT format.
THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'r' now.
Do you want to proceed? (Y/N):

Type Y. This converts in place and preserves existing partitions and data — it does not touch filesystem contents, only the partition table structure. Expect the final line to read The operation has completed successfully.

⚠️ Destructive alternative — do not use unless you’ve already backed up everything: parted /dev/sdX mklabel gpt wipes the entire partition table, not just converts it. Every partition entry is gone immediately, no confirmation prompt saves you here.

Reinstall GRUB After Partition Fix

Once the table is GPT and an EFI System Partition exists (or you’ve confirmed legacy mode matches an MBR table), re-run the grub-install and update-grub steps from the earlier section. The filesystem detection error should be gone on next boot.

Verify the Fix Worked Before Rebooting

Don’t reboot yet. Run three checks from inside the chroot first — skipping this is how people turn one rescue session into three. Rebooting on a hunch just means you’re back at grub rescue> in two minutes.

grub-probe /boot

This should print an actual filesystem type — ext4, xfs, btrfs — not throw unknown filesystem again. If it errors, your fix didn’t stick; go back and recheck /etc/fstab and the boot flag.

ls -la /boot/grub/grub.cfg

Confirm the file exists and isn’t zero bytes. No file here means update-grub never actually wrote a config, even if it printed no errors.

update-grub

Expect output like Found linux image: /boot/vmlinuz-6.11.0-13-generic and a matching Found initrd image line for every installed kernel. If it finds zero kernels, GRUB will boot to a blank menu with nothing to launch — fix that before you touch reboot.

Once all three look clean, exit and unmount everything in reverse order:

exit
sudo umount /mnt/boot/efi
sudo umount /mnt
sudo reboot

Unmounting cleanly flushes write caches so your GRUB changes actually land on disk instead of sitting in a buffer that a hard reboot silently drops.

Prevent Unknown Filesystem Errors in the Future

Once you’re booted, spend ten minutes making sure you never see grub rescue> again. Most repeat cases come from the same three habits: no /boot backup, no post-update check, and btrfs living where ext4 should be.

• Keep /boot on ext4. GRUB’s btrfs support has improved, but ext4 is still the safer choice for anything holding your kernel and initrd. If you’re on Fedora or openSUSE with btrfs as default, carve out a small separate ext4 /boot partition (512MB is plenty) during install.
• Test GRUB after every kernel update. Don’t assume it worked silently.

sudo grub-mkconfig -o /boot/grub/grub.cfg

Run this right after any kernel or GRUB package upgrade and confirm it lists your new kernel under Found linux image:.

• Back up grub.cfg before manual edits.

sudo cp /boot/grub/grub.cfg /boot/grub/grub.cfg.bak

One line, no excuse to skip it. Restoring this file beats rebuilding a broken config from scratch.

• Run fsck monthly from a live USB, not while the partition is mounted read-write.
• Never resize or move partitions without a backup image — parted and gparted both cause this exact error when interrupted mid-operation.

GRUB 2.12 (current on Ubuntu 25.10/26.04 and Debian 13) detects more filesystem types out of the box, but it still can’t fix a partition table you broke manually. Keep a live USB in the drawer — you’ll need it again eventually.

Troubleshoot If Fixes Don’t Work

If set root, grub-install, and a live-USB rebuild all fail to get you past unknown filesystem, stop suspecting software. Check the disk itself before you burn more time editing configs.

sudo smartctl -a /dev/sdX

Look at the SMART overall-health self-assessment test result line. PASSED means the drive is fine; FAILING_NOW means the disk is dying and no GRUB fix will hold.

sudo hexdump -C -n 512 /dev/sdX | head

This dumps the first 512 bytes — your MBR/boot sector. If it’s all 00 bytes, the boot sector itself is gone. That needs restoring from a backup image with dd or a data-recovery service — not something to attempt without a full disk clone first.

dmesg | grep -i error

Scan for repeated I/O error, dev sda, sector entries. Repeated hits at the same sector range point to failing hardware, not filesystem corruption.

If the disk is healthy and you still can’t boot, try single-user mode from the GRUB menu (press e on the boot entry, append single to the linux line, Ctrl+X). No GRUB menu at all means check BIOS/UEFI boot order first — it’s sometimes just pointed at the wrong disk. As a last resort on newer installs, systemd-boot is a lighter-weight replacement worth switching to once you’re back up.

Frequently Asked Questions

Related Reads

• How to Reset SSH Connection: 5-Minute Fixes

  SSH connection frozen or hanging? Copy-paste fixes ordered by likelihood. Covers hung sessions, timeout errors, and stal…

• Fix apt broken install: 5 quick solutions

  apt broken install won’t fix? Try these 5 solutions ordered by likelihood. Copy/paste commands, exact error fixes, all L…

• Disk Full But df Shows Space: Fix Inode Exhaustion

  Disk full error but df shows free space? Your inodes are exhausted. Find the culprit and fix it in 5 minutes with these …