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.
GPT is a very flexible partitioning scheme with many advantages over the older MBR system. (For details, see the What's a GPT? section of this document.) GPT does have one glaring problem, though: compatibility. Some OSes, particularly older ones, have limited or no GPT support. When using such an OS, an ugly, flaky, and downright dangerous workaround can sometimes be useful: hybrid MBRs. Using a hybrid MBR, you can satisfy your legacy OS's need for up to three partitions defined via an MBR, while keeping additional partitions for more sophisticated OSes in GPT data structures.
As noted on other pages in this document, a conventional GPT disk contains a protective MBR with a single partition, of type 0xEE (EFI GPT), defined. This partition spans the entire size of the disk or 2 TiB, whichever is smaller. The intent is to keep GPT-unaware OSes and utilities from trying to modify the disk.
A hybrid MBR is a variant on the normal protective MBR. A hybrid MBR contains a type-0xEE partition, but it also contains up to three additional primary partitions, which point to the same space that's marked out by up to three GPT partitions. For instance, suppose you've got a Macintosh that dual-boots macOS and an older version of Windows (Windows 7 or earlier). MacOS is happy on GPT, and so can use GPT partition definitions; but Windows versions prior to Windows 8 (on Macs) are less capable in this respect. Thus, you'll define your partitions first as GPT partitions (including your Windows partitions), and then you'll modify your protective MBR so that its 0xEE partition is smaller than normal and it contains one to three partition definitions that point to the same disk locations as corresponding GPT partitions. You can then install Windows on these hybridized partitions. In the past, Apple's Boot Camp helped automate this process, so you don't need GPT fdisk to set up a hybrid MBR on a Mac; however, GPT fdisk can be useful in maintaining your hybrid MBR after it's configured, and you might want to use it on BIOS-based computers for similar configurations involving other OSes. On any computer, the end result is that GPT-unaware OSes can use up to three primary partitions, while GPT-aware OSes can use all the partitions on the disk.
Note that the preceding description specified Windows 7 or earlier. Beginning with Windows 8, Microsoft's OS installs on most Intel-based Macs in EFI mode, so a hybrid MBR is not required. Microsoft ended support for Windows 7 in 2020, so chances are you shouldn't be running such an old version of the OS. Apple's current (in 2022) description of Boot Camp emphasizes Windows 10. Similarly, hybrid MBRs are increasingly unnecessary to run other OSes, since EFI boot loaders and GPT support are now available for most current OSes that run on x86 and x86-64 laptop, desktop, and server computers. If you need to run a really old OS, a virtualization tool such as VMware or VirtualBox may work as well as a dual-boot configuration.
The preceding description makes hybrid MBRs sound great if you need to run an older GPT-unaware OS: You get the best of both MBR and GPT by creating a hybrid MBR. Unfortunately, hybrid MBRs carry with them a lot of baggage. Some of these problems are mere annoyances, but other issues are real dangers. They include:
Overall, hybrid MBRs should be avoided. I've included support for them in GPT fdisk only because they're used by Apple's Boot Camp to boot Windows 7 and earlier, and because they can be useful in certain other exotic configurations involving both BIOS-mode and EFI-mode OS installations or large (over 2TiB) disks on BIOS-based computers in some dual-boot situations. This fact makes hybrid MBRs a practical necessity in some environments. Older non-Windows OSes (BeOS, OS/2, DOS, etc.) are likely to require a hybrid MBR to handle GPT disks, too, although I haven't tested them explicitly.
If you've read this far, you're presumably interested in creating a hybrid MBR. In the past, Apple's Boot Camp and the gptsync tool were the only ways I knew of to create hybrid MBRs. Boot Camp is very specialized and the gptsync program has certain limitations. For instance, it blindly converts the first three GPT partitions to MBR form, and it chokes when it sees partition types it doesn't understand. GPT fdisk is more flexible in both respects, but it requires more user interaction. Hybrid MBR support was added to GPT fdisk 0.3.2 and to sgdisk 0.6.4.
The procedure for creating a hybrid MBR is best illustrated with an example:
# gdisk /dev/sdc GPT fdisk (gdisk) version 1.0.9 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help): r recovery/transformation command (? for help): p Disk /dev/sdc: 15654912 sectors, 7.5 GiB Model: USB Flash Drive Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): E1F3535B-8F5B-1579-E04A-D8DEF36B8302 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 15654878 Partitions will be aligned on 8-sector boundaries Total free space is 6 sectors (3.0 KiB) Number Start (sector) End (sector) Size Code Name 1 40 3072007 1.5 GiB AF00 Apple HFS/HFS+ 2 3072008 7266311 2.0 GiB 8300 Linux filesystem 3 7266312 15654878 4.0 GiB 0700 Microsoft basic data recovery/transformation command (? for help):
The hyrid MBR function is located on the recovery & transformation menu, so after launching gdisk, you should type r to enter that menu. You'll also need to know partition numbers, so you should type p, as shown in the example. The example disk (a USB flash drive) has three partitions, containing HFS+, ext4, and FAT filesystems.
recovery/transformation command (m for help): h WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one, just hit the Enter key at the below prompt and your MBR partition table will be untouched.
The command to create a hybrid MBR is h. Typing that command causes a warning to be displayed before gdisk prompts for partition information.
Type from one to three GPT partition numbers, separated by spaces, to be added to the hybrid MBR, in sequence: 1 3 Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): y
You specify the partitions you want to hybridize by listing their numbers, separated by spaces. In this example, I've hybridized partitions 1 and 3 (the HFS+ and FAT partitions). They'll become MBR partitions 1 and 2 or 2 and 3, depending on the answer to the next question.
GPT fdisk can create the EFI GPT (0xEE) placeholder partition either before or after the hybridized partitions in the MBR table. (Note that this has nothing to do with the disk sectors this partition protects.) Each placement has its advantages. Putting the 0xEE partition first in the table works best with GRUB Legacy and GRUB 2, which treat the disk as an MBR disk if the first slot in the MBR is not a 0xEE partition. This first-position placement of 0xEE, however, can render Windows unable to read subsequent partitions if the disk is a removable disk, such as a USB flash drive. Overall, if the disk is a hard disk, I recommend putting the 0xEE partition first; if it's a removable disk, putting it later in the table may work better.
Creating entry for partition #1 Enter an MBR hex code (default AF): af Set the bootable flag? (Y/N): n Creating entry for partition #3 Enter an MBR hex code (default 07): 0c Set the bootable flag? (Y/N): y Unused partition space(s) found. Use one to protect more partitions? (Y/N): y Enter an MBR hex code (EE is EFI GPT, but may confuse MacOS): 0a
The program now prompts you for some information about each partition. In each case, gdisk asks you for an MBR hex code. Although the program could convert automatically, one common GPT type code (0700 in GPT fdisk) can map to several different MBR type codes. This fact makes explicit prompting at this point more sensible than a blind conversion. In this case, since the second hybridized partition (#3 in GPT) holds a FAT filesystem, I chose to use a type code of 0x0C. (See this list if you need to find MBR type codes.) You should enter a two-character hexadecimal value, with or without a leading "0x" indicator, or press the Enter key to use the default value. You can also set the bootable flag (aka the active flag) on any or all of your hybridized partitions; however, this flag is normally set on just one partition. Ordinarily, you'd set the bootable flag on a Windows boot partition, but not on data partitions. (At least one boot loader behaves strangely if you use this flag on Windows, though.) For illustrative purposes, I've set this flag on one partition.
Because I only hybridized two partitions, there was one unused space in the partition table, meaning that GPT fdisk could add one more MBR partition to protect free space from accidental modification. The program will fill the largest empty (to MBR) space on the disk with the partition it creates. You're asked if you want to do this, and in this example I responded in the affirmative. The program then asks for the MBR hex code for the created partition. Although 0xEE is a logical choice, using it will cause macOS to interpret the disk as an MBR disk, thus removing the benefits of GPT for that OS. In this example, I used 0x0A, which is the code for an OS/2 Boot Manager partition. My reason for using this code is simply that few disk utilities will attempt to do anything with such a partition. Many other codes will work as well, but all non-0xEE codes will be misleading or ambiguous.
One drawback to using a non-0xEE extra protective partition is that gdisk's own data integrity checks may flag this partition as a problem. In particular, if the partition spans multiple GPT partitions or covers an area that doesn't correspond to any GPT partition, gdisk will complain when you save your partitions or perform a disk verification (via the v menu option). If your spare protective partition is of type 0xEE, though, gdisk won't complain. Overall, if you're using macOS, it may be best to forego this partition. If you use Linux, FreeBSD, or Windows, but not macOS, I know of no reason not to create an extra 0xEE partition.
Note that even with the extra protective partition, significant parts of a disk could go unprotected. In the case of this example, it's just a few sectors at the end of the disk; however, if you hybridize two non-contiguous partitions, the last of which is not at the end of the disk, either the partitions at the end of the disk or the space between the partitions will be unallocated in an MBR sense. If you hybridize three partitions, it's likely that even more space will be unallocated in the MBR scheme. On a sub-2 TiB disk, you can maximize the protected space by placing the partitions to be hybridized at the end of the disk. That way, the 0xEE partition will span from the second sector (numbered 1 in partition listings) all the way up to the first hybridized partition.
Before writing your changes, you should check the status of the hybrid MBR:
recovery/transformation command (? for help): o MBR disk identifier: 0x00000000 MBR partitions: Number Boot Start Sector End Sector Status Code 1 1 39 primary 0xEE 2 40 3071968 primary 0xAF 3 * 7266312 8388567 primary 0x07 4 3072008 7266311 primary 0x0A Disk size is 15654912 sectors (7.5 GiB)
Typing o at the recovery & transformation prompt displays the MBR data, and you can see the hybrid partition definitions. (Caution: The o command, when typed at the main menu, creates a fresh GPT, including a new protective MBR.) If you compare the start and end values to the start and end values for the GPT partitions, you should see that they match for the hybridized partitions. The EFI GPT (0xEE) partition covers the GPT data structures, and in some cases it can cover more. If you don't hybridize the partition that comes first in disk order, the EFI GPT partition will cover its space, for instance. In this example, the extra 0x0A partition covers the area of the second GPT partition, since that was the single largest area that was unallocated in the MBR scheme. In other cases, you might have an MBR partition that spans multiple GPT partitions or that just covers a bit of unused space at the end of the disk (protecting the secondary GPT data structures and perhaps one or more partitions at the end of the disk). If you hybridize only one GPT partition and choose to create the extra protective partition, GPT fdisk will be able to protect all the available disk space in the combination of the regular 0xEE partition, the extra protective partition you create, and the hybridized partition itself.
If necessary, you can modify the hybrid MBR with Linux's fdisk or other GPT-unaware partitioning tools. (Recent versions of fdisk are GPT-aware. To modify the hybrid MBR with them, include the -t dos flag, as in fdisk -t dos /dev/sdc.) GPT-aware programs, however, are likely to modify the GPT side alone, or perhaps change the hybrid MBR back into a standard protective MBR, as GNU Parted does, at least through version 3.3. Because GPT doesn't use CHS addressing, you're likely to find that your partitions don't begin or end on cylinder boundaries, as viewed by fdisk or other MBR tools. This isn't a problem with modern OSes, but if you need to boot a truly ancient OS, such as DOS, you may not be able to use even the hybrid MBR partitions.
Note that the MBR entries may not be in order. In the preceding example, the entry for the 0x0A partition comes at the end of the table, although its disk area is between the two real partitions. If you choose to place the 0xEE partition's entry after the main partitions' entries, the order can become even more confused. For the most part, these deviations won't cause problems, although some utilities have specific quirks, as already noted.
In testing hybrid MBRs, I've found that different OSes react to them in different ways. Further complicating matters, the boot loaders you use to boot your OSes have their own quirks, as detailed shortly, in Booting from a Hybrid MBR. Unfortunately, these differences can make use of a hybrid MBR a complex and frustrating task. OS-by-OS peculiarities include:
I don't know how other OSes, such as BeOS, OS/2, DOS, Solaris, or NetBSD, react to hybridized MBRs. If you have problems with such an OS and the hybrid MBRs created by GPT fdisk, you might want to give gptsync a try. It does things a bit differently, so it's conceivable that one tool might work better in some environments and the other will work better in others.
Hybrid MBRs are often used on boot disks with multiple OSes, and so the issue of bootability is an important one. Unfortunately, this is an area that's even more poorly documented than the murky area of booting GPT disks generally. I've done some experimenting, but I don't claim to have all the answers. Some information I consider reliable includes the following:
Unfortunately, the non-standard nature of hybrid MBRs means that you'll be venturing into uncharted territory when you use this type of configuration with most tools. Generally speaking, macOS users seem to be the most experienced with such setups, thanks to Apple's Boot Camp and the OSx86 (macOS on stock PC) communities.
Most BIOS-mode OSes try to install their own boot loaders to the MBR when you install them. Thus, when you install multiple OSes, you often end up overwriting the earlier OSes' boot loaders. You can generally use GRUB or some other flexible boot loader in the MBR to redirect the boot process to any OS; however, sometimes this doesn't work. One trick that can be helpful is to back up the MBR, or at least its boot code (the first 440 bytes) after every OS installation. In Linux, you can use dd to do the job:
# dd if=/dev/sda of=/boot/sda-mbr-backup-1.img bs=512 count=1
This command backs up the entire MBR. If you change bs=512 to bs=440, only the MBR's boot loader will be backed up, which could be preferable if you want to restore the boot loader later without affecting the MBR partition table. With a backup of the MBR's boot loader from after each OS installation in hand, you can try redirecting the boot process through such a backup file, if you can't find a more direct way to boot the OS. In GRUB Legacy, the configuration would look like this:
title OpenSolaris 2008.11 captured MBR
root (hd0,1)
chainloader (hd1,4)/hda-solaris-mbr.img
This example is taken from an actual OpenSolaris installation on one of my computers, although the installation in question doesn't use a hybrid MBR. The details will vary with boot loaders other than GRUB, of course.
As I've said before, hybrid MBRs are clunky, ugly, and dangerous. If at all possible, I recommend you avoid them. If possible, use two disks rather than a hybrid MBR. Place your GPT-unaware OSes on the MBR disk and use GPT on the other disk. Windows Vista and later (and some earlier versions, depending on platform) can read GPT disks just fine once booted; they just can't boot from GPT. This fact gives you an "out" if you need to use large disks or employ GPT for another OS's benefit, since you can boot Windows from an MBR disk and store data on a separate GPT disk. Some RAID controllers enable you to configure a RAID array as two or more virtual disks, which you can then partition using MBR and GPT. In some cases, using virtualization software, such as VirtualBox or VMware Workstation or Fusion, can be better and safer than dual-booting your OSes.
Sometimes, though, you might really have no alternative but to use a hybrid MBR. This might be necessary on a laptop computer on which you want to install lots of OSes, for instance. In such cases, I recommend you treat your GPT configuration as the standard one. If possible, create the initial partitions using GPT fdisk or some other GPT partitioning tool; converting from MBR to GPT and then hybridizing presents more opportunities for problems to crop up. (On the other hand, an older MBR partitioning tool is more likely to create partitions on cylinder boundaries, which some older OSes may appreciate.) If you run into problems or need to repartition, restore a standard GPT protective MBR (using the n option on GPT fdisk's experts' menu), do whatever you need to do to your partitions, and then create a fresh hybrid MBR.
In my experience, Windows doesn't react well to changes in its partitions. (This has been true for many years; it's not a GPT-specific issue.) Thus, if possible you should install Windows after you create hybrid MBR partitions for it. Plan to re-install your MBR-based boot loader after installing Windows. On the other hand, Windows will create new partitions for itself if it doesn't see all the partitions it needs, so you must be careful to create all the partitions that Windows requires before you begin, lest it create MBR partitions that overlap with GPT partitions.
On a sub-2 TiB disk, place the partitions you must access via MBR at the end of the disk, to enable the EFI GPT (0xEE) partition to protect the non-MBR partitions. If you can keep your hybridized partitions contiguous, and numbered at just 1 or 2, you'll also be able to create a second protective partition to keep the secondary GPT data safe from meddling by GPT-unaware utilities.
On an over-2 TiB disk, having just 1 or 2 hybridized partitions becomes even more important, since you'll then be able to create a second protective partition after those partitions. Alternatively, you could place your to-be-hybridized partitions so that they're contiguous and terminate as close as possible to, but before, the 2 TiB mark. This layout will protect the preceding GPT partitions (via the 0xEE MBR partition), and the subsequent GPT partitions will be protected by virtue of falling after the MBR's 2 TiB limit.
Discussion forums are filled with posts about hybrid MBRs, mostly from people using Boot Camp with macOS. If you run into problems, try posting to such a forum. Although I may be able to help, I minimize my own use of hybrid MBRs, and my impression is that hybrid MBR problems can be quite quirky and configuration-dependent, so your best bet in getting help is to post your problems in a well-read forum.
The preceding describes hybrid MBRs as they are commonly used in 2009 and early 2010, with updates as late as 2022. This PDF document, however, describes an entirely different type of hybrid MBR. This type of hybrid MBR is basically an MBR partition scheme embedded within a GPT partition. The idea is that GPT-unaware OSes could, with the help of a modified boot loader, boot from the GPT partition as if it were a hard disk. As written, this document only mentions in passing the MBR Partition Scheme (GPT fdisk code EF01) that's already defined; instead, it emphasizes setting a new attribute bit.
To the best of my knowledge, no boot loader or OS currently implements this alternative type of "hybrid MBR" configuration. If you hear of such an implementation, I'd be interested in learning about it.
Go on to "Repairing GPT Disks"
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.