Je tente de reconstruire une partition Mac pour un disque dur externe Hitachi de 3 To qui n'a pas réussi à se monter récemment. Mis à part une taille de table GPT inattendue que je montrerai plus tard, ce problème de disque semble similaire à Comment réparer la partition de disque dur Mac qui s'affiche comme un schéma de partition Fdisk.
Voici des antécédents et des infos sur le disque que j'ai rassemblés :
Comme l'enclos du disque semblait avoir une connexion lâche, on lui a donné un nouvel enclos. Par précaution et pour avoir une copie de travail, dd a été utilisé pour créer une image de l'intégralité du disque dur de 3 To. Pour toutes les étapes nécessitant un périphérique en entrée, j'attache l'image en utilisant hdiutil attach -nomount path/to/file.dmg.
Le disque était initialement formaté avec une seule partition en utilisant Mac OS X Snow Leopard. J'ai trouvé le GUID du type de partition HFS+ en parcourant les données dans l'éditeur hexadécimal, Hex Fiend : 53746F72-6167-11AA-AA11-00306543ECAC (Conteneur de volume de fichier HFS+ Core Storage d'Apple FileVault). Cela a été suivi par la 1ère entrée de partition EFI à l'offset 4096 : 
La 1ère partition système EFI se trouve à l'offset 8192 : 
J'ai tenté d'extraire les informations GPT/EFI et de partition HFS de l'image ci-dessus :
06 00 00 00 00 00 00 00 = 6 (début de l'EFI).
05 C8 00 00 00 00 00 00 = 51205 (fin de l'EFI).
06 C8 00 00 00 00 00 00 = 51206 (début de HFS).
6F 94 A9 2B 00 00 00 00 = 732533871 (fin de HFS).
La partition système EFI secondaire à l'offset 3000592957440 semblait contenir les mêmes valeurs de début et de fin, et la 2ème entrée de partition EFI était à l'offset 3000592973824.
La 1ère entrée HFSJ a été trouvée à l'offset 209740800 : 
Le total des octets donnés par diskutil info est 3000592982016 : 
Si la taille du volume principal HFS est de 732533871 - 51205 = 732482666 blocs, alors la taille de bloc logique devrait être de 4096 (ce qui donne un total de # blocs sur le disque = 732566646). Bien qu'une taille de bloc de 512 octets soit donnée par diskutil info (dans l'image ci-dessus).
Malheureusement, gdisk n'a pas pu lire les données GPT :
GPT fdisk (gdisk) version 1.0.4
Analyse de la table de partitions :
MBR : protecteur
BSD : non présent
APM : non présent
GPT : non présentVoici ce que j'ai utilisé pour essayer de reconstruire la table de partition GPT (suivant Comment réparer la partition de disque dur Mac qui s'affiche comme un schéma de partition Fdisk) :
sudo dd if=/dev/zero of=/dev/disk2 bs=512 count=40
sudo gpt create /dev/disk2Ensuite, j'ai exécuté sudo gpt -r show /dev/disk2, ce qui a donné une taille inattendue de table GPT :
start size index contents
0 1 PMBR
1 1 En-tête GPT Pri
2 18 Table GPT Pri
20 1
21 18 Table GPT Sec
39 1 En-tête GPT SecAprès les résultats de l'utilitaire GPT ci-dessus, je n'étais pas sûr de la taille de bloc logique à utiliser pour reconstruire les tables de partition EFI et HFS.
Merci pour toute aide !
Mise à jour du 31/01/2020
J'ai terminé l'utilisation de rsync pour faire une autre copie d'image de disque de 3 To (j'ai continué de garder l'image de disque originale créée via dd comme sauvegarde).
Je pense avoir localisé la 3ème partition à l'offset de 3000458738688 octets (c'était la 1ère chaîne de données suivant la fin du volume principal HFS). Elle semble se terminer soit à l'offset 3000582143352 ou 3000582143360 (tout avis sur ceci est apprécié) : 
Contrairement à EFI/GPT et HFS, il ne semblait pas y avoir d'adresses de début ou de fin dans les en-têtes que je pouvais extraire pour cette 3ème partition de démarrage. Notez que j'ai ajouté des images de partitions plus importantes pour montrer ceci. Je vais donc essayer d'utiliser les offsets en bytes estimés ci-dessus (convertis en secteurs/blocs) comme entrée pour la 3ème étape gpt add.
Merci encore pour tout commentaire !
