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.
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...
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
Substitute “1234” with the boot entry you want to delete.
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.
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.
forgot to mark a solution on that post, did that now
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
Substitute “1234” with the boot entry you want to delete.
