grub rescue> error: unknown filesystem

I recently merged two partitions on my hard drive using Disk Management system utility in Windows 10.

Since I use the same drive to dual-boot Windows 10 and Arch Linux, having one less partition on my drive changed the GPT partition numbers and GRUB was unable to recognize the right partition where to locate its modules.

I encountered this same problem several times in the past, so I just googled the error message trying to remember the few commands that I need to run to temporarily set the right partition in GRUB and be able to boot normally.

This post is mostly a reminder for myself since I always forget these steps. (and for you, if your Google search led you here)

Now, let’s dive into the actual solution for this error.

The error message #

This is how the error message looked like exactly.

error: unknown filesystem.
Entering rescue mode...
grub rescue>

The solution I usually use #

This error frequently happens to GNU/Linux users. Therefore, there are plenty of posts and videos explaining how to fix it.

My Google search always lead me to this Ask Ubuntu answer.

In addition, having a look at the ArchWiki is always a good idea. I recommend reading this wiki page about GRUB to get a better understanding of what’s really happening with your GNU/Linux system.

Guessing the boot partition number #

If you don’t memorize your partition table by heart like me, your first mission is to guess the partition where your /boot/ directory is located.

There are three common scenarios.

1. Your boot partition is encrypted: If you fall into this category then you’ve chosen the wrong guide. However, this blog post may be helpful for you.
2. Your /boot/ directory is located in the root partition: You’ll have to find which partition is your root partition. It is usually recommended to use ext4 filesystem for root partitions. A typical GNU/Linux directory structure is explained in this post.
3. You have a separate boot partition: I installed my Arch Linux using LVM on LUKS system encryption method. Hence, I have a separate boot partition that I formatted using mkfs.ext4. ext2, ext3 and ext4 are all supported for the boot partition on modern GNU/Linux distributions.

Listing all partitions #

The first step is to list all partitions.

grub rescue> ls
(hd0) (hd0,gpt6) (hd0,gpt5) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)

Filesystem of each partition #

For each partition, we need to find out what filesystem is being used.

grub rescue> ls (hd0,gpt1)
(hd0,gpt1): Filesystem is unknown.

If the filesystem is unknown then we just ignore the partition.

I tried this same command with all partitions until I found out that my gpt5 partition is using ext2. I don’t have any ext2 partition, but I guess that GRUB is not very accurate and mistakes ext4 for ext2.

grub rescue> ls (hd0,gpt5)
(hd0,gpt5): Filesystem is ext2.

The content of ext2 partitions #

At this stage, we need to find out where GRUB modules are located.

Add a / to the last command to show the content of gpt5.

grub rescue> ls (hd0,gpt5)/
./ ../ lost+found/ vmlinuz-linux initramfs-linux.img initramfs-linux-fallback.img grub/

The GRUB modules directory #

grub/ is the directory we’re trying to find.

Let’s list the content of grub/ to make sure it’s the right GRUB modules directory.

grub rescue> ls (hd0,gpt5)/grub/
./ ../ x86_64-efi/ themes/ fonts/ grubenv grub.cfg

If your /boot/ directory is located in the root partition, your GRUB modules path is probably boot/grub/.

Booting #

We have to set root and prefix variables.

Make sure to replace gpt5 by the partition where your /boot/ directory is located.

grub rescue> set root=(hd0,gpt5)

prefix path depends on where your GRUB modules directory is located. Make sure to read the previous section of this post to find out the right path.

grub rescue> set prefix=(hd0,gpt5)/grub

We load the normal module.

grub rescue> insmod normal

And finally, we try booting the system normally.

grub rescue> normal

Fix boot partition permanently #

In UEFI systems, the boot partition is hard-coded in the grubx64.efi file. This file is usually located in /esp/EFI/grub/ in Arch Linux.

I don’t know if there is a way to safely edit the hard-coded value in this file, so I just reinstalled my GRUB.

Find out your EFI system partition mount point #

grub-install does three things:

1. Generates a new grubx64.efi file in your EFI system partition;
2. Adds a new boot option for the generated grubx64.efi file (using efibootmgr);
3. Installs GRUB modules to /boot/grub/x86_64-efi/ (or /grub/x86_64-efi/).

Therefore, your EFI system partition needs to be mounted.

On my Arch Linux, my EFI system partition gets automatically mounted to /esp/ using fstab. This may be the case on your GNU/Linux system too.

Let’s detect the EFI system partition using fdisk.

$ sudo fdisk -l /dev/sda | grep -i efi
/dev/sda2    1085440   1290239    204800   100M EFI System

Thus, sda2 is my EFI system partition.

Then, we use df to determine the mount point of sda2.

$ df | grep sda2
/dev/sda2                                 98304    32830      65474  34% /esp

If your EFI system partition does not get automatically mounted at startup, you need to mount it manually. We will use /esp/ as the mount point (use a different path if /esp/ directory already exists on your system).

$ sudo mkdir /esp && sudo mount /dev/sda2 /esp

Reinstalling GRUB #

Reinstalling GRUB depends highly on how you initially installed your GNU/Linux distribution. I use Arch Linux installed in UEFI mode and the following command did the trick for me.

$ sudo grub-install --target=x86_64-efi --efi-directory=/esp/ --bootloader-id=GRUB