Yes, I already tried this one: Partition type suddenly FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, drive unmountable
My main partition is in this ffffffff-ffff-ffff-ffff-ffffffffffff format or whatever it is. And I need all the Data on this disk3s2.
Here is a picture of my Disk, a couple of hours ago:
- disk3s1: EFI
- disk3s2: Macintosh (ffffffff-ffff-ffff-ffff-ffffffffffff partition with all of my Data on, I want this Data!)
- disk3s3: Apple_HFS Recovery HD
- disk3s4: New (Another useless Partition, its empty.)
- disk3s5: Apple_Boot Recovery HD
What I did to try to repair my disk:
diskutil umountDisk /dev/disk3
sudo gpt destroy /dev/disk3
diskutil umountDisk /dev/disk3
sudo gpt create -f /dev/disk3
sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk3
So whenever I try to add another partition, I get this Error:
gpt add: /dev/disk3: error: no space available on device
Please help if you have any suggestions, I lost a lot of important Data!!!
Update:
diskutil list
leads to this:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *120.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage SSD 119.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: SSD +118.8 GB disk1
Logical Volume on disk0s2
...deleted it...
Unencrypted
/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *320.1 GB disk3
1: EFI EFI 209.7 MB disk3s1
and
sudo gpt -r show disk3
leads to this:
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 624732774
625142414 32 Sec GPT table
625142446 1 Sec GPT header
Best Answer
The volumes could be recovered in a TeamViewer session by searching for special strings similar to the method outlined in this answer: My SATA hardrive was ejected, and is unable to be remounted due to issues.
The assumptions made:
diskutil list
screenshot of the question - both vanished after destroying the old partition table withsudo gpt destroy /dev/disk3
)To get the starting block of the first Recovery HD enter (which has to be in the 271 GiB - 274 GiB or ~291 GB - ~295 GB range of the disk)
(hexdump uses GibiBytes instead of GigaBytes!) which revealed:
0x447f801400 is Byte 294196876288 (or block 574603274) of the disk. Since the string HFSJ resides in the third block of a volume, the Recovery HD starts with block 574603272.
The typical output if the previous volume wasn't a FileVault but a normal HFSJ volume would look like this instead:
The first and second byte number show a difference of 0xc00-0x1400=0x800 or 2048 Bytes because the preceding OS X volume has an alternative volume header in the second last block while FileVault volumes don't have one.
The Recovery HD has a fixed size of 1269536 blocks and it can be added with gpt to the partition table.
Now verify the volume with
If the partition boundaries and the volume are/is OK you'll get an exit code 0.
In the unallocated disk space between EFI and Recovery HD a CoreStorage partition was added:
The FileVault password window popped up and the password was entered - so it was added successful probably.
The disk and the volume were verified with:
which both exited with code 0 and all was fine.
Later the FileVault volume was extended to the full size of the disk with: