Multiboot USB
History
BIOS & MBR
Legacy BIOS boots use the MBR format. Here you are broadly limited to four primary partitions and 2TB disks. There is little information kept about each partition and a single copy of the partition table.
This is because the MBR is just the first 512 byte block on the disk and must include several hundred bytes of boot loader code.
UEFI & GPT
UEFI allows you to provide a suite of boot and runtime services and through the GPT can address much larger disks (up into the Zettabyte range). GPTs can use up to 128 partitions, can store several attributes against each partition and also will keep a duplicate copy of everything at the end of the disk.
One particular advantage of GPT is partly in the name in that GUID's are used extensively. As a side-effect, GPT-aware boot loaders can search for boot partitions by UUID which should divorce us from knowing which device (as in /dev/sdc) a boot partition is on.
As some sort of backwards compatibility (or at least, some sort of "do no harm" principle) GPT will not overwrite the MBR. In fact you should see messages regarding a protective MBR when running gdisk later.
ESP
The EFI System Partition (ESP) is a specially tagged partition that must be a FAT32 (or FAT16 on removable media) with an EFI folder in the top level.
Much documentation suggests making this at least 100MiB although 200MiB and 500MiB are very common and a suggestion that 1GiB should be the new default.
A brand new Windows 10 install (Feb 2017) creates a 100MB vfat partition.
Note
200MiB is too small for FAT32!
EFI Boot
Part of the construction of the EFI information seems to involve knowledge of the boot device (despite UUIDs) and so sometimes you will see reference to /EFI/BOOT/BOOTX86.EFI (where X86 references the machine type short name).
We'll be aiming to use /EFI/{name}/grubx86.efi where {name} is some useful identifier to use that makes it easy to spot in the BIOS screens.
Document Actions