grub2-install is where a lot of the magic happens without you realising. Also, many of the arguments default to / (or subdirectories thereof) which isn't what you want as our putative / is currently mounted as /tmp/usb-sda (or wherever you chose).

grub2-install takes a heap of arguments many of which are important:

• --boot-directory=/tmp/usb-sda/boot

  boot-directory defaults to /boot

• --efi-directory=/tmp/usb-sda/boot/efi

  efi-directory defaults to /boot/efi

• --target=x86_64-efi

  Without this you'll get a 32bit build and/or a warning about a missing /usr/lib/grub/x86_64-efi/modinfo.sh

• --bootloader-id=multiboot

  bootloader-id is the clearly identifiable name we want to see in the BIOS screens, it defaults to grub. Here we are choosing the string multiboot

• -v

  verbose -- without this we won't see the arguments being supplied to efibootmgr. Unfortunately, most of the verbose output is the symbol-by-symbol transcript of producing a non-relocatable binary (there is no link-loader for the boot process!). Luckily, the efibootmgr output is at the end

• /dev/sda

  The device efiboomgr is going to update.

  It defaults to the current boot device?

This is the output of running grub2-install with the above arguments with notes interspersed:

...
grub2-install: info: writing 0x1dc00 bytes.
grub2-install: info: copying `/tmp/usb-sda/boot/grub2/x86_64-efi/core.efi' -> `/tmp/usb-sda/boot/efi/EFI/multiboot/grubx64.efi'.

• The generated image (core.efi) is copied to /tmp/usb-sda/boot/efi/EFI/multiboot/grubx64.efi. This includes the word multiboot in the pathname.

  Later, when the UEFI boot process kicks in, it will look on the ESP (the FAT partition) for a subdirectory of /EFI called {name} (multiboot in our case) and expect to find a suitable .efi file.

grub2-install: info: Registering with EFI: distributor = `multiboot', path = `\EFI\multiboot\grubx64.efi', ESP at hostdisk//dev/sda,gpt1.

• The same file (using a relative FAT pathname, \EFI\multiboot\grubx64.efi is registered in the ESP as hostdisk//dev/sda,gpt1

  This is unfortunate as whilst the gpt1 part refers to GPT partition one, the fact that this USB device exists in this machine as /dev/sda is also registered. Poor form!

grub2-install: info: executing efibootmgr --version </dev/null >/dev/null.
grub2-install: info: executing modprobe -q efivars.
grub2-install: info: executing efibootmgr -b 0003 -B.
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0004
Boot0000* CentOS
Boot0002* Hard Drive
Boot0004* Removable Drive

• efibootmgr then prints out the current EFI boot setup. We can decode this as:
  1. This session is the result of booting off 0000.
  2. The possible bootable entities were 0000, 0002 and 0004 -- ie. we booted off the first possible one
  3. And some information about those bootable things including their bootloader-id

grub2-install: info: executing efibootmgr -c -d /dev/sda -p 1 -w -L multiboot -l \EFI\multiboot\grubx64.efi.
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0001,0000,0002,0004
Boot0000* CentOS
Boot0002* Hard Drive
Boot0004* Removable Drive
Boot0001* multiboot

• efibootmgr then adds another bootable entity, 0001, makes it the first bootable entity, and dumps out that its bootloader-id is multiboot.

Installation finished. No error reported.

# cd /tmp/usb-sda/
# find .
.
./boot
./boot/efi
./boot/efi/EFI
./boot/efi/EFI/multiboot
./boot/efi/EFI/multiboot/grubx64.efi
./boot/grub2
./boot/grub2/x86_64-efi
./boot/grub2/x86_64-efi/div_test.mod
./boot/grub2/x86_64-efi/acpi.mod
...
./boot/grub2/locale
...
./boot/grub2/fonts
./boot/grub2/fonts/unicode.pf2
./boot/grub2/grubenv