[arch-general] The differences among bootx64.efi, loader.efi and grubx64.efi.

[Hongyi Zhao]

Maxwell Anselm via arch-general <arch-general at archlinux.org>
于2019年11月19日周二 下午10:24写道：
>
> On Fri, Nov 15, 2019 at 8:31 AM Hongyi Zhao via arch-general <
> arch-general at archlinux.org> wrote:
>
> > Hongyi Zhao <hongyi.zhao at gmail.com> 于2019年11月15日周五 下午9:13写道：
> > >
> > > Ralph Corderoy <ralph at inputplus.co.uk> 于2019年11月15日周五 下午8:57写道：
> > >
> > > >
> > > > Hi Hongyi,
> > > >
> > > > > I noticed that for many distro's install iso, there are some efi
> > files
> > > > > in the EFI/efi folder as follows:
> > > > >     bootx64.efi, loader.efi and grubx64.efi
> > > > >
> > > > > Say, for arch:
> > > > >     bootx64.efi, loader.efi
> > > > >
> > > > > for debian:
> > > > >     bootx64.efi  grubx64.efi
> > > >
> > > > bootx64.efi is the default, others may exist as you can see.
> > > > NVRAM defines a list to iterate over of *.efi to attempt.
> > > > https://wiki.mageia.org/en/About_EFI_UEFI#The_ESP has some detail.
> > > > The start of https://jdebp.eu/FGA/efi-boot-process.html may also be
> > useful.
> > >
> > > But, I've tried use the grub2's chainloader method to invoke these efi
> > > loaders, and I found that for most of the time, if both of the
> > > bootx64.efi and grubx64.efi exists, the latter will have the most
> > > chance to succeed, but the former often failed to boot.
> > >
> > > Regards
> >
> > The most strange thing I noticed that is the efibootmgr's arg format as
> > follows:
> >
> > -l | --loader name     (defaults to "\EFI\/boot/EFI\grub.efi")
> >
> > Why it must be used like this strange form.
> >
> > And in the website you given here, it also gives the example like the
> > flowing:
> >
> > sudo efibootmgr -c -d /dev/sdc -p 1 -w -L 'grub-mkstandalone-x86_64
> > usb' -l \\EFI\\grub-mkstandalone\\grub-mkstandalone-x86_64.efi
> >
> > And this is the one I tried on my Debian/Manjaro/Ubuntu box, and it
> > seems does the trick.  But I still cannot figure out why they design
> > the path format like this.
> >
> > Regards
> >
> > >
> > > >
> > > > --
> > > > Cheers, Ralph.
> >
>
> With UEFI the ESP is just a normal FAT32 partition containing executables
> (with .efi extension). Those executables might be kernels, other boot
> loaders, utilities, whatever. A boot entry created with efibootmgr simply
> specifies how to run one of those executables on boot.
>
> AFAIK, the only "standard" path is bootx64.efi. That is what the UEFI
> standard specifies should be run if no boot entries exist. It is generally
> unnecessary unless your motherboard's UEFI implementation sucks or you're
> making something like a UEFI-bootable flash drive, for example.

I also noticed that when I install the grub-efi on my usb stick.  In
detail, even I don't create the boot menu with efibootmgr, there still
will be one atuo generated.  But the auto generated menu may be wrong
or pointing to wrong bootloaders when I have multiple loaders
available.

OTOH, the efibootmgr tool will let me set the correct path of the efi
file correponding to its menu.

The more often case is: we may have so many messy or remain efi boot
menu entries which we want to cleaned up,  in this case, the
efibootmgr will also do the trick.

>
> The UEFI boot paths look weird because FAT32 uses Windows-style backslash
> path separators.

But I tried both of the following on *nix based distros, and it seems
both will be correct:

-l \\EFI\\boot\bootx64.efi

or

-l /EFI/boot/bootx64.efi

Regards
>
> Max



-- 
Hongsheng Zhao <hongyi.zhao at gmail.com>
Institute of Semiconductors, Chinese Academy of Sciences
GnuPG DSA: 0xD108493