The transition from BIOS to UEFI has brought another technological change: the use of GPT (GUID Partition Table) as default partition table instead of MBR (Master Boot Record). Conforming to the most fundamental aspects, the second transition has been forced because GPT is part of the UEFI standard, although MBR has not been able to satisfy all storage needs for years.
The use of MBR or GPT depends on the time the computer was purchased, but especially the firmware. BIOS computers are inclined (in almost 100% of cases) to use the MBR partition table, while all UEFI computers use GPT.
MBR and GPT at partition level
The format of the table determines the maximum number of partitions that can be had. Here you have to be especially careful with Windows, which imposes quite a few limitations on where and in what way it has to be installed to boot properly. Hence, its installation is recommended first if you want to do a dual boot with Linux, making the Microsoft system always occupy the first two partitions of the first disk. For its part, Linux offers much more flexibility here, no matter the order in which the partitions are created and mounted.
On the differences between MBR and GPT, in the end users face the most important thing is the maximum number of partitions supported by each one. MBR only supports up to 4 primary partitions, although to skip this limitation you can create an extended partition With logical partitions. Stated more practical, the user can create 3 primary partitions plus an extended one with logical partitions inside. Obviously, you can also create two primary partitions for Windows and make the third one extended to deal there with logical partitions, which can be those of Linux.
GPT is much more powerful in this regard by allowing to create up to 128 primary partitions on a single disk (hard or SSD), which is more than enough for any type of current and future use.
But not only the number of partitions and their format influences the use of the partition table, but also the operating system that can be used. For example, macOS and Windows for x86 require an EFI firmware to boot from GPT, a limitation that does not affect Linux, although for the latter it is necessary to perform a simple step in the partitioning process to work properly.
MBR and GPT at capacity level
Although SSDs have pushed back the maximum capacity of computers, especially laptops, it is currently not so rare to see hard drives of 2TB or more capacity. Although hard drives can become pretty annoying bottlenecks In today's computers, today they are still, at least for end users, a better option to have a lot of capacity, especially since they are cheaper.
In capacity is another advantage of GPT over MBR, since the second only has 32 bits available to represent the logical sectors. This means that In the beginning it is only capable of supporting disks up to 2TB of storage while GPT has 64-bit support here to cover disks up to 9.4 zettabytes (about 9.4 billion gigabytes), too much for any current context.
MBR and GPT before errors
MBR stores all partition and boot data in one place. In case that this place ends up corrupt, the situation would lead to serious problems and great dislikes, something that the user will detect when he sees that the operating system does not start. Although MBR recovery is possible, it is not certain that it will be successful.
GPT stores multiple copies of the boot in several partitions, at the beginning and end of the table headers, so if one partition gets corrupted, it can rely on another to recover. In addition, it has an error detection code that evaluates the partition table at boot. In case of detecting errors, GPT will try to repair itself.
MBR and GPT compatibility
The use of one or the other depends on the type of firmware used by the board and the operating system. For example, Windows only supports GPT from UEFI, while Linux can use GPT in BIOS in exchange for fulfilling a condition.
These are the versions of Windows and the partition table required for each situation:
- Windows Vista, 7, 8, 8.1 and 10 64-bit require a UEFI motherboard to boot from a disk with GPT partition table.
- Windows 8, 8.1 and 10 32-bit require a UEFI motherboard to boot from a disk with GPT partition table.
- Windows 7 32-bit cannot boot if it is installed on a GPT partition table.
- However, all mentioned Windows systems can read and write on a GPT disk used to store data.
In regards to Linux, and taking Ubuntu As a reference, if you want to use GPT over BIOS, you must first create a partition of 1 or 2 megabytes of type biosgrub, which adopts the FAT32 format. The only thing that the user has to do is to create the partition first, which is of the primary type, that occupies 1 or 2 megabytes and select “Boot BIOS Reserved Area” as the type.
In UEFI you also have to create a first partition of about 100 megabytes, although selecting “EFI System Partition” as the partition type in the Ubuntu installation. In other distributions, such as Fedora, it may be necessary to mount it in “/ boot / efi”.
How to view the partition table used on disk
Checking the partition table on a disk is very simple on both Windows and Linux. In the Microsoft system you have to open the “Disk Manager”, right click on the disk you want to check in the bottom frame (“Disk 0” in the example we are exposing), click on Properties and go to the “Volumes” tab in the window that appears.
For its part, in Linux you can use the well-known graphic partitioner GParted. After selecting the disk you want to check (in our case, / dev / nme0n1), you have to go to the “View” menu and click on “Device Information”.
How to convert an MBR partition table to GPT without losing data
This is not a situation that occurs frequently, although there may be people who have replaced a BIOS board with another UEFI without changing the case or the disks mounted on it. Here you can resort to MBR2GPT on Windows already ‘Gdisk’ on Linux to carry out the conversion process without losing data. In spite of everything, before initiating this type of action we strongly recommend the previous realization of backups, because any error in the process can result in the loss of the data.