boot always shows error: "unknown filesystem. grub rescue>"

Question

I have a dual boot with AVLinux (Debian based distro) and Windows 11 installed in two separate partitions and my PC is using EFI. My system was going well until yesterday, when I booted my PC and got Grub's black screen with the unknown filesystem. error message and a grub rescue> console to input commands.

Below is a picture of the screen:

Following the first answer of this question I could manage to launch Grub's menu from Grub's rescue console using ls to locate the Linux's partition where grub is installed and then issuing the commands to manually launch the normal kernel module inside Grub's folder. Giving that (hd0,gpt4) is my Linux the partition (where Grub is installed) I issued:

set prefix=(hd0,gpt4)/boot/grub
insmod normal
normal

Getting Grub's menu and managing to launch both the O.S.

Unfortunately I have to issue the same command at EVERY boot because I just can't get rid of that screen...

I already followed pretty much all the advices (like the one I linked before) which suggest to reinstall Grub using

sudo grub-install /dev/sda
sudo update-grub

commands (where /dev/sda refers to the drive where you want to reinstall Grub, for me should be /dev/nvme0n1) but nothing changed.

Of course I also tried to follow advices like this one which suggests to reinstall Grub from a live version of Linux (for me was Kali Linux) by mounting my Linux partition (again, the one with Grub installed in /boot/grub), my EFI partition, the efivars partition and then using chroot to issue grub-install:

sudo mount /dev/sdXY /mnt
sudo mount /dev/sdXX /mnt/boot/efi


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

mount -t efivarfs none /sys/firmware/efi/efivars 
grub-install /dev/sdX
update-grub
exit 

With: sdX = disk | sdXX = efi partition | sdXY = system partition (the one with Grub installed)

But again, nothing changed.

I also tried to use efibootmgr to change the order of the bootorder and to disable some bootnums but got no results.

I even tried to use boot-repair reading that it solved the problem for many, but - again - nothing...

It seems like at the very first stage of the boot Grub tries to launch its menu from the wrong location and thus I have to set manually the location of /boot/grub in order to get the menu screen. Unfortunately I don't know how to check this and, if so, how to configure Grub to look in the right place...

By the way, I'm not sure, but I think the problem arised after a Windows update.

Here the list of my partitions as can be seen in GParted:

where /dev/nvme0n1p3 is my Windows partition and /dev/nvme0n1p4 is Linux's one

And here is the output of efibootmgr's settings obtained issuing efibootmgr -v:

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0002,0001,0006,0003,0007,0008,0009,000A
Boot0000* Windows Boot Manager  HD(1,GPT,8b97638e-a366-4f45-be4e-60f9ef16f8dc,0x800,0x32000)/File(\EFI\MX21\grubx64.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* ubuntu    HD(1,GPT,8b97638e-a366-4f45-be4e-60f9ef16f8dc,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot0002* MX21  HD(1,GPT,8b97638e-a366-4f45-be4e-60f9ef16f8dc,0x800,0x32000)/File(\EFI\MX21\grubx64.efi)
Boot0003* debian    HD(1,GPT,8b97638e-a366-4f45-be4e-60f9ef16f8dc,0x800,0x32000)/File(\EFI\debian\grubx64.efi)
Boot0006* mx    HD(1,GPT,8b97638e-a366-4f45-be4e-60f9ef16f8dc,0x800,0x32000)/File(\EFI\mx\grubx64.efi)
Boot0007* Windows Boot Manager  HD(1,GPT,8b97638e-a366-4f45-be4e-60f9ef16f8dc,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)..BO
Boot0008* UEFI:CD/DVD Drive BBS(129,,0x0)
Boot0009* UEFI:Removable Device BBS(130,,0x0)
Boot000A* UEFI:Network Device   BBS(131,,0x0)

Someone has a clue on this? I don't know what to try anymore...

Answer 1

Ok, I solved it.

It came out the issue was the UEFI firmware running one of the bad boot entries in my EFI partition; more specifically it was the Boot0000 you can see in efibootmgr output.

In my case I couldn't manage to rearrange the boot order using efibootmgr, but I was able to do it changing the BBS boot priorities set in my UEFI firmware. More precisely the steps were:

• Rebooting my PC into the UEFI firmware
• Going into the BBS boot priorities section (in my UEFI it was located under: Settings\Boot\UEFI Hard Disk Drive BBS Priorities)
• Rearranging the boot order so that the first entry was the boot entry of my AVLinux O.S. with grub installed inside

A final reboot and it worked like a charm.

Hope this helps someone else

Answer 2

The problem is almost certainly due to the tiny (100MB) EFI partition. When Windows updated (if that was the cause), it may have perturbed the install to make room. I should say that I cannot explain every symptom you are seeing, but I can say 100MB is barely big enough for booting one OS, must less two.

Most BIOSes support multiple EFI partitions, and creating another (might as well be 1GB in size) is likely the best fix w/o a major disk reorg. I'd boot you live installer, and use use gparted to reduce the size of p4 by 1G, in the freed space, create a fat32 file system with the boot flags set like p1. Then do the manual boot repair using the new EFI partition to reinstall grub. Now you will have two BIOS boot menu entries for Kali, and you might need to use trial-and-error to find the right one. To fix that...

You have a bunch of junk in the BIOS boot menu. I'd visit p1, look in the EFI directory, and then remove the non-Windows entries; if that alone does not take care of it, then use efibootmgr (but if you do not clean the residual boot loaders, then they might keep popping up). There may be other files outside the EFI directory, but remove them only if you sure what you are doing (although a Window boot repair will likely fix any error you make if needed). Be sure not to remove your new BIOS boot menu, of course, but, likely it will be rediscovered if you do.