8 votes

Comment réparer une partition de disque dur Mac affichant le nom FDisk_partition_scheme ?

Ma situation semble très similaire à Comment réparer un disque dur GUID corrompu en MBR ? mais avec suffisamment de différences pour que je ne sois pas en mesure d'élaborer une solution fiable.

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 disque a été configuré avec une seule partition. Le disque n'était pas amorçable et n'avait pas de système installé, je suppose donc qu'il n'avait pas non plus de partition de récupération. Je ne peux pas dire avec certitude qu'il n'a jamais eu de système installé, mais je ne le pense pas. Il n'a pas été utilisé avec Bootcamp ou sur un ordinateur autre qu'un Mac.

Le disque a fonctionné normalement pendant un certain temps mais n'a pas été reconnu récemment. Lors de l'examen avec l'utilitaire de disque, il apparaît comme ayant un type de partition de Schéma de partition de disque dur . Je suis sûr qu'à l'origine c'était le défaut typique de Carte de partition GUID formaté comme suit OS X étendu (journalisé) .

Je ne peux pas penser à une utilisation ou un événement spécifique qui aurait pu causer ce changement.

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

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.

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

Start of drive in wxHexEditor

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 cherché en commençant par le début du disque et j'ai trouvé la première occurrence à l'offset 314598400.

Cependant, si je continue à chercher les occurrences de HFSJ, j'en trouve beaucoup qui se ressemblent exactement et avec beaucoup d'espace zéro autour d'elles, comme la première. Ceux-ci commencent à 360424448 et sont espacés de 32768. Par exemple, aux décalages 360424448 360457216 360489984 360522752 360555520

J'ai utilisé le Trouver tout recherche dans wxHexEditor et s'est arrêté après quelques minutes. Il en avait trouvé quelques milliers à ce moment-là. Je ne suis pas sûr de savoir ce qu'il faut en faire, le cas échéant.

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

Voici des captures d'écran de la première partition HFSJ et de la partition système EFI. J'ai ajouté une capture d'écran de l'offset 8192 en fonction des commentaires.

First HFSJ partition, EFI partition at end, and offset 8192.

Merci pour toute aide.

11voto

klanomath Points 63400

Veuillez essayer ce qui suit :

  • Obtenez l'identifiant de disque de votre disque externe de 3 To.

    diskutil list

    Ci-dessous, je suppose que l'identifiant du disque est disk6

  • démonter le disque :

    diskutil umountDisk disk6
  • Écraser 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 du 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 continuer avec 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 avez un disque et un contrôleur de disque qui indiquent une taille de bloc logique de 4096 octets. Veuillez vous arrêter ici et ajouter un commentaire.

  • D'abord reconstruire 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 : soit un volume de 200 MiB. ou un avec 300 MiB. Ici, il est évident que votre disque contient un EFI de 300 MiB et probablement 4096 octets d'espace disque non alloué : (314598400-1024)/512=614448 (=bloc de départ volume principal) 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. Puisque 5859918680 est divisible par 8 (4096 taille de bloc physique/512 taille de bloc logique), c'est une bonne estimation de la taille du volume.

    La meilleure estimation est finalement :

    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
  • Il est probable que votre volume perdu soit monté maintenant. Vérifiez le volume avec :

    diskutil verifyVolume disk6s2

    Si nécessaire, essayez de réparer le volume.

    diskutil repairVolume disk6s2

Comme vous avez déplacé le disque "corrompu" dans un boîtier et un contrôleur de disque différents, 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 devriez 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
  • D'abord reconstruire 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

En se basant sur la partie 4096b, cela se "retranscrit" après l'installation du disque dans un cas de taille de bloc logique 512b en :

  • Créez un nouveau gpt :

    sudo gpt create /dev/disk6
  • D'abord reconstruire 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 ! Puisque l'EFI est en fait "vide" et que les 262144 blocs non alloués ne contiennent que des zéros, la "première et quelque peu fausse" réponse n'affecte pas l'opérabilité du volume.

2voto

David Anderson Points 30783

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

La dernière LBA utilisable se trouve dans l'en-tête GPT. Elle se trouve à 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 secours) commence au bloc suivant. La valeur est

(732566640 + 1) * 4096 = 3000592961536 bytes.  

En utilisant ceci 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é à l'adresse 3000592961568, est le suivant

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é à 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 utilisez 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.

0voto

becker Points 101

Vous avez fini par le récupérer ? J'ai le même problème après avoir essayé d'utiliser MacDrive pour transférer de gros fichiers sur un Win10 via USB, il s'est figé et je me suis retrouvé avec mon fidèle disque dur Mac endommagé exactement comme le vôtre avec la partition 0xEE.

UPDATE : J'ai résolu mon problème avec des étapes plus simples il y a un outil testDisk qui liste le début, la fin et la taille des partitions sur le disque dur, puis le pdisk (l'option c) m'a permis d'entrer ces données et soudainement je pouvais lire mon disque dur complètement comme avant je reçois un avertissement mais toutes les données sont de retour.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X