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.
As GPT has increased in popularity but MBR continues to linger, a new problem crops up from time to time: Disks that have been used with GPT (on a Macintosh, for instance) are being re-used with MBR (on a Windows or Linux system, for instance). There's nothing wrong with this practice, but there is a pitfall: Because the basic MBR data occupies just one sector, compared with several for GPT, using an MBR-only partitioning tool can leave the disk with both valid MBR data and mostly-intact GPT data. The GPT data will not have a valid protective MBR, and any software that adheres strictly to the GPT specification will therefore ignore the GPT data in favor of the MBR data; however, some utilities and OSes will use the GPT data in this case. This is true of GParted 0.5.2 and 0.7.0 (and probably others), for instance. (It prints a warning to the text-mode console from which it was launched, but if you run it from a GUI menu, you won't see this warning!) GParted 1.0.0 uses the MBR data and ignores the GPT data on such disks.
Such disks can be identified in several ways. One is simply a clue: Different disk utilities report that the disk has very different partitions on it. Windows' disk partitioner and GParted may see the disk differently, for instance. Old versions of Linux's fdisk produces output that's much more diagnostic, if you understand the issue:
# fdisk -l /dev/sdf WARNING: GPT (GUID Partition Table) detected on '/dev/sdf'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sdf: 16.2 GB, 16166944768 bytes 256 heads, 63 sectors/track, 1957 cylinders Units = cylinders of 16128 * 512 = 8257536 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdf1 1 1957 15781216+ 83 Linux
The warning at the start of this output should be taken seriously, and it's a normal part of the fdisk output on GPT disks. Note, however, that the disk contains just one partition, and it is not the type-0xEE protective partition that's found on normal GPT disks — it's a regular Linux partition! (Of course, your disk may have some other partition or multiple partitions, but the key is that none of them have ee (meaning a type-0xEE partition) under the Id column of fdisk's output.) A GPT warning on a disk that has a type-0xEE partition is fine, and indicates a GPT disk; and a disk with no 0xEE partition and no warning is also fine (that's a normal MBR disk). It's the combination of the GPT warning with a lack of a 0xEE partition that is the indication of trouble.
Since adding GPT support, though, Linux fdisk ignores the leftover GPT data on such disks and instead uses the MBR data without much comment:
# fdisk -l /dev/sdf Disk /dev/sdf: 14.66 GiB, 15728640000 bytes, 30720000 sectors Disk model: STORE N GO Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdf1 2048 30719999 30717952 14.7G 83 Linux
Thus, you may not have much clue that there's a (potential) problem when using newer utilities. Of course, if everything handles such disks correctly, then the potential problem is just that — potential. On the other hand, there's always the possibility you'll use an old utility or OS that might become confused. Fortunately, there remains one good way to identify such issues: the partition table scan of gdisk. This produces output like the following on this type of disk:
# gdisk -l /dev/sdf GPT fdisk (gdisk) version 1.0.9 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: present Found valid MBR and GPT. Which do you want to use? 1 - MBR 2 - GPT 3 - Create blank GPT Your answer:
GPT fdisk has identified the MBR as being a valid conventional MBR, rather than a protective or hybrid MBR (MBR: MBR only), and it's also found intact GPT data structures (GPT: present). It then asks what to do — more on that question later, but if you use gdisk -l to view the partition table, you can select either of the first two options to view the MBR or GPT, respectively, without changing any on-disk data structures. If gdisk identifies the GPT as damaged, then something else may have overwritten part, but not all, of the GPT data. If you need to recover the GPT data, this situation can be trickier, but if you simply want to wipe it clean, this condition is no more of a problem than having intact GPT data.
If you've identified your disk as having this issue, then before proceeding further, it's wise to create a backup of your MBR data. That way, if something goes wrong, you should be able to restore it. In Linux, sfdisk can back up your partition data to a file:
# sfdisk -d /dev/sdf > parts.txt
Change /dev/sdf to the disk in question, of course. Copy the parts.txt file to a USB flash drive, network share, or some other medium other than the hard disk involved. If you damage your partition table, you can then restore it by typing sfdisk -f /dev/sdf < parts.txt.
With the MBR backup ready, you can launch gdisk again, but without the -l option:
# gdisk /dev/sdf
gdisk will display the same partition table scan data as shown earlier and ask what to do. Since this page is about wiping out errant GPT data, I'll assume you don't want to keep that data. (If you do want to keep the GPT data, you should select option 2, make any changes you want, and then use the w menu option to save your data. The program will then generate a fresh protective MBR. Do not do this if your MBR data are correct, though!)
If you want to keep the MBR and wipe the GPT, your answer to this question of what data to use is irrelevant. You can then proceed to use the z ("zap" GPT data) option on the experts' menu:
Command (? for help): x Expert command (? for help): z About to wipe out GPT on /dev/sdf. Proceed? (Y/N): y GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. Blank out MBR? (Y/N): n MBR is unchanged. You may need to delete an EFI GPT (0xEE) partition with fdisk or another tool.
Warning: Be sure to answer n to the prompt about blanking the MBR! If you answer y to this question, you'll be left with a completely unpartitioned disk! Also, some disk utilities store data in the sectors immediately following the MBR. If GPT fdisk reports that the GPT data are damaged, it could be that such data are present on your disk. In such cases, you may need to restore this post-MBR data after you wipe the GPT data. Alternatively, you could wipe the last sector of the disk rather than use GPT fdisk to destroy all the GPT data structures.
In the case being described on this page, you can ignore the comment about having to delete a 0xEE partition with fdisk — after all, such a partition isn't present!
Instead of using gdisk, you can use sgdisk for this job. Using sgdisk is simpler; however, it doesn't provide as much intermediate information and it's unforgiving of errors. If you want to use sgdisk, you should use the --zap (-z) option:
# sgdisk --zap /dev/sdf
Warning: Be sure to use a lowercase -z if you want to keep the MBR! If you use an uppercase -Z (--zap-all), the MBR will be erased, as well as the GPT! This is useful if you want to create a fresh MBR with another utility or if you want to use the disk with another partitioning system entirely.
A third option is to use FixParts to do the repair. This tool is related to gdisk and sgdisk, but it might not be installed in the same binary package. It detects the stray GPT data and offers to erase it. FixParts is the simplest and safest way to do the job if you're certain that you want to keep your MBR data. If you want to study the GPT data before deciding what to do, though, you should use gdisk.
At this point, your disk should have a valid MBR but no leftover GPT data. Whatever problem led you to this page should be cleared up. (It's conceivable you'll need to reboot before your kernel will use the MBR partition table, though.)
Go on to "Booting from GPT"
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.