Comment réparer la partition du disque dur Mac en tant que Fdsik_partition_scheme

Ma situation semble très similaire à la façon de réparer le disque dur GUID corrompu en MBR mais avec suffisamment de différences que je n'ai pas été en mesure de mettre en place une solution sûre.

J'ai un disque Toshiba de 3 To dans un boîtier USB utilisé sur un Mac avec OS X El Capitain 10.11.3.

Le lecteur a été configuré avec une seule partition. Le lecteur n'était pas amorçable et n'avait pas de système installé, donc je suppose qu'il n'aurait pas non plus de partition de récupération. Je ne peux pas dire avec certitude qu'aucun système n'a jamais été installé, mais je ne le pense pas. Il n'a pas été utilisé avec Bootcamp ou sur un ordinateur non Mac.

Le lecteur a fonctionné normalement pendant une longue période, mais n'a pas été reconnu récemment. En enquêtant avec l'utilitaire de disque, il apparaît comme ayant un type de partition FDisk_partition_scheme . Je suis sûr que c'était à l'origine la valeur par défaut typique de la carte de partition GUID au format OS X Extended (journalisé) .

Je ne peux penser à aucune utilisation ou événement spécifique qui aurait pu provoquer le changement.

Voici les informations que j'ai recueillies sur le disque.

liste diskutil / 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 récupérer / 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.

Voici une capture d'écran de la première partie du lecteur dans wxHexEditor. L'EFI PART commence à 4096.

J'ai commencé à chercher la chaîne HFSJ à partir d'un décalage de 409642, comme suggéré dans d'autres réponses, mais je ne l'ai pas trouvée près de là. J'ai donc recherché à partir du début du lecteur et trouvé la première occurrence au décalage 314598400.

Cependant, si je continue à rechercher des occurrences de HFSJ, j'en trouve beaucoup qui se ressemblent exactement et avec beaucoup d'espace nul autour d'eux, comme le premier. Ceux-ci commencent à 360424448 et sont espacés de 32768. Par exemple, aux décalages 360424448 360457216 360489984 360522752 360555520

J'ai utilisé la recherche Find All dans wxHexEditor et je me suis arrêté après quelques minutes. Il en avait trouvé quelques milliers à ce moment-là. Je ne sais pas quoi faire de ceux-ci, le cas échéant.

J'ai également pu trouver une section intitulée Partition système EFI à l'offset 3000592961536. Cela montre également le nom du lecteur, "Rosie".

Voici des captures d'écran de la première partition HFSJ et de la partition système EFI. Ajout d'une capture d'écran du décalage 8192 en fonction des commentaires.

Merci pour toute aide.

— Doug Smith
source

Si apparaît votre disque avait une taille de bloc de 4096 octets et a maintenant une taille de 512 octets. Étant donné que la taille du bloc n'est pas stockée sur le disque lui-même, ma question serait la suivante: avez-vous modifié le matériel d'une manière ou d'une autre? De plus, si la taille du bloc était de 4096 octets, vous devriez pouvoir lire les anciennes entrées de la table GPT à partir de 8192 octets. Jusqu'à présent, vous n'avez publié l'en-tête GPT qu'à partir de 4096 octets. Le vidage hexadécimal peut être reconverti aux valeurs décimales correctes en utilisant les informations fournies ici .

— David Anderson

@DavidAnderson, le matériel a changé en ce que le lecteur est dans un boîtier USB différent. Je pourrais obtenir le boîtier d'origine si cela peut aider.

— Doug Smith

@DavidAnderson J'ai changé la capture d'écran pour en ajouter une pour l'offset 8192. Il y montre une partition système EFI .

— Doug Smith

@klanomath Oui, votre réponse liée était correcte. J'ai mélangé bloc et décalage. Cependant, il n'y a que des zéros autour du décalage 209736704. J'ai également essayé de diviser cela par 8 (26217088) au cas où il y aurait un problème de taille de bloc 4096. Cela me met dans beaucoup de données, mais aucune chaîne HFSJ en vue.

— Doug Smith

@klanomath, j'avais commencé votre processus. Ma tentative d'écraser les 40 premiers blocs n'a pas vraiment écrit de données:0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)

— Doug Smith

Réponses:

S'il vous plaît essayez ce qui suit:

Obtenez l'identifiant de disque de votre lecteur externe de 3 To
```
diskutil list
```
Ci-dessous, je suppose que l'identifiant du disque est disk6
démonter le disque:
```
diskutil umountDisk disk6
```

Remplacez les 40 premiers blocs:

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

Créez un nouveau gpt:
```
sudo gpt create /dev/disk6
```
Vérifiez les informations du disque avec:
```
diskutil info /dev/disk6
```
Assurez-vous que la taille du bloc de périphérique est toujours de 512 octets

Vous pouvez également utiliser
```
sudo gpt -r show /dev/disk6
```
Si le gpt montre:
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2          32         Pri GPT table
```
vous disposez d'un disque et d'un contrôleur de disque qui indiquent une taille de bloc logique de 512 octets. Veuillez passer à l'étape suivante.

Si le gpt montre:
```
   start        size  index  contents
       0           1         PMBR
       1           1         Pri GPT header
       2           4         Pri GPT table
```
vous disposez d'un disque et d'un contrôleur de disque qui indiquent une taille de bloc logique de 4096 octets. Veuillez vous arrêter ici et ajouter un commentaire.
Reconstruisez d'abord l'entrée EFI avec:
```
sudo gpt add -b 40 -i 1 -s 614400 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk6
```
En fonction de la taille du disque et de la version du système, des volumes EFI de tailles différentes sont construits s'ils sont partitionnés avec l'Utilitaire de disque: l'un avec la taille 200 Mio ou l' autre avec 300 Mio. Ici, il est évident que votre disque contient un EFI de 300 Mo et probablement 4096 octets d'espace disque non alloué: (314598400-1024) / 512 = 614448 (= volume principal du bloc de démarrage) 614448-40-8 = 614400 (= taille de l'EFI)
Reconstruisez votre volume principal avec:
```
sudo gpt add -b 614448 -i 2 -s SizeOfVolume1 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
La taille du volume principal peut être déterminée par la première entrée (corrompue et ancienne) de la deuxième table GPT: (3000592961536/512) = 5860533128 est son numéro de bloc. Ensuite, la taille est calculée par 5860533128-614448 = 5859918680 blocs. Étant donné que 5859918680 est divisible par 8 (taille de bloc physique 4096 / taille de bloc logique 512), c'est une bonne estimation de la taille du volume.

La meilleure supposition est enfin:
```
sudo gpt add -b 614448 -i 2 -s 5859918680 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
La deuxième meilleure supposition est:
```
sudo gpt add -b 614448 -i 2 -s 5859918672 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk6
```
Votre volume perdu est probablement monté maintenant. Vérifiez le volume avec:
```
diskutil verifyVolume disk6s2
```
Si nécessaire, essayez de réparer le volume.
```
diskutil repairVolume disk6s2
```

Depuis que vous avez déplacé le disque «corrompu» vers un autre boîtier et contrôleur de disque, la taille du bloc logique a été modifiée. L'ancienne carte de partition est probablement basée sur une taille de bloc logique de 4096 octets.

Pour récupérer la carte de partition dans l'ancien cas (4096b), vous auriez dû entrer ce qui suit pour restaurer le GPT (basé sur la réponse de David Anderson):

Créez un nouveau gpt:
```
sudo gpt create /dev/disk6
```

Reconstruisez d'abord l'entrée EFI avec:

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

Reconstruisez votre volume principal avec:

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

la carte de partition finale ressemble à ceci:

 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

Sur la base de la partie 4096b, cette "retraduit" après l'installation du disque dans un cas de taille de bloc logique 512b pour:

Créez un nouveau gpt:
```
sudo gpt create /dev/disk6
```

Reconstruisez d'abord l'entrée EFI avec:

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

Reconstruisez votre volume principal avec:

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

Cela diffère de la première partie (acceptée) de ma réponse, mais c'est la bonne! Étant donné que l'EFI est réellement "vide" et que les blocs 262144 non alloués contiennent uniquement des zéros, la réponse "première et en quelque sorte erronée" n'affecte pas l'opérabilité du volume.

— klanomath
source

Ce n'est pas une réponse, mais plutôt un exemple de la façon d'extraire les informations de partition GPT des données que vous avez présentées. Les entrées de partition GPT secondaires (de sauvegarde) ont été utilisées car vous n'avez pas publié le contenu des entrées de partition GPT principales. Le document " GUID Partition Table " a été utilisé pour interpréter les données.

Le dernier LBA utilisable se trouve dans l'en-tête GPT. Cela se produit à l'adresse 8244. La valeur est

70 14 aa 2b 00 00 00 00 little endian = 0x2baa1470 = 732566640 @ 4096 bytes/block.

Le début des entrées GPT secondaires (de sauvegarde) commence au bloc suivant. La valeur est

(732566640 + 1) * 4096 = 3000592961536 bytes.

En utilisant cela comme début de l'entrée de la table de partition EFI, j'obtiens les valeurs suivantes. Le début de la partition EFI, trouvée à l'adresse 3000592961568, est

06 00 00 00 00 00 00 00 little endian = 0x6 = 6 @ 4096 bytes/block.

La fin de la partition EFI, trouvée à l'adresse 3000592961576, est

05 2c 01 00 00 00 00 00 little endian = 0x12c05 = 76805 @ 4096 bytes/block.

Ce qui donne une taille de partition de

76805 - 6 + 1 = 76800 @ 4096 bytes/block.

Le début de la partition HFS, trouvée à l'adresse 3000592961696, est

06 2c 01 00 00 00 00 00 little endian = 0x12c06 = 76806 @ 4096 bytes/block.

La fin de la partition HFS, trouvée à l'adresse 3000592961704, est

70 94 a9 2b 00 00 00 00 little endian = 0x2ba99470 = 732533872 @ 4096 bytes/block.

Ce qui donne une taille de partition de

732533872 - 76806 + 1 = 732457067 @ 4096 bytes / block.

Si vous prévoyez d'utiliser une taille de bloc de 512 octets, les résultats ci-dessus devront être multipliés par une valeur de 8 pour être convertis en 512 octets / bloc.

— David Anderson
source

+1 Nous obtenons une taille et un bloc de démarrage identiques pour l'EFI et un bloc de démarrage identique mais une taille différente du volume principal.

— klanomath