First, be aware that there are two partition table types: the older Master Boot Record (MBR) system and the newer GUID Partition Table (GPT). Windows ties these partition table types to the boot method: MBR works only with the Basic Input/Output System (BIOS) and GPT works only with the newer Extensible Firmware Interface (EFI) or Unified EFI (UEFI). Linux is more flexible, but deviating from this mapping can cause problems, as noted later.
This is important because the "boot flags" that
parted, GParted, and other libparted-based tools present have different meanings depending on the partition table type. Specifically, the "boot flag" is properly named for MBR disks. It's used by some (but not all) BIOS-mode boot loaders to identify the partition that holds second-stage boot code. EFI boots in a completely different way, though, and for reasons that I don't pretend to know, but libparted developers chose to re-use the name "boot flag" on GPT disks to identify the EFI System Partition (ESP) -- that is, it's a partition type code on GPT. The concept is only very loosely similar to the MBR concept. As a practical matter, it's common to set the "boot flag" on a Linux partition on MBR disks, although this isn't required when using GRUB (because GRUB ignores the "boot flag"). On a GPT disk, though, you should never set the "boot flag" on a Linux partition; it should be set only on the ESP. Linux doesn't care about this, but the firmware might, and other partitioning tools or OSes might get confused if a Linux partition is set as the ESP. For clarity of discussion, the term "boot flag" is best reserved for MBR disks, because the term is not used on GPT disks outside of libparted-based tools -- the GPT fdisk family (
cgdisk) doesn't use it, and neither do tools outside of Linux. In fact, there is a "legacy BIOS boootable" attribute in GPT that's closer to the meaning of the MBR "boot flag," but it's set in libparted via the "legacy_boot flag." I'm sorry that this is so confusing. You can blame the libparted developers for hacking something together with inadequate thought.
Moving on, you've asked about two partitions:
- The ESP holds a FAT (officially FAT32, although FAT16 often works) filesystem and EFI boot loaders. It is, as I said, identified by a "boot flag" in libparted, or by a type code of EF00 in GPT fdisk. There's no officially-mandated size, but it's commonly between 100MiB and 1GiB. It's required to boot a computer in EFI mode.
- The BIOS Boot Partition holds GRUB boot code for booting from a GPT disk in BIOS mode. It's not required when booting in EFI mode. This partition is typically 1-2MiB in size, although it can sometimes be smaller. Making it larger will serve no real purpose. It does not hold a filesystem; GRUB just dumps code into this area "raw."
It's possible for a GPT disk to have both an ESP and a BIOS Boot Partition; however, you need at most one of them to boot. (In fact, you can boot using SYSLINUX, LILO, or GRUB Legacy in BIOS mode with neither of these partitions.) Having both will enable you to switch between BIOS-mode and EFI-mode boots, assuming you've got both types of boot loader installed.
As to your problem of your firmware saying that there's no bootable device, I recommend you read the following pages:
The "no bootable device" error typically means that one of three things is happening:
- The computer is configured to boot only in EFI mode, and it can find no EFI-mode boot loader -- say, because you installed Ubuntu in BIOS/CSM/legacy mode or because the ESP is mis-identified.
- The computer is configured to boot in BIOS/CSM/legacy mode, but there's no BIOS/CSM/legacy-mode boot loader available -- say, because you installed Ubuntu in EFI mode.
- The computer is configured to boot in BIOS/CSM/legacy mode, but the firmware expects to see a "boot flag" on an MBR partition. If you installed Ubuntu in BIOS/CSM/legacy mode but used GPT partitioning, no such flag will be present. This causes some EFIs to flake out. See my page on the topic for details.