6

3rd time re partitioning my 1TB SSD so hoping to get it right. Learning but still many questions

Because my system has UEFI firmware and already have a SSD dedicated to Windows my understanding is that I MUST have a UEFI boot partition on my 2nd SSD dedicated to Linux. And if using GPT partitioning in addition it needs to have the 'boot' flag set.

My first point of confusion is conflicting device I am reading about GPT vs MBR-msdos partitioning.

At ubuntuforums here under Two Drive Installs>Partitioning it states

With UEFI, gpt partitioning is (almost) required. If multiple drives all bootable drives need to be gpt and best if data drives are also gpt in case later you want to make it bootable. With gpt there is no primary, extended, logical partitions as in MBR(msdos) nor the 4 primary partition limit. You can only have one efi partition per drive and with gparted you use the boot flag to assign it as the efi partition. No other partitions can have boot flag. Only if booting in BIOS mode with Ubuntu on gpt partitioned drive, you need a bios_grub partition. Windows will only boot in UEFI mode so you cannot install Windows to gpt drive unless booting with UEFI.

but this partition guide over at ubuntu-mate.community seems to indicate using MBR partitioning ubuntu-mate.community see Part 4: Create a UEFI boot partition. + swap + root + home partitions.

Which is right? Why is GPT partitioning recommended for UEFI?

1
  • 1
    One reason is that MBR fails to work with bootable disks above 2Tb, Another reason is that an MBR does not have a backup whereas there are 2 copies of a GPT on a disk.
    – fpmurphy
    Commented Jan 5, 2017 at 4:01

3 Answers 3

2

Because my system has UEFI firmware and already have a SSD dedicated to Windows my understanding is that I MUST have a UEFI boot partition on my 2nd SSD dedicated to Linux. And if using GPT partitioning in addition it needs to have the 'boot' flag set.

The 'boot' flag is actually the result of gparted trying to present GPT using an interface originally designed exclusively for MBR. When gparted shows a 'boot' flag on a partition on a GPT-partitioned disk, it actually means that the type GUID of that partition will be set to the standard value that matches "EFI System Partition", or ESP.

The guide at ubuntu-mate.community has multiple parts: parts 1-3 are about MBR partitioning, and only part 4 covers GPT. As of this writing the GPT guide only covers the case of having Linux as the only operating system on the disk. It's almost as if the writer of the guide was less familiar with GPT than with MBR.

That ESP is what UEFI firmware will look for when trying to identify if a hard disk is bootable or not.

It is possible to share an ESP partition between Windows and Linux, or between any number of operating systems. In fact, the standard layout of the ESP filesystem was designed to facilitate precisely that.

It is also possible to have multiple disks with each having an ESP partition, as long as your UEFI firmware can support the disk controllers the disks are plugged into. Having multiple ESP partitions on the same disk does not seem to be recommended anywhere, and I assume it might confuse some firmware versions.

When you have a UEFI-based system, the most well-tested configuration by the manufacturer will almost certainly be the one with GPT partitioning. The second well-tested configuration will be the one with the legacy BIOS compatibility (sometimes referred to as Compatibility Support Module = CSM) enabled and MBR partitioning.

The hybrid configurations (native UEFI boot + MBR partitioning, or legacy-BIOS-compatible boot + GPT partitioning) are likely to receive only limited testing, as they are expected to be used in rare cases only.

Of those two, the legacy BIOS + GPT might actually be the one that receives more testing, as it will be needed to support operating systems with legacy boot on disks larger than 2 TB. Since GPT occupies the location on the disk immediately after MBR but before the beginning of the first partition, the GRUB bootloader can no longer be embedded in there (nor can be any other bootloader for that matter), and so the bios_grub partition was developed as a workaround.

Using MBR partitioning with native UEFI boot method won't give you any advantages whatsoever: it will just restrict you to a maximum capacity of 2 TB on your system disk (unless you use disks with 4KiB sectors, which would be quite another can of worms...).

And Microsoft, still the biggest gorilla of the x86 architecture, has decreed that if your system uses a native UEFI boot method, only GPT-partitioned system disk will be officially supported; if you use a hybrid solution, you'll be on your own.

0

GPT is part of the UEFI specification, they go hand in hand. While UEFI is supposed to also support MBR partitioned disks, that is for legacy reasons only. The UEFI + MBR combination is a deviation from what you are supposed to be using, and may lead to surprises with some (future) operating systems or tools.

0

I start saying:

if you have an UEFI system, you have no reason to use MBR


Full story:
GPT is part of the UEFI specification [1].
In an UEFI system, you have the right, the ability to use MBR just due to backward-compatibility: UEFI specification considers/expects such case [1], so MBR is accepted.
Thus, coming back to your question, I can further add that GPT has no limits over MBR, such as number of partitions and their size;
so there is no reason to prefer MBR over GPT.


[1] https://wiki.archlinux.org/index.php/Partitioning#GUID_Partition_Table

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .