Apple Intelligence now features Image Playground, Genmoji, Writing Tools enhancements, seamless support for ChatGPT, and visual intelligence.

Apple Intelligence has also begun language expansion with localized English support for Australia, Canada, Ireland, New Zealand, South Africa, and the U.K. Learn more >

You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

manually repair GUID table

System: Macbook Pro 13 (Late 2013) with Yosemite 10.10.3


Question: How can I manually repair the GUID partition table without destroying windows or OSX


I resized my bootcamp partition by first creating empty space with disk utility. Then booting into windows and using Mini Tool Partiton manager to expand the partition into the free space. This worked in giving my a bootable windows partition and I can also boot into OSX so I dont want to break it now!


However OSX can no longer mount the bootcamp partition and thinks its corrupted.


I have already dug into this somewhat and it seems that the issue is that Mini Tool has edited the MBR but this change has not been detected by OSX and put in the GUID partition table (these are separate entities? correct me if I'm wrong).


So using "sudo gpt show disk0" i get this


gpt show: disk0: Suspicious MBR at sector 0
      start       size  index  contents
          0          1         MBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6        
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  859375000      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  859784640    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  861054176        800        
  861054976   49645568      4 
  910700544   66404352      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  977104896        131        
  977105027         32         Sec GPT table
  977105059          1         Sec GPT header


Disk util list shows

diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            440.0 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data                         34.0 GB    disk0s4


and Testdisk (which you can get here http://www.cgsecurity.org/Download_and_donate.php/testdisk-7.0.mac_intel.tar.bz2) shows this


TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/disk0 - 500 GB / 465 GiB - 977105060 sectors (RO)
     Partition               Start        End    Size in sectors
>P EFI System                    40     409639     409600 [EFI]
 D Mac HFS                   409640  859784639  859375000
D MS Data                745005064  861054976  116049913
D Mac HFS                859784640  861054175    1269536
D MS Data                861054976  977104888  116049913
D MS Data                910700544  977104895   66404352
D Mac HFS                975835488  977105023    1269536





Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
                P=Primary  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
FAT32, blocksize=512, 209 MB / 200 MiB


So from this i'm pretty sure the issue is that there are two entries for the same bootcamp partition and both are from before I did the resize. It seems the windows partition resized now goes from 861054976 to 977104888 but the GUID partition table says 910700544 to 977104888.


How do I fix this without destroying my setup?

MacBook Pro (Retina, 13-inch, Late 2013), OS X Yosemite (10.10.3)

Posted on May 25, 2015 7:14 AM

Reply
23 replies

Mar 17, 2017 10:56 AM in response to Kyuzumaki

Hello,


I had the same problem, I will post my solution here perhaps it will be useful for someone else.
1. Download and install gdisk https://sourceforge.net/projects/gptfdisk/

2. Open up terminal and type sudo gdisk /dev/rdisk0 and enter your password

3. Type p and take a look at your partition table

4. The problem is partition 4, minitool updated the MBR but not GPT. GPT has wrong information as you can notice. Partition 4 still has the start and the size before the resizing. This creates a mismatch and prevents Mac OS from mounting the partition. So we need to copy the values from MBR to GPT.

5. Type r (recovery/transformation)

6. Type f (load MBR and build fresh GPT from it) Type Y (proceed)

7. Type p and write down the start and end values of partition 4

8. IMPORTANT! Do NOT write the changes to disk, instead type q and quit without saving changes. In my case EFI partition was not visible, which would make the machine unbootable.

9. sudo gdisk /dev/rdisk0 again and enter password

10. Type d (delete)

11. Type 4

12. Type n (new)

13. Type 4

14. Enter the start and end values from step 7, enter partititon type 0700

15. Now type w to write the values, confirm by typing y and restart your mac. All done!


I hope this was useful 🙂

Mar 17, 2017 2:25 PM in response to tolgainci

tolgainci wrote:



I hope this was useful 🙂

Be aware, that this is a solution for legacy BIOS/Hybrid MBR on 2014 or older Macs. This is not viable on 2015 and later EFI-only installations. MPT is not a very good tool on Macs. The developers of MPT still do not seem to understand Hybrid MBRs, which have been around for a long time.

May 25, 2015 9:03 AM in response to Kyuzumaki

Leave your Testdisk display and start a new Terminal Window. You need to use the following steps.


If you see any error messages during the following steps, please stop and post back here with the error message. The following steps have values from your Testdisk output (and you can verify) in Steps 7 and 8.


Rebuild GPT4 using start/end offsets


  1. Sudo gdisk /dev/rdisk0
  2. P (print the full list of parts)
  3. D (delete)
  4. 4 (part 4)
  5. N (new part)
  6. 4 (part 4)
  7. 861054976 - Start offset in bytes (start point for Bootcamp part)
  8. +116049913 - Size offset (as opposed to End offset)
  9. 0700 (Windows part type)
  10. P (print list of all parts just to see what changes will be made)
  11. W (Write the new GPT)
  12. Y (Yes! really write the new GPT)

This will delete and re-write the GPT partition info for /dev/disk0s4.

Test 1 - Does Bootcamp Volume show up in Finder?

Test 2 - Can you see files in Bootcamp Volume?

Test 3 - Can you select Bootcamp in System Preferences -> Startup Disk?

Test 4 - If Test 3 is successful, select Bootcamp and Click Restart.

May 25, 2015 10:59 AM in response to Loner T

Thanks for the help so far!! 🙂 I've got to step 11 and its warning me about a MBR mismatch? Should I just go ahead or does something else need fixed first?


Disk /dev/rdisk0: 977105060 sectors, 465.9 GiB
Logical sector size: 512 bytes

Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 977105026
Partitions will be aligned on 8-sector boundaries
Total free space is 944 sectors (472.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       859784639   409.8 GiB   AF00  Macintosh HD
   3       859784640       861054175   619.9 MiB   AB00  Recovery HD
   4       861054976       977104888   55.3 GiB    0700  Microsoft basic data

Command (? for help): w

Warning! Mismatched GPT and MBR partition! MBR partition 4, of type 0x07,
has no corresponding GPT partition! You may continue, but this condition
might cause data loss in the future!

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N):


Also sudo fdisk /dev/disk0 give me


Disk: /dev/disk0 geometry: 60821/255/63 [977105060 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE    0   0   2 -   25 127  14 [         1 -     409639] <Unknown ID>
 2: AF   25 127  15 - 1023 254  63 [    409640 -  859375000] HFS+        
 3: AB 1023 254  63 - 1023 254  63 [ 859784640 -    1269536] Darwin Boot 
*4: 07 1023 254  63 - 1023 254  63 [ 861054976 -  116049920] HPFS/QNX/AUX

May 25, 2015 11:53 AM in response to Kyuzumaki

Your Testdisk shows MS Data to be

D MS Data 861054976 977104888 116049913

Your MBR shows

*4: 07 1023 254 63 - 1023 254 63 [ 861054976 - 116049920] HPFS/QNX/AUX


Notice the 7 sector difference between the two numbers 116049913 and 116049920. This is what Gdisk is warning you about. My suggestion is to use the number from the MBR (116049920) as the number in step 8. You can redo Gdisk steps again to make the GPT and MBR match.

Jun 10, 2015 8:16 AM in response to Loner T

Hi there


similar problem here.


And it seems that here are "the experts". Couldn't find anyone with this in-depth-knowledge.


I wanted to resize a 1TB external HFS+ disk to 850GB and 150GB extra for installing OS X 10.11. Did resize with "DiskUtility". Worked (dismounted, resized, mounted again) whereas access was "very slow" afterwards (maybe it was Spotlight, but didn't expect) meaning opening a 5-file dir took Finder more than 20 secs to show.


So I shutdown and restarted the MacBookPro and no I cannot mount the Volume anymore. It seems to be "there",


Following shows what I've done so far


PPMacBookPro: Peter$ diskutil mount 1TB_Auslagerung


Volume on disk3s2 failed to mount

If the volume is damaged, try the "readOnly" option



auch mit „readOnly“ geht es nicht:



PPMacBookPro: Peter$ diskutil mount readOnly 1TB_Auslagerung


Volume on disk3s2 failed to mount

If the volume is damaged, try the "readOnly" option


That's what info diskutil gets me



PPMacBookPro: Peter$ diskutil list
/dev/disk3


#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.0 TB disk3

1: EFI EFI 209.7 MB disk3s1

2: Apple_HFS 1TB_Auslagerung 850.0 GB disk3s2




PPMacBookPro: Peter$ diskutil info disk3s2


Device Identifier: disk3s2

Device Node: /dev/disk3s2

Part of Whole: disk3

Device / Media Name: Apple_HFS_Untitled_2


Volume Name: 1TB_Auslagerung


Mounted: No


File System Personality: HFS+

Type (Bundle): hfs

Name (User Visible): Mac OS Extended

Journal: Unknown (not mounted)

Owners: Disabled


Partition Type: Apple_HFS

OS Can Be Installed: No

Media Type: Generic

Protocol: FireWire

SMART Status: Not Supported

Volume UUID: F3A6B8DF-6C56-3B28-9F98-206D36875C7B

Disk / Partition UUID: 026A1615-B3E0-40A8-9704-32B0ABACACF7


Total Size: 850.0 GB (849999998976 Bytes) (exactly 1660156248 512-Byte-Units)

Volume Free Space: 0 B (0 Bytes) (exactly 0 512-Byte-Units)

Device Block Size: 512 Bytes


Read-Only Media: No

Read-Only Volume: Not applicable (not mounted)

Ejectable: Yes


Whole: No

Internal: No



PPMacBookPro: Peter$ diskutil verifyDisk disk3


Started partition map verification on disk3

Checking prerequisites

Checking the partition list

Checking for an EFI system partition

Checking the EFI system partition's size

Checking the EFI system partition's file system

Checking the EFI system partition's folder content

Checking all HFS data partition loader spaces

Checking booter partitions

Checking Core Storage Physical Volume partitions

The partition map appears to be OK

Finished partition map verification on disk3



PPMacBookPro: Peter$ diskutil verifyVolume 1TB_Auslagerung


Started file system verification on disk3s2 1TB_Auslagerung

Verifying file system

Checking Journaled HFS Plus volume

Checking extents overflow file

Checking catalog file

Checking multi-linked files

Checking catalog hierarchy

Checking extended attributes file

Checking volume bitmap

Checking volume information

The volume 1TB_Auslagerung appears to be OK

File system check exit code is 0

Finished file system verification on disk3s2 1TB_Auslagerung


So, Volume and HFS+ filesystem seem to be "healthy", just not "mountable".

Got some more info from gdisk and get for your info:


Command (? for help): i


Partition number (1-2): 1

Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)

Partition unique GUID: EEFB69A9-7CB6-493F-B3FF-5AA782F277CF

First sector: 40 (at 20.0 KiB)

Last sector: 409639 (at 200.0 MiB)

Partition size: 409600 sectors (200.0 MiB)

Attribute flags: 0000000000000000

Partition name: 'EFI System Partition‘


Command (? for help): i


Partition number (1-2): 2

Partition GUID code: 48465300-0000-11AA-AA11-00306543ECAC (Apple HFS/HFS+)

Partition unique GUID: 026A1615-B3E0-40A8-9704-32B0ABACACF7

First sector: 409640 (at 200.0 MiB)

Last sector: 1660565887 (at 791.8 GiB)

Partition size: 1660156248 sectors (791.6 GiB)

Attribute flags: 0000000000000000

Partition name: ‚Apple_HFS_Untitled_2'


Command (? for help): p


Disk /dev/disk2: 1953525168 sectors, 931.5 GiB

Logical sector size: 512 bytes

Disk identifier (GUID): 22EF0F44-84DD-4468-9C32-C47EB7163D43

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 1953525134

Partitions will be aligned on 8-sector boundaries

Total free space is 292959253 sectors (139.7 GiB)

Number Start (sector) End (sector) Size Code Name

1 40 409639 200.0 MiB EF00 EFI System Partition

2 409640 1660565887 791.6 GiB AF00 Apple_HFS_Untitled_2


Command (? for help): v


No problems found. 292959253 free sectors (139.7 GiB) available in 2

segments, the largest of which is 292959247 (139.7 GiB) in size.


Recovery/transformation command (? for help): o


Disk size is 1953525168 sectors (931.5 GiB)

MBR disk identifier: 0x00000000

MBR partitions:

Number Boot Start Sector End Sector Status Code

1 1 1953525167 primary 0xEE


Expert command (? for help): d


Partitions will begin on 8-sector boundaries.


sudo gpt show disk2


Password:

start size index contents

0 1 PMBR

1 1 Pri GPT header

2 32 Pri GPT table

34 6

40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B

409640 1660156248 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC

1660565888 292959247

1953525135 32 Sec GPT table

1953525167 1 Sec GPT header


So, it seems to me that "resizing" the index 2 partition to make it 1660156248 + 292959247 should resolve the issue, correct?
@LonerT: you seem to be the "Wizard", could you (or of course anyone else) help?
Would Testdisk and creating an image, then format HD, and re-copy everything (will take a couple of hours) be an option?
I bet it's just changing some bits and bytes.
Appreciate any help,
thanks,
Peter




Jun 10, 2015 8:34 AM in response to ppitton

In Disk Utility, if you click on the 1TB disk, do you see two partitions, one is 800GB and the other is Free Space. Can you drag the bottom right corner of the 800GB partition and make it the full disk? This may be easier than manipulating the GPT. If that does not work, do you have a back up of the 800GB partition?

Jun 10, 2015 9:24 AM in response to ppitton

It may be worth noting before I performed any of the steps above I had to disable core storage on the drive. This does disable Fusion Drive technology and FileVault 2 encryption but if your not using that it shouldn't matter. After disabling reboot into recovery mode by holding CMD+R at startup then diskutility should allow you to resize the volume by dragging the bottom corner around.

Jun 10, 2015 10:08 AM in response to Kyuzumaki

Thanks,


but I did not have FileVault activated at all on this drive.


When I use "diskutil corestorage list" it does only show the internal drive (Macintosh_HD) which is encrypted.


Using "Wondershare Data Recovery" does (with RAW search) find all files but seems to take roughly 8-10 hrs.

"DiskWarrior" didn't find anything.


Since "diskutil verifyVolume" did show that the HFS+ volume is ok I'm hoping to tweak some bits/bytes and have the drive back.


Thanks for your input,


Peter

manually repair GUID table

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.