''EFI boot partition'' and ''biosgrub'' partition

Solution 1:

There are four conditions (BIOS vs. EFI and MBR vs. GPT), but two of them have identical needs (and one of those is exceedingly rare):

• On a traditional BIOS-based computer with a traditional MBR partition table, GRUB's executable code gets spread around like spaghetti thrown by a baby. Some of it's in the boot-code section of the MBR, some of it's in post-MBR sectors that are officially unallocated, and some of it's in the Linux /boot partition. This is a real mess, and it works only because developers have had literally decades to create clever hacks and work out (almost) all the kinks.
• On a traditional BIOS-based computer with a new GUID Partition Table (GPT), the GRUB code is similar to that in the preceding case; however, the sectors immediately following the MBR are not unallocated; they're used by the GPT itself. GPT offers no analogous place for GRUB to hijack, so GRUB's developers settled on the BIOS Boot Partition (which GParted and parted identify by a bios_grub flag) to hold the code that would go in the post-MBR sectors on an MBR disk. This is actually safer and cleaner than the MBR approach, since it serves to protect the GRUB code from other programs that might try to use that unallocated space.
• On a computer with a newer EFI rather than a BIOS, boot loaders are not stored in the MBR, in officially-unallocated post-MBR sectors, or in BIOS Boot Partitions; instead, boot loaders reside as ordinary files on a FAT partition known as the EFI System Partition (ESP). (Confusingly, Debian and Ubuntu installers refer to the ESP by the name "EFI boot partition," but this name is non-standard. GParted and parted identify the ESP as having its "boot flag" set, although that terminology means something completely different on MBR disks.) An ESP can exist on either a GPT disk or an MBR disk, but the former is much more common on EFI-based computers. The EFI approach is much safer and much more flexible than the BIOS approach, since it doesn't tuck raw code away in weird places; boot loaders reside in files, just like OS-level programs. This makes them easier to identify and manipulate. (OTOH, EFI also stores data on boot loaders in NVRAM, which creates a second point of failure in the boot process. EFI's newness also means it's not as well-tested, which accounts for a host of EFI-specific problems.)

GhostMotleyX, your comment to LiveWireBT's response opined that the "best" way to install is BIOS/MBR. This is subjective, of course, but I disagree with that assessment. The BIOS/MBR approach is the least safe and the most clumsy of the three approaches I've just outlined. The EFI approach is the safest and most flexible approach. I suspect you're getting hung up on the fact that separate partitions are required for the GRUB/GPT and EFI approaches, but that's not a big deal. Aside from when setting up the system or doing partition maintenance, those partitions will be pretty much invisible to you, and they give you a lot of flexibility. Unlike MBR, GPT is not limited to four primary partitions, so you needn't hoard your primary partitions like a leprechaun hoarding his gold.

Solution 2:

You need to create a biosgrub partition on a GPT partitioned disk when setting up legacy booting or an EFI boot partition (for both GPT or MBR partitioned disk) when setting up UEFI booting.

• GRUB requires a BIOS Boot Partition (2 MiB, no filesystem, EF02 type code in gdisk or bios_grub flag in GNU Parted) in BIOS systems to embed its core.img file due to lack of post-MBR embed gap in GPT disks. [...]

^{https://wiki.archlinux.org/index.php/GPT#Bootloader_Support}