10.12 Sierra Disque dur externe crypté reformaté

Il y a eu une double tentative de réparation qui n'a pas réussi. On ne peut rien faire de plus par mon procédé concernant cette partition CoreStorage.

Mais ce dont on a la certitude absolue > c'est que les 3 partitions recrées occupent au bloc près leurs emplacements d'origine.

Passe la commande :
Bloc de code:
sudo gpt show disk5

  • poste le tableau des blocs.
 
Je te remercie de la peine que tu donne sur mon problème. Ca fout d'autant plus les boules si les partitions sont bien là à attendre sagement.

Bloc de code:
   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  2725095696      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  2725505336      262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  2725767480  3134765651      
  5860533131          32         Sec GPT table
  5860533163           1         Sec GPT header

J'ai acheté deux logiciels : Stellar Phoenix Recovery et DiskDrill (trouvant que le premier était nul) et pourtant je suis pas un petit richou... c'est vraiment parce que je tenais au contenu
 
Il y a davantage de chances de récupérer la partition médiane (non touchée par la "zéroïsation").

Mais je préférerais m'en occuper demain > car il se fait déjà bien tard et ces opérations réclament une entière précision d'esprit.
 
Ok tu en as déjà fait beaucoup.

D'après ce que je comprend DiskDrill ne fait pas mieux voire pire que ce que tu me propose ? C'est donc inutile de passer par lui ? Je vais à tout hasard scanner un des nouvelles partitions qu'il m'a trouvé pour voir si en bas niveau il me trouve des données..

Je vais laisser tourner toute la nuit.

Merci encore.

Je serais à mon poste toute la journée dés 9h
 
Le problème > c'est que les écritures des blocs de partitions CoreStorage chiffrées sont... chiffrées, justement.

À demain.
 
Voici la bande de blocs libres qui restent sur le disque > entre le pied de la partition « booter » n°3 et la sauvegarde de la GPT de fin de disque -->
Bloc de code:
  2725767480  3134765651

  • 2725767480 est le n° du bloc commençant cette bande de blocs libres ; 3134765651 l'extension de cet espace = 1605 Go.

Afin de poursuivre la recréation des partitions originelles sur ces blocs > nous possédons le tableau initial de la GPT qui va servir de paradigme pour cet espace spécifique du disque -->
Bloc de code:
  2725767480       36295   

  2725803775  1181378496      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC

  3907182271      225845   

  3907408116      262144      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC

  3907670260  1952862871

  • cette mention :
Bloc de code:
  2725767480       36295

  • désigne un tampon de blocs libres qui existait entre le pied de la partition « booter » n°3 & le départ de la partition CoreStorage4. Taille du tampon : 36295 blocs = 18,58 Mo. Il faut respecter ce tampon.
  • cette mention :
Bloc de code:
  2725803775  1181378496      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC

  • décrit la partition CoreStorage4. On sait absolument que le bloc 0 de cette partition est le n°2725803775 > qui a valeur de super-bloc pour le système de fichiers jhfs+ inscrit dans la partition. Ce super-bloc et ceux qui suivent doivent être intouchés par l'effacement antérieur. L'UUID affecté à cette partition est ridicule : il s'agit du déterminant de type : "Apple_HFS" alors qu'il faut à toute force celui du type : "Apple_CoreStorage". Il n'y a pas eu qu'un début d'effacement du disque > mais aussi une corruption de la GPT dans Linux.
  • cette mention encore :
Bloc de code:
  3907408116      262144      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC

  • décrit une partition d'une extension de 262144 blocs = 134,2 Mo. On sait donc qu'on a affaire nécessairement ici à la partition du second « booter » de la partition CoreStorage4 > càd. à la partition n°5 exactement délimitée. Avec toujours un ridicule UUID de type : "Apple_HFS" au lieu de : "Apple_Boot".
 
  • J’aime
Réactions: Mc kintosh
Le problème spécifique à la recréation de cette paire de partition consiste à l'assignation du bloc de pied de la partition CoreStorage. En effet > une bande de blocs intercalaires -->
Bloc de code:
  3907182271      225845

  • de 225845 blocs = 115,6 Mo --> est signalée entre la partition CoreStorage4 et sa partition « booter » n°5. Je ne sais pas quoi faire de cette bande de blocs libres > étant donné - théoriquement parlant - qu'il ne doit exister aucun espace libre (ne serait-ce que d'un seul bloc) --> entre le pied d'une partition de type "Apple_CoreStorage" et sa partition « booter » de type "Apple_Boot".
  • je pense pouvoir interpréter la génération de cette bande de blocs libres ainsi : après le début de "zéroïsation" du disque et la corruption de la table GPT > une tentative de réparation de la table GPT a dû intervenir via l'Utilitaire de disque (le mal nommé). Or le type de la partition du « booter » avait été corrompu par sa conversion au type "Apple_HFS". `De même que le type de la partition : "Apple_CoreStorage" du dessus > par sa conversion au type : "Apple_HFS". Lorsqu'une opération de réparation du disque est lancée > et que des partitions de type "Apple_HFS" existent sur le disque > une réparation non des systèmes de fichiers > mais des conditions d'amorçage de ces partitions --> se trouve effectuée. L'accollement d'alors des 2 partitions faussement assignées à un type : "Apple_HFS" a dû se trouver estimé problématique > ce qui fait que la réparation du disque aurait décidé de créer un tampon intercalaire de 225845 blocs (= 115 Mo). Ce qui était un faux-problème > puisque les 2 partitions n'étaient pas réellement de type : "Apple_HFS" > mais de type : "Apple_CoreStorage" & de type : "Apple_Boot".
  • je conclus de cette analyse théorique qu'il y a eu un rétrécissement indû de la partition CoreStorage des 225845 blocs du faux tampon > et que ces blocs doivent à toute force se trouver réintégrés à l'extension d'une partition de type "Apple_CoreStorage" qu'absolument aucun bloc ne doit séparer de la partition de type "Apple_Boot" de son « booter ». Je pense par là avoir théoriquement démontré par nécessité logique que le bloc 0 de la partition CoreStorage4 doit être le n°2725803775 > et que l'extension de blocs de cette partition doit être rigoureusement de 11811604341 blocs = 604,98 Go. Càd. venir toucher le bloc n°3907408116 dont on sait qu'il est le bloc 0 de la partition du « booter ». Il s'ensuit qu'on connaît au bloc près l'extension des 2 partitions4 & 5 à recréer > leur bloc 0 d'origine (super-bloc) > leurs rangs et leurs types logiques.

=> tu n'auras qu'à faire signe lorsque tu seras disponible pour la recréation de cette paire de partition centrales.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Mc kintosh
Bonjour,

De retour pour la bataille de la récupération du disque dur.

Avoir autant d'érudition sur ce bas niveau, je te cacherai pas que ça me fait bien penser à Space Cowboy... ;°)

Que Linux est touché en quelques centaines de megas les trois partitions est juste hallucinant et navrant.
 
Passe une commande :
Bloc de code:
diskutil list

  • et poste le tableau des disques --> que je sois sûr de l'index de disque du DDE.
 
Bloc de code:
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk5
   1:                        EFI EFI                     209.7 MB   disk5s1
   2:          Apple_CoreStorage Sans titre              1.4 TB     disk5s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk5s3
 
C'est donc le disk5. Repasse aussi la commande :
Bloc de code:
sudo gpt show disk5

  • et poste le tableau des blocs --> que je me remette dans le bain...
 
Bloc de code:
 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  2725095696      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  2725505336      262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  2725767480  3134765651        
  5860533131          32         Sec GPT table
  5860533163           1         Sec GPT header
 
Passe les commandes :
Bloc de code:
diskutil umountDisk force disk5
sudo gpt add -b 2725803775 -s 1181604341 -t 53746F72-6167-11AA-AA11-00306543ECAC -i 4 /dev/disk5

  • la 1ère démonte le disque
  • la 2è crée le descripteur d'une partition de rang4 > dans le type "Apple_CoreStorage" > avec pour bloc 0 le n° 2725803775 > et une extension de 1181604341 blocs = 604.98 Go

Poste le retour de la 2è commande.
 
Bloc de code:
/dev/disk5s4 added

Bloc de code:
 sudo gpt show disk5
       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  2725095696      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  2725505336      262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  2725767480       36295        
  2725803775  1181604341      4  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  3907408116  1953125015        
  5860533131          32         Sec GPT table
  5860533163           1         Sec GPT header
 
Alors on enchaîne sur la recréation de la partition du « booter ». Passe les 2 commandes :
Bloc de code:
diskutil umountDisk force disk5
sudo gpt add -b 3907408116 -s 262144 --t 426F6F74-0000-11AA-AA11-00306543ECAC -i 5 /dev/disk5

  • la 1ère démonte à nouveau le disque
  • la 2è crée le descripteur d'une partition de rang5 > dans le type : "Apple_Boot" > avec pour bloc 0 le n° 3907408116 > et une extension de 262144 blocs = 134,2 Mo

Poste le retour de la 2è commande + le retour d'un nouveau :
Bloc de code:
sudo gpt show disk5
 
Bloc de code:
gpt: illegal option -- -
usage: gpt add [-b lba] [-i index] [-s lba] [-t uuid] device ...

Problème dans la ligne de commande ?
 
Pardon : lapsus calami --> j'ai mis un double tiret -- au lieu d'un tiret simple - devant l'option t de (type). Voici la 2è commande éditée -->
Bloc de code:
sudo gpt add -b 3907408116 -s 262144 -t 426F6F74-0000-11AA-AA11-00306543ECAC -i 5 /dev/disk5
 
Bloc de code:
/dev/disk5s5 added

Bloc de code:
sudo gpt show disk5
       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  2725095696      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  2725505336      262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  2725767480       36295        
  2725803775  1181604341      4  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  3907408116      262144      5  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  3907670260  1952862871        
  5860533131          32         Sec GPT table
  5860533163           1         Sec GPT header
 
Ça s'étoffe bigrement ce disque ! --> en fait > il grouille de partitions :hilarious:

Passe la commande :
Bloc de code:
diskutil repairDisk disk5

  • commande de réparation multi-forme du disque > dont réparation de l'architecture CoreStorage & du « booter »

Poste l'affichage retourné.
 
Pourtant je l'ai acheté, j'ai trois (ou quatre) partition que j'ai nommé RAID + nom du disque que je sauvegarde et j'y ai pas touché depuis

Bloc de code:
diskutil repairDisk disk5
Repairing the partition map might erase disk5s1, proceed? (y/N) y
Started partition map repair on disk5
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking booter partition disk5s3
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Boot OS X appears to be OK
File system check exit code is 0
Checking booter partition disk5s5
Updating boot support partitions for the volume as required
Problems were encountered during repair of the partition map
Error: -69846: Unrecognized file system