Clonezilla fails at cloning with mismatched GPT and MBR partition

Question

I got this message:

This disk contains mismatched GPT and MBR partition: /dev/sda

Clonezilla's FAQ says:

You might have installed an OS with GPT partition table, and later overwrite the disk by installing another OS with MBR partition table. The MBR partition table editor, e.g. fdisk, sfdisk, or cdisk does not know GPT, so it overwrite part of the GPT partition table, but did not clean the rest completely. Therefore that's why you got such a message.

If you are sure your running OS is using MBR partition table, not GPT one, you can run sudo sgdisk -z /dev/sdx (Replace /dev/sdx with your disk name, e.g. /dev/sda for the 1st hard drive) to clean the GPT partition table, while keep the MBR partition table. //NOTE// Use the above command carefully. It might destroy everything on the harddrive.

I installed Mac first and Windows second, then replaced the default MBR boot manager with Chameleon Boot Loader.

Here's the partition table:

   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS macintosh               69.3 GB    disk0s2
   3:                  Apple_HFS mavericks               180.0 GB   disk0s3
   4:       Microsoft Basic Data Melomano                749.9 GB   disk0s4

Disk0s3 is the current MacOSX partition, disk0s2 is a Time Machine backup and disk0s4 is Windows 8.1.

What should I do?

Solution 1

Solution Resolve the conflict observed by clonezilla, by removing one of the entries (gpt). To do this, access the command line terminal of clonezilla. Use the following command to delete the gpt.

sudo gdisk /dev/sda
(Press 1 to select MBR)
Press 'x' and enter to reach the eXpert mode
Now press 'z' to delete the gpt
At this step be careful, you will get an option to blank out your MBR, do **NOT** do it.
Press Ctrl + C when ever you need to exit from gdisk.

Possible Cause When Windows gets installed in SSD, it creates a GPT. In my system the GPT was blank. Now when, clonezilla finds that MBR has the pariotion structure whereas GPT is blank, it throws an error. So, when the GPT is deleted, there is no more conflict.

Note Before performing this, please take a backup of your data, so that even if you accidentally delete the correct partition format, you can still retrieve your data.

Solution 2

Chances are you should be using a hybrid MBR with your setup. I don't know if Clonezilla deals well with that. If you need the hybrid MBR and Clonezilla doesn't like it, you could back up your hybrid MBR (in fact, your whole partition table) with gdisk, create a fresh protective MBR to replace the hybrid MBR, use Clonezilla, and then restore the hybrid MBR. This is a pretty advanced dance, though, so I recommend you do it only once you understand what you're doing. Read the gdisk documentation and anything else (maybe the Wikipedia article on GPT) until you understand it. (I haven't provided step-by-step details because I don't want to encourage anybody who doesn't understand it to try it.)

It's also possible that your hybrid MBR is damaged or that you've got mis-matched GPT and MBR data. In this case, you'll need to repair your partition table. The details of what you'll need to do depend on what specific damage you've suffered, and your post doesn't provide sufficient details to reveal that. The gdisk documentation site includes a page on repairing GPT damage, which should help you get started. Posting detailed output of both the GPT and MBR data might help us understand what's going on. To do this, enter gdisk, type x to enter the experts' menu, type p, type o, and then type q to quit. Post the entire session output. If gdisk asks you whether to use GPT or MBR data when you first start it, then that means that they're badly mis-matched, and you need to decide which to use. Note that in this sort of situation, OS X is likely to use the GPT data and Windows will use the MBR data, so you'll need to carefully check both tables, figure out which is correct (or which portions of each is correct), and develop a plan to reconcile them.

If you're lucky, the fix for your problem will be easy. Be careful, though, because it's possible that you're heading into very treacherous waters. If you have important data on that disk, back it up before you do anything else!!!!

Solution 3

For anybody else that might struggle or face the same issue, here is a tool you can use to that will surpass the MBR - GPT issue.

WinPE this worked fine for me. https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/winpe-intro

The downside of this software is that it is vendor specific, meaning Windows only, second it will take up 5-7GB of disk space. but if you wold like, i can can give you a copy (github repo) of my tools that I have created, that way, you won't be required to install it.

Follow the documentation on the provided link

Comments

[Gabriel]

Thank you, as you suggested the partition table was a mess, so I went with the long route and used Carbon Copy Cloner in OS X and DriveClone in Windows to backup each partition accordingly. Also Chameleon boot loader was used to replace the standard Bootcamp manager.

[Le Droid]

I was unable to boot after this operation but hopefully I did first a backup of the first 512K (not only 512 bytes) of the disk with "dd if=/dev/sdX of=backStartOfDisk bs=512K count=1". After applying your solution, I restored partially the backup with "dd if=backStartOfDisk of=/dev/sdX bs=512 seek=1 skip=1 count=256". This last command skipped the first 512 bytes to leave them as corrected, then restored the following 256K that was missing for a normal boot. Thanks!

[Ryan Leach]

The problem is, cloning the disk WAS my backup solution. Now you are asking me to make a backup, before I make my backup...

[Teodorico Sidonio]

The reason I had to relay on different resources, is because I my listed drives had information I intended to clone.