Maxwell Anselm via arch-general <arch-general@xxxxxxxxxxxxx> 于2019年11月19日周二 下午10:24写道： > > On Fri, Nov 15, 2019 at 8:31 AM Hongyi Zhao via arch-general < > arch-general@xxxxxxxxxxxxx> wrote: > > > Hongyi Zhao <hongyi.zhao@xxxxxxxxx> 于2019年11月15日周五 下午9:13写道： > > > > > > Ralph Corderoy <ralph@xxxxxxxxxxxxxxx> 于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@xxxxxxxxx> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
