Skip to content. | Skip to navigation


You are here: Home / Support / Guides / Tools / Multiboot USB / grub2-install

Personal tools

Multiboot USB

Booting from multiple ISOs on one USB


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).


May 2021 update

grub2-install no longer works as directed on Fedora 34 and CentOS Stream 8. See here for details.

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/

  • --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 will create a GRUB2 boot which refers to sda. If you put it in a machine where the BIOS decides your USB stick is sdb then you cannot boot off this stick.

This may be an issue in which case you can also pass the --removable flag which will ignore your --bootloader-id flag and create .../BOOT/BOOTX86.efi (or a similar name for 32bit). This appears to be a well-known fallback name that UEFI boot systems will look for.

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.


The full results of this aren't immediately obvious. In fact have a rummage:

# cd /tmp/usb-sda/
# find .

We now have an .efi file on the ESP partition (.../EFI and below); some modules; locale data; font information etc. in /boot/grub2.

The list of modules might be of interest later in grub.cfg and even in the GRUB shell but at least includes xfs.mod. And 260 others...


You may see reference to the --removable flag which will work but has a subtle effect:

  1. it suppresses references to our bootloader-id, multiboot
  2. the image created is .../BOOT/BOOTX86.EFI

It appears this is a well-known fallback name for situations where such a thing is needed.

Document Actions