Grub tries to boot to a wrong UUID

Hey Guys,

so recently i had a second version of garuda installed on a seperate NVME drive on my system.

I had the issue (some may remember) that it wouldn't find my primary os anymore and i had to manually config my grub.cfg

Now i wiped that second drive clean, and while in my main OS i did update-grub, verified that the grub.cfg is looking exactly how it should, and now my after the reboot my grub still tries too boot into the wrong UUID.

Now i already tried to repair from a live install but that doesn't work. The grub.cfg is looking exactly how i left it, and afaik it is absolutely correct. Everywhere it shows me the correct UUID of the drive but as soon as i boot, it still shows me that it couldn't find the UUID of my other drive...That other UUID is not present in my grub.cfg

I don't know what to do anymore...from a live garuda-usb drive i cannot run garuda-boot-repair as it says it cannot enter chroot correctly.

Can someone help me out here?

The grub.cfg file tells the bootloader which UUID to use but that is not the only place that matters.

Have you also updated /etc/fstab and the run sudo mkinitcpio -P to rebuild the initrams?

1 Like

@dalto i did sudo mkinitcpio -P linux but i didn't do anything with fstab before that...i reboot into a live install and see what i find there

So in the fstab there is nothing mentioned of that wrong UUID...but in the table i don't see a special entry for boot...should there be one?

This is what my fstab looks like via chroot...this c3ef0... UUID is the correct one. When going into grub it tries to find some ba53 ..

Have you tried adding nofail to Bahamut?

Better yet, temporarily comment out everything below tmpfs to see if one of those is causing your issue.

i did, commented out everything below tmpfs but to no avail.

I also added a /boot entry in the upper part. So i have a /boot between / and /home with the correct column of /@boot aswell....still asks for ba58e2bb...UUID.

I have no frigging clue where that still lingers. Inside chroot i also did a garuda-update and saw that btrfs-grub has a newer version. With that it did mkinitcpio aswell...

That is wrong unless you have a custom subvolume layout.

Can you share the exact error message you are getting along with the context around it?

1 Like

You mean the one in grub?


GRUB loading...
Welcome to GRUB!

error: no such device: ba58e2bb-b37a-4c64-9d6b-dd322d4ec043
error: unknown filesystem.
Entering rescue mode...
grub-rescue> _


Can you share the contents of /boot/grub/grub.cfg and lsblk -o name,type,fstype,size,mountpoint,uuid

yeah i can, but not today...i gotta go to bed. Wasted my entire evening on this.

Btw, when i do ls (hd0,msdos1)/ on grub-rescue, i get my linux drive, but there is no boot folder there...when i do chroot i have a boot folder...

I send you everything tomorrow. Thanks already!!

It sounds like you are booting (or trying to boot) to the wrong Grub–the one from the old system, on the wiped drive. Even though you wiped the drive, you might have an old EFI entry kicking around that points to nothing.

Check the boot options in your BIOS menu, or run efibootmgr to see what your system thinks are viable boot options and delete the bogus ones.

sudo efibootmgr -b 1234 -B

:point_up: Substitute “1234” with the boot entry you want to delete.

2 Likes

Please never post images from the terminal, only as formatted text.
This can be searched, as well as copied for further internet searches.

Apart from that it also unnecessarily inflates the server memory, backups and traffic. :slight_smile:

2 Likes

When i installed the other version, i let it install it's bootloader on my main drive though..

My BIOS doesn't show me any boot options by name, Only by drive :-/

Also my main system is installed as MBR/BIOS not EFI :-/ Screwed that one up back then

i couldn't get that terminal output as text...it was via chroot and it wouldn't let me copy :frowning:

From a live usb i only get "EFI variables are not supported on this system" when i try to run efibootmgr

So, i am back in my system...i reinstalled garuda kde dragonized on my second drive, told it to install the boot loader on my first drive.

I then copied the grub.cfg from my main drive, into that new bootloader.

Now i can get back into my system. BUT i cannot access my snapshots anymore, and i am sure that if i were to wipe the second install again, it would fail again.

...yeah maybe it helps that i am atleast able to boot into my main system again.

have you tried piping your output to clipboard? I often do that to post my inxi:

garuda-inxi | xsel -i -b

It let’s me directly paste the output to forum without having to worry about copying everything manually.

Use

garuda-inxi | tb

and post the link.

4 Likes

These wacky installation hijinks are why you run into issues booting in the first place.

I read through your previous post again (here), to which a solution was not marked but as you left the thread it sounded like you were going to set up a custom.cfg to get Grub to pick up the second drive. Did you do that? Because if so, you will have to take down the custom.cfg now that the boot entry it is pointing to is gone.

1 Like
  1. forgot to mark a solution on that post, did that now

  2. no i did not create a custom.cfg i had my main drive in the custom section of the regular grub.cfg

installation hijinks werent what i was aiming at..back then i just wanted to have a second bare metal installation to play around with wayland on nvidia, thought that installing the bootloader on my main drive would be the safest way, that if i were to delete that second install i could just continue...well now i have the hijinks and i would pretty much prefer not to reinstall my main system