GRUB menu not showing up after turning on the PC

[raj]

I have one SSD and one HDD on my computer, the SSD has windows 10 pre-installed on it and I installed Garuda by partitioning my HDD and freeing up 100 GB size for Garuda installation.

While installing Garuda Linux I chose Replace partition and used 100 GB free space for Garuda installation.

After completing the installation of Garuda I checked the checkbox of Restart now and everything worked perfectly, but when I started my computer for the second time the GRUB menu didn't show up and I got GRUB error like this:

Welcome to GRUB!
error: no such device: 267831a0-3b22-4248-b030-7cc4fceeca4d
error: unknown filesystem
Entering rescue mode...
grub rescue> _

I tried re-installing GRUB on ESP and repairing GRUB configuration file using garuda-boot-repair utility but nothing changed.

I also tried to find the solutions online but could not find any solution that can help me with this problem, so I decided to post here.

[Bro]

Where did you install your bootloader (EFI partition), and where did you install GRUB? Your answer lies in there.

[filo]

Maybe this can help.
It explains very well IMO how to find your ESP and manually reinstall the grub there.

How to chroot Garuda Linux

From Grub fails after update - #3 by librewish Some unlucky times that your system is not bootable and the only advised option is to use chroot from a Live ISO to repair the installed system (for example, to (re)install the bootloader), here is the suggested method: steps required to chroot to your installed Garuda installation (btrfs) Boot to a Garuda usb Live ISO Start a terminal and Find your installed system (btrfs) partition, you need the /dev/<something> part. lsblk -f Warning: Remem…

[SGS]

lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 232,9G  0 disk 
├─sda1   8:1    0   260M  0 part /boot/efi
└─sda2   8:2    0 232,6G  0 part /run/timeshift/backup
                                 /var/tmp
                                 /var/log
                                 /var/cache
                                 /home
                                 /root
                                 /srv
                                 /

[raj]

@Bro

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 931.5G  0 disk
├─sda1        8:1    0 831.5G  0 part
└─sda2        8:2    0   100G  0 part /root
zram0       254:0    0   650M  0 disk [SWAP]
zram1       254:1    0   650M  0 disk [SWAP]
zram2       254:2    0   650M  0 disk [SWAP]
zram3       254:3    0   650M  0 disk [SWAP]
zram4       254:4    0   650M  0 disk [SWAP]
zram5       254:5    0   650M  0 disk [SWAP]
zram6       254:6    0   650M  0 disk [SWAP]
zram7       254:7    0   650M  0 disk [SWAP]
zram8       254:8    0   650M  0 disk [SWAP]
zram9       254:9    0   650M  0 disk [SWAP]
zram10      254:10   0   650M  0 disk [SWAP]
zram11      254:11   0   650M  0 disk [SWAP]
nvme0n1     259:0    0 238.5G  0 disk
├─nvme0n1p1 259:1    0   260M  0 part /efi
├─nvme0n1p2 259:2    0    16M  0 part
├─nvme0n1p3 259:3    0 237.4G  0 part
└─nvme0n1p4 259:4    0   850M  0 part

[filo]

Your GRUB should go into

nvme0n1p1

[raj]

@filo
Yes and my GRUB is there, I know

/efi/EFI/Garuda/GRUBX64.efi

[filo]

What seems strange to me is that the mount point is /efi instead of /boot/efi, but maybe this could be ok.
I think it could help checking your:
lsblk -f to check the UUIDs
/etc/fstab, to see if your /boot/efi (or /efi in your case?) points to nvme0n1p1
efibootmgr -v

[raj]

@filo
Here's the lsblk -f output :

NAME        FSTYPE FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1      ntfs         DATA     1A56A70456A6E02D
└─sda2      btrfs                 267831a0-3b22-4248-b030-7cc4fceeca4d   89.8G     9% /var/cache
zram0                                                                                 [SWAP]
zram1                                                                                 [SWAP]
zram2                                                                                 [SWAP]
zram3                                                                                 [SWAP]
zram4                                                                                 [SWAP]
zram5                                                                                 [SWAP]
zram6                                                                                 [SWAP]
zram7                                                                                 [SWAP]
zram8                                                                                 [SWAP]
zram9                                                                                 [SWAP]
zram10                                                                                [SWAP]
zram11                                                                                [SWAP]
nvme0n1
├─nvme0n1p1 vfat   FAT32 SYSTEM   E6C7-43C7                               230M    10% /efi
├─nvme0n1p2
├─nvme0n1p3 ntfs         OS       A81AC90B1AC8D788
└─nvme0n1p4 ntfs         RECOVERY 0C6AB3D16AB3B5B4

And for efibootmgr -v :

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000
Boot0000* Windows Boot Manager  HD(1,GPT,fecf6faa-5aa9-4d85-97a2-a7e832a30b36,0x800,0x82000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.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* Garuda        HD(1,GPT,fecf6faa-5aa9-4d85-97a2-a7e832a30b36,0x800,0x82000)/File(\EFI\GARUDA\GRUBX64.EFI)

And I have confirmed the UUID from lsblk -f output, it's the same UUID that shows in the grub: no such device error.

[filo]

Seems ok
My only concern Is in that mount point in /efi instead of /boot/efi...

[raj]

@filo
Don't worry about mount point it's /efi instead of /boot/efi because I changed it to /efi, the reason for that was: I read in arch wiki somewhere that /efi is the new replacement for the older(and still used in many distros) /boot/efi mount point

[filo]

Is this consistent with your /etc/fstab?
Sorry for asking, I'm not that expert but always saw /boot/efi here

[Bro]

@raj

instead of /boot/efi because I changed it to /efi,

/efi is the default in Arch, yes. But not Garuda. Garuda uses /boot/efi. And Garuda uses the Calamares installer, which (I'm guessing) is looking for /boot/efi instead.

I may be totally wrong.

[raj]

@Bro

Yes, but the thing is when my mount point was /boot/efi then also the problem was still there it's not like first I changed the mount point and then the problem occurred

And I don't think mount point matters after the GRUB is installed in ESP(This is just my thought)

[raj]

@filo
Are you asking about UUID?

[filo]

No, it's ok.
If you had the issue also before, mounting on /boot/efi (which I'd go back to anyway), I don't think there's much to check there. Maybe just that it doesn't point to the wrong disk, but I really don't believe.
Apart from that, secure boot is off?
I don't have other ideas...

[raj]

@filo
Yes secure boot is off.

[Bro]

@raj

And I don't think mount point matters after the GRUB is installed in ESP

Yeah, but does GRUB know your boot partition has been sleeping around?

[filo]

I think you could also try with the grub rescue commands to boot (search on internet for details), e.g.:

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

or

configfile (hd0,gpt2)/boot/grub/grub.cfg

Then update-grub
I'm not sure about the hd0 or hd1 but you can use the ls command on rescue.
E.g. Ubuntu Grub Rescue Commands - Techolac

[raj]

@filo
when I enter ls command in grub rescue it shows only partitions from one disk (I have one SSD and one HDD):

(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd0,gpt4)

and when I try to ls into any of the mentioned disk partitions it shows the output like that:

filesystem is unknown