Hongyi Zhao <hongyi.zhao@gmail.com> 于2019年11月15日周五 下午9:13写道：
Ralph Corderoy <ralph@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.
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493