Why don't we go back to basics...
Ive been trying different methods and this is happening now...
when I mount the path below it works
sudo mount /dev/sda1 /boot/efi/
and also when I run
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Garuda --removable
I get
Installing for x86_64-efi platform.
Installation finished. No error reported.
But then when I unmount and restart the laptop it does not show any available OS on the boot menu so it doesn't boot up. What am I missing?
You should try
sudo update-grub
I have rebooted and it opened the grub menu..
I followed the steps to select the boot drive. Now it is telling me :
You need to load the kernel first
There was no Garuda option to be selected?
You could try chrooting again and give a
pacman -S linux-zen linux-zen-headers
But there's probably still something wrong...
I saw on some other forum they suggested..
linux /boot/vmlinuz-4.2.0-16-generic root=/dev/sda1 ro
Is there a version of that, that can work for me.
I think that stuff is needed when you drop into an emergency shell, not in this case.
I see now and agree with the comment of @Bro or even start from scratch: download a new ISO, verify checksum, burn it one the USB possibly with Ventoy, fast boot and secure boot disabled in the BIOS, boot ISO and install.
If I can give you also a general advice, I suggest you always make clear in your posts what you have done, provide the relevant input and output whenever possible (eg when in terminal or chroot), otherwise it becomes difficult to follow and understand the actions and what's going on.
Okay so let me recap. I have 3 iso images, dragonized, gaming edition and cinnamon. I've been using usb image writer from my linux mint v20 to create a bootable usb.
so all the versions when show the same above error, with I realize that its caused by the default installation command
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Garuda --force
so after the installation fails I mount run the fish command line
sudo mount /dev/sda1 /boot/efi
after successful mounting I run this command
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Garuda --removable
which gives me the results
Installing for x86_64-efi platform.
Installation finished. No error reported.
Then I reboot and it boots up to GNU Grub 2:2, when I type in the boot command it returns an error: you need to select kernel first.
I tried following the steps for manually fixing the grub which involved
ls
set root=
insmod normal
normal
But then when it comes to selecting the kernel I get stuck.
I really want to install this linux that is why i've been trying relentlessly. even
sudo update-grub
returns
/usr/bin/grub-probe: error: failed to get canonical path of `overlay'.
I know its probably stupid but I was wondering if there is a way we could just modify the iso so that it comes with the --removable command instead of the --force
I appreciate your time. Thank you.
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.
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.
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: Index of /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.
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.
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.
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).
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.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.