MacOS – How to fix Mac hard drive partition showing as FDisk_partition_scheme

disk-utilitydiskutilhard drivemacospartition

My situation seems very similar to how to fix GUID hard drive corrupted to MBR but with enough differences that I haven't been able to put together a confident solution.

I have a 3TB Toshiba drive in a USB enclosure being used on a Mac with OS X El Capitain 10.11.3.

The drive was set up with a single partition. The drive was not bootable and did not have a system installed so I'm assuming it would not have a recovery partition either. I can't say for sure it never had a system installed, but I don't think so. It has not been used with Bootcamp or on any non-Mac computer.

The drive worked normally for a long time but then failed to be recognized recently. On investigating with Disk Utility, it shows as having a partition type of FDisk_partition_scheme. I'm sure it was originally the typical default of GUID Partition Map formatted as OS X Extended (Journaled).

I can't think of any specific use or event that may have caused the change.

Here is the information I've collected from the drive.

diskutil list /dev/disk6

/dev/disk6 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *3.0 TB     disk6
   1:                       0xEE                         375.1 GB   disk6s1

diskutil info /dev/disk6

   Device Identifier:        disk6
   Device Node:              /dev/disk6
   Whole:                    Yes
   Part of Whole:            disk6
   Device / Media Name:      DT01ABA300

   Volume Name:              Not applicable (no file system)

   Mounted:                  Not applicable (no file system)

   File System:              None

   Content (IOContent):      FDisk_partition_scheme
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 USB
   SMART Status:             Not Supported

   Total Size:               3.0 TB (3000592982016 Bytes) (exactly 5860533168 512-Byte-Units)
   Volume Free Space:        Not applicable (no file system)
   Device Block Size:        512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)

   Device Location:          External
   Removable Media:          No

   Virtual:                  No
   OS 9 Drivers:             No
   Low Level Format:         Not supported

fdisk /dev/disk6

Disk: /dev/disk6    geometry: 97451/255/63 [1565565872 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -  732566645] <Unknown ID>
 2: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 3: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 4: 00    0   0   0 -    0   0   0 [         0 -          0] unused

gpt recover /dev/disk6

gpt recover: /dev/disk6: no primary or secondary GPT headers, can't recover

gpt -r -vv show /dev/disk6

gpt show: /dev/disk6: mediasize=3000592982016; sectorsize=512; blocks=5860533168
gpt show: /dev/disk6: PMBR at sector 0
       start        size  index  contents
           0           1         PMBR
           1  5860533167

gdisk /dev/disk6

GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.

Here is a screen shot of the first part of the drive in wxHexEditor. The EFI PART starts at 4096.

I started looking for the HFSJ string starting at an offset of 409642, as suggested in other answers, but didn't find it near there. So I searched starting from the beginning of the drive and found the first occurrence at offset 314598400.

However, if I keep searching for occurrences of HFSJ, I find a lot of them that look exactly the same and with a lot of zero space around them, like the first one. Those start at 360424448 and are spaced 32768 apart. For example, at offsets
360424448
360457216
360489984
360522752
360555520

I used the Find All search in wxHexEditor and stopped after a few minutes. It had found a couple thousand at that point. I'm not sure what to make of those, if anything.

I was also able to find a section labeled EFI System Partition at offset 3000592961536. That also shows the name that the drive had, "Rosie".

Here are screen shots of the first HFSJ partition and the EFI System Partition. Added a screen shot of offset 8192 based on the comments.

Thanks for any help.

Best Answer

Please try the following:

Get the disk identifier of your external 3 TB drive
```
diskutil list
```
Below I assume the disk identifier is disk6
unmount the disk:
```
diskutil umountDisk disk6
```

Overwrite the first 40 blocks:

sudo dd if=/dev/zero of=/dev/disk6 bs=512 count=40

Create a new gpt:
```
sudo gpt create /dev/disk6
```

Check the disk info with:

diskutil info /dev/disk6

Reassure yourself that the device block size still is 512 Bytes

You may also use

sudo gpt -r show /dev/disk6

If the gpt shows:

   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2          32         Pri GPT table

you have a disk & disk controller which report a logical block size of 512 Bytes. Please continue with the next step.

If the gpt shows:

   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2           4         Pri GPT table

you have a disk & disk controller which report a logical block size of 4096 Bytes. Please stop here and add a comment.

First rebuild the EFI entry with:
```
sudo gpt add -b 40 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
```
Depending on the size of the disk and the system version differently sized EFI volumes are built if partitioned with Disk Utility: either one with the size 200 MiB or one with 300 MiB. Here it's obvious that your disk contains a 300 MiB EFI and probably 4096 bytes of unallocated disk space: (314598400-1024)/512=614448 (=Start block main volume) 614448-40-8=614400 (=size of EFI)
Rebuild your main volume with:
```
sudo gpt add -b 614448 -i 2 -s SizeOfVolume1 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
The size of the main volume can be determined by the first (corrupted & old) entry of the second GPT table: (3000592961536/512)=5860533128 is its block number. Then the size is calculated by 5860533128-614448=5859918680 blocks. Since 5859918680 is dividable by 8 (4096 physical block size/512 logical block size) this is a good guess for the volume size.

The best guess is finally:
```
sudo gpt add -b 614448 -i 2 -s 5859918680 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
The second best guess is:
```
sudo gpt add -b 614448 -i 2 -s 5859918672 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Probably your lost volume gets mounted now. Verify the volume with:
```
diskutil verifyVolume disk6s2
```
If necessary try to repair the volume.
```
diskutil repairVolume disk6s2
```

Since you moved the "corrupted" disk to a different case and disk controller the logical block size was modified. The old partition map is probably based on a logical block size of 4096 Bytes.

To recover the partition map in the old (4096b) case you would had to enter the following to restore the GPT (based on David Anderson's answer):

Create a new gpt:
```
sudo gpt create /dev/disk6
```

First rebuild the EFI entry with:

sudo gpt add -b 6 -i 1 -s 76800 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6

Rebuild your main volume with:

sudo gpt add -b 76806 -i 2 -s 732457067 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6

the final partition map looks like this:

 sudo gpt -r show disk1
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2           4         Pri GPT table
           6       76800      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
       76806   732457067      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   732533873       32768         
   732566641           4         Sec GPT table
   732566645           1         Sec GPT header

Based on the 4096b part this "retranslates" after installing the disk in a 512b logical block size case to:

Create a new gpt:
```
sudo gpt create /dev/disk6
```

First rebuild the EFI entry with:

sudo gpt add -b 48 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6

Rebuild your main volume with:

sudo gpt add -b 614448 -i 2 -s 5859656536 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6

This differs from the first (accepted) part of my answer but is the proper one! Since the EFI actually is "empty" and the 262144 unallocated blocks contain zeros only, the "first and somehow wrong" answer doesn't affect the operability of the volume.

Related Solutions

I think I messed up the Fusion Drive on the 1TB iMac (with BootCamp)

Theoretically everything is fine with your Fusion Drive. Fusion Drives look like this. Disk0 is your SSD with 121 GB and disk1 is your HDD with ~1 TB (~1.121 TB summed up).

The larger parts of your SSD (disk0s2) and your HDD (disk1s2) are pooled to a CoreStorage LVG (Fusion Drive: disk3) with a size of 967.8 GB. The rest is reserved for EFIs, a Recovery HD (alltogether ~1.3 GB) and your old Windows partition - now probably free space (~152 GB).

The logical volume 'Macintosh HD' (967.8 GB) spans disk0s2 and disk1s2. This is the first 'Macintosh HD' in picture 1. The volume 'Macintosh HD' - it's the one visible on the desktop - should ideally also have about 967.8 GB. This is the second 'Macintosh HD' in picture 1.
In fact it has only 852.67 GB (see picture 3).

In the second picture the logical volume 'Macintosh HD' is the first listed in black, the volume 'Macintosh HD' is the second listed in black, the other two 'Macintosh HD's listed in grey are the parts of your SSD and HDD dedicated to the logical volume 'Macintosh HD'.

In my opinion something went wrong after deleting various partitions with the Bootcamp Assistant/Disk Utility or in Windows.

Preparation:

Detach any external drive (especially your external Time Machine backup drive)
Restart to Internet Recovery Mode by pressing alt cmd R at startup.
The prerequisites are the latest firmware update installed, either ethernet or WLAN (WPA/WPA2) and a router with DHCP activated.
On a 50 Mbps-line it takes about 4 min (presenting a small animated globe) to boot into a recovery netboot image which usually is loaded from an apple/akamai server.

I recommend ethernet because it's more reliable. If you are restricted to WIFI and the boot process fails, just restart your Mac until you succeed booting.

Alternatively you may start from a bootable installer thumb drive (preferably Mavericks or Yosemite) or a thumb drive containing a full system (preferably Mavericks or Yosemite).

Now you may either repair CoreStorage or rebuild your Fusion Drive:

'Repair CoreStorage' (not recommended):

First i would try to check the volume 'Macintosh HD' with Disk Utility. If the volume is corrupted consider a reinstall of Mac OS X.
If the volume is ok quit Disk Utility
Open Terminal and enter diskutil unmountDisk /dev/LVIdentifier and both diskutil unmountDisk /dev/DiskContainingApple_CoreStorageIdentifier
In your case: first diskutil unmountDisk /dev/disk3 then diskutil unmountDisk /dev/disk0 and diskutil unmountDisk /dev/disk1
remove the EFI NO NAME partition with gpt remove -i IndexNumberOfEFINoName DiskIdentifier:
gpt remove -i 4 disk1
Remount the CoreStorage disks and then the Logical Volume:
In your case: first diskutil mountDisk /dev/disk0 and diskutil mountDisk /dev/disk1 and then diskutil mount /dev/disk3.

enter gpt -r -vvv show /dev/diskIdentfierOfApple_CoreStorage to get infos of your HDD CoreStorage disk.
In your case: gpt -r -vvv show /dev/disk1
It should look like this:

-bash-3.2# gpt -r -vvv show /dev/disk1
gpt show: /dev/disk1: mediasize=1000204886016; sectorsize=512;         blocks=1953525168
gpt show: /dev/disk1: PMBR at sector 0
gpt show: /dev/disk1: Pri GPT at sector 1
gpt show: /dev/disk1: GPT partition: type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, start=40, size=409600
gpt show: /dev/disk1: GPT partition: type=53746F72-6167-11AA-AA11-00306543ECAC, start=409640, size=1671210848
gpt show: /dev/disk1: GPT partition: type=426F6F74-0000-11AA-AA11-00306543ECAC, start=1671620488, size=1269760
gpt show: /dev/disk1: Sec GPT at sector 1953525167                               
     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    1671210848      2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
1671620488       1269760      3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
1672890248     280634887
1953525135            32        Sec GPT table
1953525167             1        Sec GPT header

The free space on your HDD has 280634887 blocks. Please calculate the biggest block number dividable through 8. That's 280634880 blocks (á 512 bytes) which equals 143685058560 B or ~143.7 GB. Add the size of your HDD CoreStorage Physical Volume (852666400768 B) The result is 143685058560 B + 852666400768 B = 996351459328 B
Resize your HDD CoreStorage physical volume with diskutil cs resizeDisk HDDPVUUID newsize
In your case: diskutil cs resizeDisk 93892BE8-2B7F-4ABD-A4C3-984495DCD98D 996351459328b
Calculate the maximal size of your CoreStorage Logical Volume in diskutil cs list: (size disk0s2) + (size disk1s2) In your case that's 120988852224 B + 996351459328 B = 1117340311552 B. That should be the size of your refreshed Logical Volume Group.
Resize your Logical Volume with diskutil cs resizeVolume LVUUID LVGSize-128 MB In your case that's diskutil cs resizeVolume D237FFDC-7DA4-41D7-AC13-4CC7E5E8C0A0 1117212311552b. If you get an error (There is not enough free space...) choose a smaller size like 1117148311552b.
Quit Terminal and open Disk Utility.
Check your expanded CoreStorage Volume for errors.
Quit Disk Utility, choose your CS volume as startup disk and restart your Mac

'Rebuild Fusion Drive' (recommended if you have a Time Machine backup)

Booted to Internet Recovery Mode open Utilities → Terminal in the menubar and enter:
diskutil cs list to get the CoreStorage listing.
Copy the Logical Volume UUID, it's the fifth listed.
Now delete the Logical Volume with diskutil cs deleteVolume LVUUID.
In your case: diskutil cs deleteVolume D237FFDC-7DA4-41D7-AC13-4CC7E5E8C0A0.
Copy the Logical Volume Group UUID, it's the first listed in the listing of diskutil cs list.
Then delete the Logical Volume Group with diskutil cs delete LVGUUID.
In your case: diskutil cs delete 1EFE58BC-3613-44C4-86EE-D816F3B66E3E
Enter exit and quit 'Terminal'
Open 'Disk Utility'. Enter 'Ignore' if you are asked to fix the drives.
Choose your SSD and partition it: 1 Partition Mac OS X Extended (Journaled), hit the Options button and choose GUID Partiton table and hit OK and Apply.
Please check that the size is ~121 GB

Example:
Choose your HDD and partition it: 1 Partition Mac OS X Extended (Journaled), hit the Options button and choose GUID Partiton table and hit OK and Apply.
Please check that the size is ~1 TB

Example:
Quit Disk Utility and open Terminal
Enter diskutil list

Example (your disk identifiers and sizes are different of course: Your volume SSD probably has the Identifier disk0s2 and the size 121 GB and your volume HDD probably has the Identifier disk1s2 and the size 1.0 TB):
Enter diskutil cs create "Name" IdentifierSSD IdentifierHDD
In your case probably diskutil cs create "Macintosh HD" disk0s2 disk1s2.

Copy the resulting LVGUUID

Example:
Enter diskutil cs CreateVolume LVGUUID jhfs+ "Macintosh HD" 100%.

Example:
Enter diskutil cs list
Check the size of your Logical Volume. It should have the size ~1.121 TB

Example:
Quit Terminal
Open 'Disk Utility' and check your newly created volume for errors
Quit 'Disk Utility'
Attach your external Time Machine backup drive or check this answer if you use NAS or another network share.
Open 'Restore from Time Machine Backup'
Choose the appropriate Time Machine backup and restore your system
Reboot to your restored system.
Unmount and detach your Time Machine backup drive
Open 'Terminal' and enter 'diskutil list'
Check if your 'Recovery HD' is listed.
If your 'Recovery HD' is missing, usually reinstalling your current system with the latest available system installer (e.g. 'Install OS X Mavericks (10.9.5)' if Mavericks is currently installed) will recreate it without loosing any data. AFAIK Recovery Partition Creator 3.8 will NOT create a Recovery HD on CoreStorage volumes.
After reinstalling the system with the latest available system installer open App Store and install the latest security fixes.

MacOS – Hard drive no longer accessible

I suspect Windows` chkdsk or another Microsoft tool to erroneously repairing the partition table of your device containing the EXFAT volume.

The result of sudo gpt -r -vv show /dev/disk2 of my 4 TB device created in a VM and formatted with Disk Utility in comparison looks like this:

gpt -r -vv show /dev/disk2
gpt show: /dev/disk2: mediasize=4000655081472; sectorsize=512; blocks=7813779456
gpt show: /dev/disk2: PMBR at sector 0
gpt show: /dev/disk2: Pri GPT at sector 1
gpt show: /dev/disk2: Sec GPT at sector 7813779455
       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        2008         
      411648  7813365760      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  7813777408        2015         
  7813779423          32         Sec GPT table
  7813779455           1         Sec GPT header

(Please consider that the mediasize, the blocks and some other values are different to yours, because i use a slightly smaller example disk here.)

The differences to your finding are obvious: the first partition of your disk isn't aligned properly to the 4096 byte sector size and is smaller. The second partition starts too early and is probably too big.

You probably have to fix both partition. This will only work if you partitioned the drive with Disk Utility in Mac OS X.

Preparation:

Backup your Mac and then detach all external drives.
Download and install wxHexEditor. Enable the root user and log-in as root.

Hint: While working with wxHexEditor don't use copy and paste. Enter everything manually! You might accidentally write directly to your disk.

Where does the EXFAT partition start and end?

First you have to determine the starting block of your EXFAT volume:

Open Terminal and enter diskutil list. Get the Identifier of the disk to repair.
Open Calculator. Open wxHexEditor. Check that you work in read-only mode ("Options" -> "File mode" -> "Read only"). In the menubar go to "Devices" -> "Open disk device" -> choose the appropriate diskNumber.
Hit the search button (marked with the red circle in the picture below) and enter EXFAT (exactly like in the picture). Please try to arrange the wxHexEditor window like in the examples below with straight red lines.
My EXFAT entry (see picture below) is at offset 210763776. Now you can calculate the start block of the volume with: OffsetBytes/512 = NewStartBlockEXFAT. The start block in my example is 411648.

If you get a significantly smaller starting block (=<409639) stop here, because you probably didn't partition your disk with Disk Utility previously.
The ending block of the EXFAT volume can't be determined easily; we have to guess it (somehow). The problem is the variable gap between partition 2 and the second GPT table. In your case it has 1679 blocks, in my example it has 2015 blocks.
- Method 1 (maximal size in the "unallocated space" between the block containing the EXFAT string and the second GPT table):
  The maximal volume size is StartBlock2ndGPT-NewStartBlockEXFAT. The size has to be dividable through 8. Reduce the size until you get a size dividable through 8. Example: In my case the maximal size would be 7813779423 (StartBlock2ndGPT) - 411648 (StartBlockEXFAT) = 7813367775 (which isn't dividable through 8). The biggest size dividable through 8 is 7813367768.
- Method 2 (minimum size containing all occupied blocks between the block containing the EXFAT string and the second GPT table):
  You might jump to sector 7814037135 (the first block of your secondary GPT table) with the arrow button (the second button left of the search button) and search backwards and match case disabled with "Find some bytes" to get the last occupied sector. This may take a while. Make a note of your finding (if you have one in a reasonable timeframe). Divide the offset through 512 to get the sector number. The sector number should be smaller than 7814037135. Now calculate the provisional minimal size of your volume: StartBlockEXFAT+1-LastOccupiedSector. The result must be dividable through 8. To get size add blocks until the size is dividable through 8.
  You may stop the process after 5 minutes without result because then the last occupied block number is probably smaller than 7807917625 assuming the process searches 10 MByte/s (the last ~3 GB of your disk). Use Method 1 then.
Both results probably lead to a wrong size of the EXFAT volume, but this should be repairable. It's more important to get the proper start block. Additionally method 2 may deliver incorrect results if the disk has been completely filled with data previously using a different partition layout and hasn't been zero-filled afterwards.

Restoring the "old" GPT

Here i assume the identifier of the disk containing the EXFAT volume is disk0.

First you have to unmount the disk
```
diskutil umountDisk disk0
```

Check the partition layout, then remove the two partitions:

gpt -r -vv show /dev/disk0

gpt remove -i 2 disk0
gpt remove -i 1 disk0

Since the (Apple-)EFI usually has a fixed size we can easily add it with:

gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0

With the start block of the EXFAT partition and Size (the volume size found with Method 1 or 2 above) we can also add it:
```
gpt add -b NewStartBlockEXFAT -i 2 -s Size -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk0
```
Remount disk0 with:
```
diskutil mountDisk disk0
```
Quit Terminal, Calculator and wxHexEdit and open Disk Utility.
Check your EXFAT volume for errors.

If you run into problems (e.g you can't find the proper EXFAT volume size), have doubts or questions immediately stop and contact me with a comment @klanomath!

Best Answer

Related Solutions

I think I messed up the Fusion Drive on the 1TB iMac (with BootCamp)

MacOS – Hard drive no longer accessible

Related Question