Wiping Out Old GPT Data

by Rod Smith, rodsmith@rodsbooks.com

Last Web page update: 6/26/2011, referencing GPT fdisk version 0.7.2

I'm a technical writer and consultant specializing in Linux technologies. 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
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal

Note: This page is part of the documentation for my GPT fdisk program.

I've been seeing a new GPT problem crop up with increasing frequency: 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!)

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. Linux's fdisk produces output that's much more diagnostic, if you understand the issue:

# fdisk -l /dev/sdc

WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk
doesn't support GPT. Use GNU Parted.


Disk /dev/sdc: 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/sdc1               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.

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/sdc > parts.txt

Change /dev/sdc to the disk in question, of course. Copy the parts.txt file to a floppy disk, USB flash drive, CD-R, 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/sdc < parts.txt.

With the MBR backup ready, you can continue investigating with gdisk, which is even more explicit in identifying the disk as having a problem:

# gdisk /dev/sdc
GPT fdisk (gdisk) version 0.7.2

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:

The partition table scan identifies the MBR as being MBR-only and GPT data as being present. This is the definition of the problem. (If the MBR is MBR-only and the GPT is damaged, the problem also exists; however, in this case something else may have overwritten some of the non-MBR GPT data, and using GPT fdisk to correct the problem can damage whatever overwrote the GPT data—perhaps a boot loader or disk encryption tool. Proceed with caution in such cases!)

Having identified the problem, gdisk asks what to do. Since gdisk is a GPT tool, it will convert the MBR to GPT form, use the GPT data, or create a blank GPT. 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/sdc. 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, at least if you have access to this tool. 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/sdc

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


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.