[arch-general] The differences among bootx64.efi, loader.efi and grubx64.efi.
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 I just cannot figure out the differences among them. Could you please give me some hints on this? Thanks in advance. -- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
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. -- Cheers, Ralph.
Hi again Hongyi,
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.
Sorry, one more. Lots of detail in this one; I couldn't find it just now. https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-wo... -- Cheers, Ralph.
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
-- Cheers, Ralph.
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
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
On Fri, Nov 15, 2019 at 8:31 AM Hongyi Zhao via arch-general < arch-general@archlinux.org> wrote:
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.
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. The UEFI boot paths look weird because FAT32 uses Windows-style backslash path separators. Max
Maxwell Anselm via arch-general <arch-general@archlinux.org> 于2019年11月19日周二 下午10:24写道：
On Fri, Nov 15, 2019 at 8:31 AM Hongyi Zhao via arch-general < arch-general@archlinux.org> wrote:
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.
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@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
Hi Hongyi,
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
Use the source that's processing the -l option; it's perhaps converting / into \ for the user's convenience. -- Cheers, Ralph.
participants (3)
-
Hongyi Zhao
-
Maxwell Anselm
-
Ralph Corderoy