Last Web page update: 4/18/2022, referencing GPT fdisk version 1.0.9
This Web page, and the associated software, is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find GPT fdisk or this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!
| Donate $1.00 | Donate $2.50 | Donate $5.00 | Donate $10.00 | Donate $20.00 | Donate another value |
Note: This page is part of the documentation for my GPT fdisk program.
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. (Unfortunately, though, many such OSes can't handle GPT.) I've heard from one user who used this ability to fix an over-2TiB RAID array that had been inappropriately partitioned with MBR. The BSD disklabel support can help simplify and extend a BSD partitioning scheme by removing the need to keep an MBR partition containing a BSD disklabel on the disk of a multi-boot computer.
In addition to converting to GPT format, GPT fdisk supports converting from GPT format to MBR format. This feature, though, comes with some caveats: Depending on how the disk was originally partitioned, it may not be possible to convert all the original partitions. Even if converting all the partitions is possible, there may be restrictions on which partitions can be turned into logical partitions, which may in turn result in some odd or undesirable assignments to primary vs. logical partitions in the final MBR partition table.
Note that the details of how to convert a disk, as well as the problems of a conversion, vary with the conversion type. You should read the appropriate section of this page to learn details. If you want to convert an MBR disk with a BSD disklabel partition, you'll have to perform both conversions.
Conversions from MBR to GPT works because of inefficiencies in the MBR partitioning scheme. Through most of MBR's history, MBR partitioning software would use the first sector for the MBR and leave the rest of the first cylinder (typically 63 sectors) unused, giving room for the GPT data structures (which consume a total of 34 sectors by default, including the protective MBR). More recently, MBR partitioning tools have shifted away from using cylinder/head/sector (CHS) information, and leave all but the first sector of the first 1 MiB of the disk unused — again leaving room for GPT data. Similarly, most MBR partitioning tools leave some unused space at the end of the disk (although sometimes they don't), so there's usually room at the end of the disk for the backup GPT data structures. If there's no gap at the end of the disk, it's usually possible to shrink that final partition in a tool like GParted so that there's a small gap — just 33 sectors is sufficient in most cases.
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.
Converting the partition type codes poses another challenge. Sometimes a single MBR type code has two or more possible translations to GPT GUIDs. This is true of 0x82, for instance, which can mean either a Linux swap partition or a Solaris disklabel. In this case, because gdisk originated as a Linux utility, it translates MBR 0x82 partitions into GPT Linux swap partitions. Some MBR type codes have no direct GPT equivalents. GPT fdisk converts them into a platform-specific default partition type. All of these assignments can be changed by the user, of course.
Another conversion challenge relates to BSD disklabels contained within MBR partitions. As described later on this page, BSD disklabels are tricky to convert. Thus, when you perform an initial MBR conversion, your disklabels will be left intact, so that a potentially unwanted or incorrect conversion won't be forced upon you. In the MBR scheme, several disklabel type codes exist, such as 0xA5 for FreeBSD and 0xA9 for NetBSD. Because I know of only one GPT disklabel code (for FreeBSD), GPT fdisk converts the type code of all known MBR disklabel partitions to the GPT code for FreeBSD disklabels. FreeBSD, at least, can read such a partition just fine. I'm not sure about other OSes, though. Booting from a GPT-based BSD disklabel partition seems tricky at best; I've not succeeded in getting it working. You can instead convert the disklabel partition, breaking its contents out into GPT partitions, and then boot directly from them. (See the Booting from GPT page for details.) I don't know of a GUID code for Solaris disklabels in GPT, and Solaris disklabels are different from BSD disklabels. Thus, I can't recommend converting a disk that contains Solaris disklabels to GPT format unless you know more about this than I do.
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 kibibytes), 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 kibibytes of disk space.
The GPT partition numbers on a converted disk should match the partition numbers under Linux on the original MBR disk. For instance, if a disk had two primary partitions (1 and 3) and two logical partitions (5 and 6), you'll have the same partition numbers on the converted disk. This is perfectly legal for a GPT disk; however, some GPT disk utilities will sort these partition numbers and remove the gaps. You may then need to adjust your /etc/fstab and boot loader configurations. If you'd rather not suffer unexpected surprises, you can sort your partitions in gdisk with the s menu option from the start. You may still need to make /etc/fstab and boot loader changes, but at least you'll know to do this right away and not be taken by surprise by a utility that sorts the partition table but doesn't warn you about the need to make such changes.
As described earlier, MBR's inefficiencies usually provide room for GPT to squeeze in its data structures. This isn't always true, though. Some disks leave insufficient room at the start of the disk, and it's possible for there to be insufficient room at the end of the disk. Sometimes you can use the s option on the experts' menu to work around this problem. This option enables you to resize the partition table from 128 entries to some lower value. This operation is non-destructive (it doesn't destroy the partition table). Using fewer than 128 entries, however, is both highly unusual and a technical violation of the GPT specification. It's conceivable such a configuration will cause problems with some environments. In cursory tests with Linux, Windows Vista, and macOS, all three OSes seem to handle such disks fine. Versions 2.1.0 and 3.0 of GNU Parted choke on such disks, although versions 1.9.0 and 3.3 both handle them fine. Another option for end-of-disk problems is to resize the final partition on the disk. Shrinking it by just 33 sectors (16.5 KiB) should be enough to provide room for the backup GPT header and partition table. GPT fdisk can't resize partitions, so you'll need to use another utility to do this job.
GPT fdisk has supported BSD disklabels since version 0.4.0. This type of partition table can be used in either of two ways:
In the case of whole-disk conversions, it's likely that the first and/or last partitions will overlap with GPT disk structures. In the case of the first partition, you might be able to reduce the GPT table size to save the partition, but the final partition will probably have to be deleted. (It will be converted, but its presence will block any attempt to save the partition table.) If you can resize the offending partition(s) using GParted or a similar tool, a conversion might work better.
Carrier-partition conversions are less likely to run into the problem with overlap of GPT data structures, simply because the BSD disklabel is constrained to the MBR partition size, which in turn is less likely to have size issues. If a carrier conversion completes successfully, the carrier partition is deleted; otherwise it would overlap with its formerly-contained partitions. (Note that a "successful" conversion could be one in which several partitions are dropped in the process!) Thus, you'll have at least one gap in the partition numbering sequence, and the numbers may not match those assigned in Linux or any other OS. You can create a linear partition number sequence starting with 1 by using the s (sort) main-menu option.
Like MBR partitions and GPT partitions, BSD disklabel partitions have type codes. Some of these type codes are obsolete or have no clear GPT equivalents and some are ambiguous. For instance, a common type code is 7, for BSD Fast File System (FFS; aka the Unix File System, or UFS). There are, however, several GPT FFS/UFS codes — for FreeBSD, NetBSD, Apple, and so on. GPT fdisk can't know which to use in the case of a whole-disk BSD disklabel, and even in the case of a carrier-partition disklabel, that conversion occurs after the conversion from MBR to GPT of the carrier partition, so the source OS data has been lost. For the most part, GPT fdisk favors FreeBSD in its assignment of type codes; however, a couple do get converted to NetBSD type codes. Type codes with no obvious GPT equivalents are converted to an OS-specific default. You can of course change the type codes after the conversion.
Unfortunately, the BSD disklabel format is strange, and interpretation varies from one BSD to another. Thus, interpreting BSD disklabels (and therefore converting them to GPT form) is tricky. I've attempted to create a conversion process that works on any BSD disklabel format I know about, but I can't promise that the conversion will succeed. You may find that one or more partitions has disappeared from the conversion or that the converted partitions are unusable because their start and end points are wrong, they overlap with each other, or for other reasons. Therefore, you should be very cautious about your BSD disklabel conversions! Ideally, you should take notes on the disklabel's original contents and compare the converted partitions to your notes to ensure that everything is OK. Be sure to back up your data, and don't convert a booting BSD system unless you're prepared to re-install it.
Another common partition system is the Apple Partition Map (APM). This scheme was used by Apple on Macintoshes until Apple switched to Intel CPUs; at that time, Apple also switched to GPT partitioning.
Starting with version 0.4.0, gdisk detects the APM signature and displays a warning message if it's found on a disk. GPT fdisk cannot, however, convert APM disks to GPT format. Such a conversion is theoretically possible, albeit with the caveat that the first and/or last partitions might be unconvertable because of overlap with GPT data structures.
In practice, gdisk doesn't support APM conversions because these conversions are least important to me personally. MBR support is useful because of the huge installed base of x86 and x86-64 systems that use them, and BSD disklabel support is useful because some of these MBR-based systems dual-boot a BSD OS. The vast majority of computers that use APM run older versions of macOS, which can't handle GPT. APM has been used on removable media, of course, but for them, APM support in an OS seems more sensible than converting a disk from APM to GPT.
Unfortunately, a complete conversion from GPT to MBR is tricky. Any disk with more than four partitions requires use of logical partitions, and as just described, each logical partition requires a small preceding gap to hold its partition descriptor. Because GPT fdisk can't guarantee that such gaps exist, the GPT-to-MBR conversion process can be incomplete.
If you care to try such a conversion, though, it can be done via the g option on the recovery & transformation menu, which produces a new prompt at which additional conversion commands can be typed. You should begin by typing p to view your current partition table:
Command (? for help): r
Recovery/transformation command (? for help): g
MBR command (? for help): p
** NOTE: Partition numbers do NOT indicate final primary/logical status,
** unlike in most MBR partitioning tools!
** Extended partitions are not displayed, but will be generated as required.
Disk size is 3981312 sectors (1.9 GiB)
MBR disk identifier: 0x00000000
MBR partitions:
Can Be Can Be
Number Boot Start Sector End Sector Status Logical Primary Code
1 2048 411647 primary Y 0x07
2 411648 1026047 primary Y 0xAF
3 1026056 1026255 primary Y Y 0x07
4 1026256 1435855 omitted 0x07
5 1435856 2050255 omitted Y 0x8E
6 2050264 2459863 logical Y 0xA5
7 2459872 3074271 logical Y 0x07
8 3074272 3981262 omitted 0xBF
MBR command (? for help):
Additional commands at this prompt are identical to those provided by the FixParts program, so you should consult that page for detailed instructions — but skip down to the "Checking Your Partitions" section, since the preceding sections don't apply to GPT fdisk's MBR conversion. The most useful commands are likely to be r, l, and o, which convert a partition to primary form, convert a partition to logical form, or omit the partition from the final table, respectively. You may also need to use t to change the MBR type code for some partitions, particularly if you're converting FAT partitions. These partitions will be given 0x07 type codes by default, but another type code (probably 0x0c) may be more appropriate. See this page for what is, to the best of my knowledge, the most complete list of MBR type codes.
The MBR system itself imposes some limits on conversions. The need for at least one free sector before each logical partition has already been mentioned. The limit of four primary partitions is another important restriction. All the logical partitions are grouped together in a single extended partition, which takes over one of the four primary partition slots, so if any logical partitions are present, you can have only three primary partitions. The placement of logical partitions in an extended partition means that the logical partitions must all be contiguous. (You may omit partitions from a sequence of logical partitions, though.)
The preceding example omits three partitions by default, but depending on your needs, you might be able to do better. By converting partition 3 from primary to logical, you will then be able to include partition 5 (as a logical) and 8 (as a primary). The final layout will then omit only partition 5.
Partition numbers on the converted disk may bear little resemblance to those on the original disk. Primary partitions are numbered from 1 to 4, and logical partitions are numbered from 5 up. This correlation is not reflected in the listing produced by the p option on the MBR conversion menu.
If you decide to abort a conversion, type q. This action returns you to the recovery & transformation menu. Note that your protective MBR will be rebuilt, so if you were converting a disk with a hybrid MBR, it will be lost if you save your changes in GPT form. If you decide to go ahead with the conversion to MBR, type w from the MBR command prompt. The program will give you a final chance to terminate your changes:
Converted 7 partitions. Finalize and exit? (Y/N):
If you type Y, the program erases the disk's GPT structures and writes the new MBR structures. If you type N, your disk will be untouched; however, GPT fdisk must create a new protective MBR. Therefore, if you were contemplating converting a disk with a hybrid MBR or some other unusual MBR features, you should either exit without saving or re-create your hybrid MBR by using the h option on the recovery & transformation menu.
One caveat of GPT-to-MBR conversions is that the CHS geometry of the converted disk may be very strange by the standards of old-style CHS-centric MBR partitioning. Partitions can begin and end mid-cylinder, particularly if the disk originated as a GPT disk rather than as a conversion from MBR format. (The same is true of MBR disks partitioned by most MBR partitioning tools since the early 2010s.) Such peculiarities don't seem to cause problems for most modern OSes, but I can't guarantee that older or more obscure OSes will react as well.
A GPT-to-MBR conversion will also, of course, not overcome the 2 TiB limitation of MBR. GPT fdisk will convert any partition that's 2 TiB or smaller in size and that begins below the 2 TiB mark. (These limits apply to primary and extended partitions; logical partitions may begin beyond the 2 TiB mark, provided their carrier extended partition is legally placed.) This means that GPT fdisk can create converted partitions that span the 2 TiB mark. As described in the What's a GPT? section of this document, such partitions work fine in some OSes, but not in others. Thus, you should exercise caution if you create such a partition in a GPT-to-MBR conversion.
An alternative to a GPT-to-MBR conversion may be the creation of hybrid MBR, which I describe on my Hybrid MBRs: The Good, the Bad, and the So Ugly You'll Tear Your Eyes Out page. Hybrid MBRs can help GPT-unaware OSes coexist or interact with GPT-friendly OSes; but as you might guess by the title of my page on the subject, hybrid MBRs have their problems.
Conversion operations are inherently risky. For safety, I recommend making a backup of your original configuration before converting a disk. In the case of an MBR-to-GPT conversion, the MBR itself is stored on the first sector of the disk, and can be backed up with dd:
# dd if=/dev/sda of=backup.mbr bs=512 count=1
This example backs up the MBR from /dev/sda (change the device filename as necessary for your system) to backup.mbr. Be sure to get the if and of parameters right; reversing them will wipe out your MBR, rather than back it up! (At least, if backup.mbr exists.) Store the backup someplace safe (on a removable disk or network server, but not on the disk that produced the backup), and you can reverse the process if something goes wrong. This backup will not include your logical partition definitions, but once the MBR is restored, they should reappear, so long as nothing adjusted the data structures later on the disk. To back up everything, other tools can be used. For instance, Linux's sfdisk can back up the partition table to a text file:
# sfdisk -d /dev/sda > backup.txt
This backup may be restored by passing it to sfdisk:
# sfdisk -f /dev/sda < backup.txt
BSD disklabels can be backed up using dd, much like a direct MBR backup; however, the precise location of BSD disklabels varies. Backing up the first 4 sectors of the disk or partition should do the trick, with room to spare; however, backing up too much may cause problems when you restore it, since you might overwrite filesystem data structures that have changed. Try restoring one sector at a time until it starts to work.
Prior to restoring an MBR or BSD disklabel backup after a conversion to GPT, you should completely wipe the GPT data structures. The z option on the gdisk experts' menu (or the -Z option to sgdisk) will do this job.
GPT backups can be made using the b option on gdisk's main menu and restored using the l option on the recovery & transformation menu. (In sgdisk, use -b and -l, respectively.)
Converting from MBR to GPT and then using GPT fdisk's GPT-to-MBR conversion tool will produce a disk that's similar, but probably not quite identical, to the original. The partitions will all be present and will be located in the same places, but disk geometry and placement of the logical partition linked-list data structures may be different. The disk identifier is also almost certain to change.
If you convert a boot disk from one format to another, chances are good that it will no longer boot. If your OS(es) support booting from the new format, you should be able to correct this problem, as described in the Booting from GPT section.
Go on to "Wiping Out GPT Data"
Return to "GPT fdisk" main page
copyright © 2009–2022 by Roderick W. Smith
If you have problems with or comments about this web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Return to my main web page.