I think you should give a look at this thread (I just noticed it, sorry).
It’s very similar to your problem, and a user seems to have found a workaround.
2 Likes
Provided that the solution should probably come from the thread above, if you like to have some fun like I do, you could try to update the following file in your live USB:
sudo micro /usr/lib/calamares/modules/bootloader/main.py
and change every occurrence of force to removable (there should be 4).
Save, exit and try installing…
By-the-way, if I remember correctly, --removable just does not write in the NVRAM, so could do the trick anyway, just in a different way.
2 Likes
Hello, please elaborate on how you do that exactly, I have the Debian written into the usb already
I was honestly hoping for some clarity in that thread.
My interpretation is that the Debian ISO was being used to manually create an entry in the UEFI boot menu.
In the Debian USB, after mounting sda1 onto /boot/efi, I would:
sudo efibootmgr -c -d /dev/sda -p 1 -L "Garuda" -l /EFI/Garuda/grubx64.efi
Then, the other thread says:
it also booted the grub boot loader
So, you could try booting normally to check that at least the Garuda Grub starts, but not configured, as reported.
So, going back to the Garuda USB, and after chrooting, I think only:
update-grub
should be missing.
Well I can provide more details.
What I did was I did download debian-live-11.5.0-amd64-kde+nonfree.iso from here: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current-live/amd64/iso-hybrid/
I Put the ISO image on an USB stick and I did boot my Macbook from this stick.
However WLAN does not work with this image so you need a wired LAN connection on your Macbook.
Then you download efibootmgr by:
sudo apt update
sudo apt install efibootmgr
Then you can modify your EFI NVRAM entry by:
sudo efibootmgr -c -L “Garuda” -l \\EFI\\Garuda\\grubx64.efi
Take care. you need two backslashes for the path not forward slashes and it need to be two of them as shown above.
However, this is the example when you have a standalone Garuda installation on your Macbook otherwise you may have to provide. a different disk and or at least a different partition by the -p option.
With this the Macbook did boot into grub after a restart, however you will end up on the grub command line. So there are of course several possibilities how to fix this. What I did was i entered the garuda instalation USB stick and on “Garuda Welome” I choose “Garuda Boot Repair” and there I did choose the second option “Repair GRUB configuration file”.
And another reboot now from disk and you should be done.
5 Likes
Perhaps I should add, that the command:
sudo efibootmgr -c -L “Garuda” -l \EFI\Garuda\grubx64.efi
should of course also work under Garuda. The problem is that this is not the case, which is why the installation fails.
My workaround then was, to use another distribution to modify the EFI NVRAM.
so I was able to modify the NVRAM, when i check using
sudo efibootmgr -c -L "Garuda" -l \EFI\Garuda\grubx64.efi
I can see the bootloader
Boot0001* Garuda HD(1,GPT,c9b2783e-f7df-0e47-a84b-a58bdee8cd7d,0x1000,0x96000)/File(\EFI\Garuda\grubx64.efi)
Then when I reboot I still fall back to the Grub terminal, I booted with the Garuda live usb multiple times repairing the Grub bootloader, updating it, and even reinstalling it on fish terminal but it still boots up to grub.
First thing to check is, if there are other entries in your NVRAM and if the one you want to use is the right one. Just to avoid that there are other boot loaders on your disk and you are repairing the right one but you boot into a different one.
Do you have only one installation on your disk? Or do you have multiple operating systems on your disk?
So with:
sudo blkid
you can see the harddisks, the partitions and the UUIDs of your computer.
with
efibootmgr -v
You can see all your NVRAM entries together with the UUIDs. So check whether the UUID in the NVRAM (BOOT0001 in your case) is identical with the partition that is meant to be your /boot/efi partition (per default in a stadard installation this should be on /dev/sda1). And check whether the BOOT0001 is the first in the BootOrder.
This is to make sure that the GRUB boot loader which is loaded when you start your computer is the right one and probably the only one.
If all of this is correct then there might be a problem in the GRUB configuration. However, for me it did work with the “Repair GRUB configuration file” of the “Garuda Boot Repair” tool. So this is why it may make sense to do the checks above.
2 Likes
additional with:
sudo fdisk -l
you can list all your partitions and there partition type. If there is only one operating system on your computer then there should be exactly one and only one “EFI System” partition (usually this is /dev/sda1 as said before) and this should be the one whose UUID is listed in the NVRAM.
1 Like
In addition to the information above, remembering this, I’d give a look also at your /etc/fstab (when inside your installed system via chroot).
2 Likes
Thank you very much everyone. It has worked
I followed all your instructions and it worked like a charm, grub booted up perfectly, I really appreciate your time and effort.
3 Likes
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.