Detecting efi files and booting them from grub

We can use a UEFI grub to detect any efi files and boot up the OS.
From any grub prompt (and a manjaro livecd media will do fine),

To Boot Manjaro OS

insmod fat
search -f /efi/manjaro/grubx64.efi

Output will show the $esp partition where this manjaro efi file resides.
To boot that Manjaro OS,

insmod fat
insmod chain
search -f /efi/manjaro/grubx64.efi --set=root
chainloader /efi/manjaro/grubx64.efi
boot

To Boot Other Linux OS
We can similarly detect (and boot) other OS’s efi files, for example

grub> search -f /efi/ubuntu/grubx64.efi

ps: The configfile method is preferable in booting up a non-bootable OS than this booting up of efi files as usually, a non-bootable OS may have a missing or non-functional grubx64.efi.

Also note this will be exactly similar to the entry as shown in this link as follows.

menuentry "Multiboot --uefi" {
               search --set=root --label xxxx
               chainloader /boot/grub/x86_64-efi/core.efi
     }

As grubx64.efi is just a copy of core.efi

To boot Device Boot OS

grub> search -f /efi/boot/bootx64.efi

To Boot to rEFInd and systemd-boot

grub> search -f /efi/systemd/systemd-bootx64.efi
grub> search -f /efi/refind/refind_x64.efi

To boot Windows

grub> search -f /efi/Microsoft/Boot/bootmgfw.efi

To Detect and List All Bootable efi-files

This is the menuentry to be put in grub.cfg or custom.cfg

menuentry "Detect EFI bootloaders "  {
    insmod part_gpt
    insmod fat
    insmod chain

             for efi in (*,gpt*)/efi/*/*.efi (*,gpt*)/efi/*/*/*.efi (*,gpt*)/*.efi (*,gpt*)/*/*.efi ; do
                regexp --set=1:efi_device '^\((.*)\)/' "${efi}"
                if [ -e "${efi}" ]; then
                    efi_found=true

                    menuentry --class=efi "${efi}" "${efi_device}" {
                        root="${2}"
                        chainloader "${1}"
                    }
                fi
            done

            if [ "${efi_found}" != true ]; then
                menuentry --hotkey=q --class=find.none "No EFI files detected." {menu_reload}
            else
                menuentry --hotkey=q --class=cancel "Cancel" {menu_reload}
            fi   
    }

This menuentry is directly copied from Manjaro install menu.

10 Likes

@gohlip, I recently got a laptop which is my first UEFI machine.

It has Manjaro Unstable and 2 other distros on it, but I set Manjaro’s grub first in boot order due to the intel ucode issue.

However, yesterday Manjaro hung in the midst of installing a few new packages (luckily unimportant). I decided to hard reboot the laptop. Grub menu appeared but booting into Manjaro failed (nothing appeared at all) so I thought the install was borked.

I changed grub boot order to boot from another distro, and copied a custom.cfg file with custom entries from my legacy BIOS/MBR PC to the /boot/grub folder of that other distro. The entry directly booting Manjaro’s 4.14 kernel and initrd img worked fine, meaning my Manjaro install didn’t die after all, but the other menu entry that attempts to chainload into Manjaro’s grub didn’t work when I pointed it to the root partition.

That’s understandable since Manjaro’s grub is in the ESP.

I’m trying to understand from your post how to adjust that chainloader custom entry so that it works. ESP is /dev/sda1, Manjaro root partition is sda2

Would this work – ie, the line with the search command – within a menu entry in custom.cfg file?

menuentry ‘Manjaro .efi’ {
insmod fat
insmod chain
search -f /efi/manjaro/grubx64.efi --set=root
chainloader /efi/manjaro/grubx64.efi
}

Or should I just do it this way?

menuentry ‘Manjaro .efi’ {
insmod fat
insmod chain
set root=’(hd0,gpt1)'
chainloader /efi/manjaro/grubx64.efi
}

Hi, @wongs,
The first entry is preferable as with multiple disks, the bios sometimes ‘allocate’ a different mapping (sda/sdb) to the disks. [If you have only one disk, that shouldn’t matter].

However, whenever there’s any problem (as you found out), it is better to use configfile because the
grubx64.efi file may be in error or removed. Chainloading core.efi (in OS main partition) is better than chainloading grubx64.efi but still the best is using configfile.

A configfile entry can be as follows.

menuentry "Configfile " --class recovery {
    insmod part_gpt
    part part_msdos
    insmod ext2
    search.file  /etc/manjaro-release root
    configfile /boot/grub/grub.cfg
}

I use /etc/manjaro-release here (instead of intel-ucode.img) because I recall you have Arch.
Oh…, I remember that you have quite a number of OS’s and if you have multiple Manjaro’s,
then the search.file line above may select any one of the manjaro OS’s. In that case, you may then use set root=’(hd0,gpt1)’ but careful about the device mapping (it may be (hd1,gpt1)). Just" grub> ls (hdx,y) " to confirm.
And if you have labels for partitions then use Label. Best of all.

search --set=root --label xxxx

Hope this explains and that I answered what you want to know.
Cheers.

[edit] -
“part part_msdos” above should be “insmod part_msdos”. Sorry.

2 Likes

Tested a few variations in the custom.cfg file. I thought I’d set them out here in case anyone is interested. All work but the last one also issued an error message .

menuentry “ManjaroSX .efi search” {
insmod fat
insmod chain
search -f /efi/manjaro/grubx64.efi --set=root
chainloader /efi/manjaro/grubx64.efi
}

menuentry “Configfile searchlabel” --class recovery {
insmod part_gpt
part part_msdos
insmod ext2
search --set=root --label manjarosx
configfile /boot/grub/grub.cfg
}

menuentry “ManjaroSX .efi gpt1” {
insmod fat
insmod chain
set root=’(hd0,gpt1)'
chainloader /efi/manjaro/grubx64.efi
}

menuentry “Configfile searchfile” --class recovery {
insmod part_gpt
part part_msdos
insmod ext2
search.file /etc/manjaro-release root
configfile /boot/grub/grub.cfg
}

Works after first throwing up an error message, something about not finding “part…” and asking me to press any key. I did that and the manjaro grub menu turned up anyway and I was able to log in.

Removed the line with part_msdos, since there is no MBR/msdos partition table on this SSD, and the error message went away.

menuentry “ManjaroSX searchlabel chain” --class recovery {
insmod part_gpt
part part_msdos <== deleted this line later
insmod ext2
search --set=root --label manjarosx
chainloader /boot/grub/x86_64-efi/core.efi
}

Hee hee hee, My bad, it is a typo on my part.

Should be

insmod part_msdos

But yes, you can delete it if the partition is gpt.
The reason it is included in most ‘distro default’ grub.cfg (including Manjaro) is that bios-legacy bios is fickle and cannot detect gpt partitions well. {uefi bios usually can detect msdos partitions ok}. But both are included just in case. So as in my case when I wrote it out. Just wrongly, sorry.

Good you got it working (and have a label for manjaro partition).
Cheers.

I did wonder about that. Thanks.

As for having labels, when one multiboots many distros, it’s always safer to label every single partition. :grinning:

I must say that the ESP thing does have its advantages. It’s quite convenient to be able to chuck every distro’s grub in there, and be able to reorder the boot priority of all the grub menus from BIOS settings instead of having to boot into a selected distro and issuing a “grub-install” command from the terminal to seize control of main boot.

1 Like

Added a menuentry in first post to detect all efi files and put bootable entries into the grub menu.
Since I added this, I also added other entries to boot other OS’s, refind and systemd-boot.

rEFInd users often mention that refind can detect other OS and boot them and this is the main advantage of using refind (besides the eye-candy of its menu) which basically means they are using refind to boot up another bootloader (grub mostly) for booting.

But so can grub, as shown in the first post.
ps - personally, I don’t like the idea of calling up another bootloader from another bootloader

2 Likes