Talk:Understanding GPT and UEFI

MBR

A master boot record (MBR) is a special type of boot sector at the very beginning of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond. The concept of MBRs was publicly introduced in 1983 with PC DOS 2.0.

The MBR holds the information on how the logical partitions, containing file systems, are organized on that medium. Besides that, the MBR also contains executable code to function as a loader for the installed operating system—usually by passing control over to the loader's second stage, or in conjunction with each partition's volume boot record (VBR). This MBR code is usually referred to as a boot loader.

The organization of the partition table in the MBR limits the maximum addressable storage space of a disk to 2 TB (232 × 512 bytes). Therefore, the MBR-based partitioning scheme is in the process of being superseded by the GUID Partition Table (GPT) scheme in new computers. A GPT can coexist with an MBR in order to provide some limited form of a backwards compatibility for older systems. [1] GPT

GUID Partition Table (GPT) is a standard for the layout of the partition table on a physical hard disk, using globally unique identifiers (GUID). Although it forms a part of the Unified Extensible Firmware Interface (UEFI) standard (Unified EFI Forum proposed replacement for the PC BIOS), it is also used on some BIOS systems because of the limitations of master boot record (MBR) partition tables, which use 32 bits for storing logical block addresses (LBA) and size information.

MBR-based partition table schemes insert the partitioning information for (usually) four "primary" partitions in the master boot record (MBR) (which on a BIOS system is also the container for code that begins the process of booting the system). In a GPT, the first sector of the disk is reserved for a "protective MBR" such that booting a BIOS-based computer from a GPT disk is supported, but the boot loader and O/S must both be GPT-aware. Regardless of the sector size, the GPT header begins on the second logical block of the device. [2]

GPT uses modern logical block addressing (LBA) in place of the cylinder-head-sector (CHS) addressing used with MBR. Legacy MBR information is contained in LBA 0, the GPT header is in LBA 1, and the partition table itself follows. In 64-bit Windows operating systems, 16,384 bytes, or 32 sectors, are reserved for the GPT, leaving LBA 34 as the first usable sector on the disk. [3] MBR vs. GPT

Compared with MBR disk, A GPT disk can support larger than 2 TB volumes where MBR cannot. A GPT disk can be basic or dynamic, just like an MBR disk can be basic or dynamic. GPT disks also support up to 128 partitions rather than the 4 primary partitions limited to MBR. Also, GPT keeps a backup of the partition table at the end of the disk. Furthermore, GPT disk provides greater reliability due to replication and cyclical redundancy check (CRC) protection of the partition table. [4]

The GUID partition table (GPT) disk partitioning style supports volumes up to 18 exabytes in size and up to 128 partitions per disk, compared to the master boot record (MBR) disk partitioning style, which supports volumes up to 2 terabytes in size and up to 4 primary partitions per disk (or three primary partitions, one extended partition, and unlimited logical drives). Unlike MBR partitioned disks, data critical to platform operation is located in partitions instead of unpartitioned or hidden sectors. In addition, GPT partitioned disks have redundant primary and backup partition tables for improved partition data structure integrity. [5] BIOS

In IBM PC compatible computers, the Basic Input/Output System (BIOS), also known as System BIOS, ROM BIOS or PC BIOS, is a de facto standard defining a firmware interface. The name originated from the Basic Input/Output System used in the CP/M operating system in 1975. The BIOS software is built into the PC, and is the first software run by a PC when powered on.

The fundamental purposes of the BIOS are to initialize and test the system hardware components, and to load a bootloader or an operating system from a mass memory device. The BIOS additionally provides abstraction layer for the hardware, i.e. a consistent way for application programs and operating systems to interact with the keyboard, display, and other input/output devices. Variations in the system hardware are hidden by the BIOS from programs that use BIOS services instead of directly accessing the hardware. Modern operating systems ignore the abstraction layer provided by the BIOS and access the hardware components directly. [6] UEFI

The Unified Extensible Firmware Interface (UEFI) (pronounced as an initialism U-E-F-I or like "unify" without the n) is a specification that defines a software interface between an operating system and platform firmware. UEFI is meant to replace the Basic Input/Output System (BIOS) firmware interface, present in all IBM PC-compatible personal computers. In practice, most UEFI images provide legacy support for BIOS services. UEFI can support remote diagnostics and repair of computers, even without another operating system.

The original EFI (Extensible Firmware Interface) specification was developed by Intel. Some of its practices and data formats mirror ones from Windows.] In 2005, UEFI deprecated EFI 1.10 (final release of EFI). The UEFI specification is managed by the Unified EFI Forum.

BIOS vs. UEFI

UEFI enables better use of bigger hard drives. Though UEFI supports the traditional master boot record (MBR) method of hard drive partitioning, it doesn't stop there. It's also capable of working with the GUID Partition Table (GPT), which is free of the limitations the MBR places on the number and size of partitions. GPT ups the maximum partition size from 2.19TB to 9.4 zettabytes.

UEFI may be faster than the BIOS. Various tweaks and optimizations in the UEFI may help your system boot more quickly it could before. For example: With UEFI you may not have to endure messages asking you to set up hardware functions (such as a RAID controller) unless your immediate input is required; and UEFI can choose to initialize only certain components. The degree to which a boot is sped up will depend on your system configuration and hardware, so you may see a significant or a minor speed increase.

Technical changes abound in UEFI. UEFI has room for more useful and usable features than could ever be crammed into the BIOS. Among these are cryptography, network authentication, support for extensions stored on non-volatile media, an integrated boot manager, and even a shell environment for running other EFI applications such as diagnostic utilities or flash updates. In addition, both the architecture and the drivers are CPU-independent, which opens the door to a wider variety of processors (including those using the ARM architecture, for example).

However, UEFI is still not widespread. Though major hardware companies have switched over almost exclusively to UEFI use, you still won't find the new firmware in use on all motherboards—or in quite the same way across the spectrum. Many older and less expensive motherboards also still use the BIOS system. [7] MBR vs. GPT and BIOS vs. UEFI

Usually, MBR and BIOS (MBR + BIOS), and GPT and UEFI (GPT + UEFI) go hand in hand. This is compulsory for some systems (eg Windows), while optional for others (eg Linux).

Converting from MBR to GPT

From http://www.rodsbooks.com/gdisk/mbr2gpt.html

One of the more unusual features of gdisk is its ability to read an MBR partition table or BSD disklabel and convert it to GPT format without damaging the contents of the partitions on the disk. This feature exists to enable upgrading to GPT in case the limitations of MBRs or BSD disklabels become too onerous—for instance, if you want to add more OSes to a multi-boot configuration, but the OSes you want to add require too many primary partitions to fit on an MBR disk.

Conversions from MBR to GPT works because of inefficiencies in the MBR partitioning scheme. On an MBR disk, the bulk of the first cylinder of the disk goes unused—only the first sector (which holds the MBR itself) is used. Depending on the disk's CHS geometry, this first cylinder is likely to be sufficient space to store the GPT header and partition table. Likewise, space is likely to go unused at the end of the disk because the cylinder (as seen by the BIOS and whatever tool originally partitioned the disk) will be incomplete, so the last few sectors will go unused. This leaves space for the backup GPT header and partition table. (Disks partitioned with 1 MiB alignment sometimes leave no gaps at the end of the disk, which can prevent conversion to GPT format—at least, unless you delete or resize the final partition.)

The task of converting MBR to GPT therefore becomes one of extracting the MBR data and stuffing the data into the appropriate GPT locations. Partition start and end points are straightforward to manage, with one important caveat: GPT fdisk ignores the CHS values and uses the LBA values exclusively. This means that the conversion will fail on disks that were partitioned with very old software. If the disk is over 8 GiB in size, though, GPT fdisk should find the data it needs.

Once the conversion is complete, there will be a series of gaps between partitions. Gaps at the start and end of the partition set will be related to the inefficiencies mentioned earlier that permit the conversion to work. Additional gaps before each partition that used to be a logical partition exist because of inefficiencies in the way logical partitions are allocated. These gaps are likely to be quite small (a few kilobytes), so you're unlikely to be able to put useful partitions in those spaces. You could resize your partitions with GNU Parted to remove the gaps, but the risks of such an operation outweigh the very small benefits of recovering a few kilobytes of disk space. Switching from BIOS to UEFI

See: UEFI_-_Install_Guide#Switching_from_BIOS_to_UEFI Note

Switching from [MBR + BIOS] to [GPT + UEFI]

Switching from BIOS to UEFI consists of 2 parts-

i. Conversion of disk from MBR to GPT. Side effects- Possible Data Loss, other OS installed on same disk may or may not boot (eg Windows)..

ii. Changing from BIOS to UEFI (and installing GRUB in UEFI mode). Side Effects- Other OS (can be both Linux and Windows) may or may not boot, with systemd you need to comment out the swap partition in /etc/fstab on a GPT partition table (if you use a swap partition).

After converting from MBR to GPT, probably your installed Manjaro wont work, so you would need to prepare beforehand what to do in such a case. (eg, chroot using a live disk and installing GRUB in UEFI way)

And Windows 8 if installed in MBR way, would need to be repaired/reinstalled in accordance to UEFI way.

https://wiki.manjaro.org/index.php?title=Some_basics_of_MBR_v/s_GPT_and_BIOS_v/s_UEFI

Repairing GPT Disks by Rod Smith

An Ounce of Prevention

Before you get into trouble, it's worth taking preventive measures: Back up your partition tables! You can do this in either of two ways, and preferably both:

   On gdisk's main menu, you'll find the b option, which saves partition data to a disk file. You can also use sgdisk for this task, as in sgdisk -b sda-backup.gpt /dev/sda to save a backup of /dev/sda to the file sda-backup.gpt. Using either method, the data saved is the protective MBR, the main header, the backup header, and one copy of the partition table. These items are stored in a binary file in this order. You should back up your partition table and keep this file on another computer or on a removable medium (USB flash drive, floppy disk, CD-R, etc.). You can then recover from very serious corruption by loading this file back (using the l option on the recovery & transformation menu) and saving your changes back to the disk's partition table (using w).
   You can display your partition summary information using the p command, and if you want this level of detail, use the i command to view the detailed information on each partition. You can then cut-and-paste this information to a text file and save it. This method results in more tedious recovery than the first, since you'll need to manually re-create your partitions (including their GUID codes, if this detail is important). This method has the advantage, though, that you can print the data on paper for safekeeping with other hardcopy information on your computer. 

If you take the simple precaution of backing up your GPT data, and keeping this backup current with any changes you make, you should find data recovery much easier.

If your disk is already damaged, performing a gdisk binary backup is a wise precaution before you begin repairing the disk. In the event that your repair attempts make matters worse, you may be able to recover the disk to its damaged state by restoring the backup; however, be aware that GPT fdisk's backup function saves the in-memory representation of the on-disk structures, and the program performs some minimal interpretation in the act of loading the data. Therefore, a backup of a corrupt partition table, when restored, might not exactly replicate the original corrupt state; it could be even worse! Things that Can Go Wrong

As described in detail on the What's a GPT? page, GPT disks contain five data structures: the protective MBR, the main GPT header, the main partition table, the backup partition table, and the backup GPT header. Any or all of these data structures can become damaged. Although recovery from some problems is fairly simple, other problems may be impossible to fix.

Any or all of the five GPT data structures can become damaged. The easiest problems to repair without a backup are those that involve just one data structure, or at most two that aren't of the same type. Because the MBR is basically just a placeholder, its loss isn't a big deal, although loss of a hybrid MBR will require some slight recovery effort.

GPT data structures can be damaged in several ways:

   User error—You might, when using GPT fdisk or some other disk partitioning tool, accidentally delete a partition, set the wrong partition type code, or even wipe out an entire partition table. Such problems can be hard to fix, since the partitioning tool will duplicate your error on both the main and the backup data structures. On rare occasion, you might be able to recover information from a hybrid MBR, if your error involved a partition that was hybridized. Use the 'o' option on GPT fdisk's experts' menu to obtain the start sector and length of the affected partition. You can then re-create the partition, entering those values.
   GPT utility errors—GPT utilities can contain bugs, and these bugs can result in any manner of partition table problems. Thankfully, bugs that render a disk completely useless are rare. As noted on other pages of this document, though, GNU Parted and its relatives are known to set incorrect GPT type codes for FAT, NTFS, and bootable partitions. You can use GPT fdisk's 't' option to correct this problem.
   MBR/GPT mismatches—The MBR and GPT can become mismatched in various ways, such as using a GPT-unaware disk utility on a GPT disk or editing GPT partitions on a hybrid disk. GPT fdisk detects some of these problems when it runs, and gives you the option of how to proceed. Typically, you'll want to use the MBR data or the GPT data, discarding the other type of data. If you need to somehow integrate the two, I recommend you back up the data and write down the start and end points of the relevant partitions so you can re-create them.
   GPT disk re-used as MBR—This is a special case of the preceding problem. If you create GPT partitions on a disk and then decide to use the disk as an MBR-only disk, you can end up with mismatched MBR and GPT data structures. This situation can be confusing, and in principle it could cause some utilities to cause further damage or to refuse to work. In this case, the 'z' option on GPT fdisk's experts' menu may be helpful; it wipes out the GPT data structures, leaving the MBR untouched. You should use this option with caution, though; if the disk really is a valid MBR disk, this option could conceivably damage the first or last MBR partition!
   Overwritten GPT main header or table—Various disk utilities have been written to store data in the unused (on true MBR disks) area between the MBR and the start of the first partition. Such utilities, if run on a GPT disk, might overwrite some or all of the GPT main header or partition table. You can use the 'b' and 'c' options on gdisk's experts' menu to have the program use the backup header and partition table, respectively, thus recovering from this problem.
   Disk corruption—Power failures at bad times, bugs in software, or other problems can cause any of the five main GPT data structures (protective MBR, main GPT header, main GPT table, backup GPT table, and backup GPT header) to be damaged. GPT fdisk checks for such damage when it starts, and the verify ('v') option also checks for such problems. Recovery procedures are described later.
   Misplaced data—If you use a hardware RAID array and add a disk to it, the backup data structures will no longer be at the end of the disk. Likewise if you back up your GPT data to a disk file and then restore that backup to a larger disk. In either case, the 'e' option on the recovery & transformation menu will move the backup data structures to their correct location. 

Semi-Automated Recovery

When GPT fdisk starts, it attempts to read the various GPT data structures. In doing so, the program checks the CRC values stored in the main and backup headers, and it performs various other sanity checks. If GPT fdisk detects a problem, it will notify you, and if a fix is obvious, it will implement it automatically. For instance, consider what happens when GPT fdisk discovers that the main partition table's CRC doesn't match that stored in the main header:

1. gdisk /dev/sdc

GPT fdisk (gdisk) version 0.7.2

Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table!

Partition table scan:

 MBR: protective
 BSD: not present
 APM: not present
 GPT: damaged

Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended.

Note: Details of what problems are detected vary from one version to another. Version 0.6.2 substantially improved GPT fdisk's reporting and automatic correction of GPT errors.

This example shows three diagnostic messages:

   The warning ("main partition table CRC mismatch...") indicates that GPT fdisk detected and automatically corrected a problem.
   The partition table scan, which is shown by gdisk (but not sgdisk) even on healthy disks, indicates that the GPT data structures were damaged.
   The caution surrounded by asterisks is intended to grab your attention. Whenever a disk error is found, you should be alert to peculiar program operation, missing partitions, or other oddities; and you should perform at least minimal checks and verification of the data. At a minimum, I recommend viewing your partition definitions with the p command and verifying the disk with the v command. 

To create this example, I used dd to erase the main partition table. In this example, I was able to use GPT fdisk normally from this point on, despite the caution; however, as a general rule, you should pay attention to such warnings.

In some cases, GPT fdisk won't be able to decide what to do when you launch it on a damaged disk. For instance, the software might detect valid GPT data structures and a valid MBR that doesn't include an EFI protective partition. In such cases, gdisk prompts you for which of two or more things to do, such as use the MBR or GPT data structures. In most cases you can use the advanced recovery options to change your choice after you've made it. Manual Recovery Procedures

In some cases, GPT fdisk won't be able to automatically recover. Several recovery options, most of them on the recovery & transformation menu, can help you recover your partitions, provided at least one valid partition table exists on the disk. You can see the available options by typing ? at the recovery & transformation menu's prompt:

Command (? for help): r

recovery/transformation command (? for help): ? b use backup GPT header (rebuilding main) c load backup partition table from disk (rebuilding main) d use main GPT header (rebuilding backup) e load main partition table from disk (rebuilding backup) f load MBR and build fresh GPT from it g convert GPT into MBR and exit h make hybrid MBR i show detailed information on a partition l load partition data from a backup file m return to main menu o print protective MBR data p print the partition table q quit without saving changes t transform BSD disklabel partition v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu

Highlights of these options include:

   The l option on the recovery & transformation menu loads a GPT backup file (created with the b option on the main menu). This is the preferred recovery method if a backup file exists.
   The o option on the main menu causes GPT fdisk to create new GPT data structures (headers, partition tables, and MBR). If your disk's data structures are very badly damaged, using this option first might enable you to load one undamaged partition table to recover your partitions.
   The b and d options on the recovery & transformation menu enable you to load the backup and main headers, respectively. These options both load the specified header from disk and rebuild the other header using the one that was just loaded. The GPT headers specify the location of the partition tables on the disk, as well as of the other header, the disk's GUID, and so on. In a recovery situation, these options may not be very useful; GPT fdisk should automatically use an intact header if it can find one. If both headers are damaged, you may be better off rebuilding a new one.
   The c and e options on the recovery & transformation menu load the backup and main partition table, respectively. If GPT fdisk loaded a damaged partition table, you can use one of these options to load the other, in case it's undamaged. If the program didn't load any GPT partitions, these options could still be useful, particularly after using the 'o' option on the main menu; it's conceivable that the headers were both damaged, but enough of one or both partition tables survive to reconstruct your disk.
   The f option on the recovery & transformation menu loads the MBR and generates a fresh GPT from it. This option can be useful if GPT fdisk mistakenly interpreted an MBR disk as a GPT disk, or if the GPT structures on a hybrid MBR disk were very badly damaged but the MBR definitions remain intact.
   The e option on the experts' menu relocates the backup data structures to the end of the disk. This option can be useful in some recovery situations because, if the headers are damaged, GPT fdisk will become confused about where the backup data structures should reside, and as a result an attempt to write the data (using w) will fail. The e option causes the program to recompute this information. This option is also useful if you've resized a hardware RAID array; in this case, the backup data structures will no longer reside at the end of the disk, so they should be relocated.
   The v option verifies the disk structures. This option displays information on problems the program has identified. Sometimes it reports old problems or problems that will be corrected when you write the data to disk, though, so the report may be overly pessimistic. The v option automatically corrects few problems; it just reports them. This is by design; the problems that are easily solved automatically are handled when GPT fdisk first loads GPT data. Furthermore, although many problems in isolation have obvious solutions, the many possible combinations of different problems pose logical challenges that are best handled on a case-by-case basis by a knowledgeable user. Therefore, the v option presents suggested remedies for many problems, but it doesn't implement them automatically. This way, you can decide which remedy to attempt, should you encounter multiple problems with multiple possible fixes. 

If a verify (v) procedure produces a recommendation of taking just one action, such as loading the backup header, then that's probably a good choice. If the program produces competing recommendations, though, your task is harder. One approach is to take the least radical road. For instance, you might relocate the backup data (using e on the experts' menu) rather than load a header. Another approach, particularly if you run into massive corruption of the headers, is to use the o option on the main menu to build a new set of GPT data structures and then load your old partition table using the c or e option on the recovery & transformation menu. If the original disk used an unusual partition table size, though, you'll need to resize your in-memory table before you can successfully load the table from disk.

In all cases, you should exercise extreme caution when performing data recovery. You can experiment with all of the options just described (except for w); none of the data-recovery tools causes immediate writes to the disk. The w option, though, overwrites all your GPT data structures, so if you aren't sure you've recovered your partitions, you should not employ the w option. The z option on the experts' menu is also very dangerous; this option destroys all GPT (and optionally MBR) data structures and then exits. Caution: Software Under Construction

In writing GPT fdisk, I've attempted to anticipate various types of data corruption that might occur on GPT disks. A few individuals have reported real-world problems, as well. I cannot test every possible problem, though, and so it's possible that a particular type of disk error will cause GPT fdisk to misbehave in strange ways or even make the problem worse, particularly if you use the w option to save changes you make.

If your disk contains mission-critical data, I urge you to contact data-recovery specialists rather than poke around with GPT fdisk or any other data recovery software. Although such specialists charge a great deal of money, they have the expertise needed to make full recovery of your data more likely.

If hiring a data-recovery specialist is out of the question, making a complete backup of the problem disk can help ensure that you won't make matters worse. You can use the dd command to do this job:

1. dd if=/dev/sda of=/dev/sdb

Be sure to get the if and of parameters right; if you reverse them, you'll end up overwriting the disk you want to restore! This example backs up /dev/sda to /dev/sdb. The latter must be as large as or larger than the former disk, and the backup will take a long time—probably measured in the hours. Such a backup will be a complete low-level backup of the original disk, so that if you damage the original during your tests, you can at least restore the backup. Note that if the backup disk is larger than the source, even by a single sector, the GPT backup data structures will be misplaced on the backup disk. This can make GPT data recovery harder, so you may need to work on the original disk rather than the backup.