10.12 Sierra Disque dur externe crypté reformaté

Je ne conçois pas cette erreur. Passe la commande :
Bloc de code:
sudo gpt show disk4
  • poste le tableau de la distribution des blocs
 
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  5860123491        
  5860533131          32         Sec GPT table
  5860533163           1         Sec GPT header
 
Il y a bien 5860123491 blocs libres = 3000.38 Go. Pourquoi une partition d'une extension de 2725095736 blocs = 1395.24 Go ne pourrait-elle pas être créée sur une partie de ces blocs ?

Passe la commande :
Bloc de code:
sudo gpt add -b 409600 -s 2725095736 -t 53746F72-6167-11AA-AA11-00306543ECAC disk4

  • j'ai supprimé la commande de démontage préalable + le n° de rang de la partition

Poste le retour.
 
Voyons s'il est possible de créer en-dessous la partition du « booter ». Passe la commande :
Bloc de code:
sudo gpt add -b 2725505336 -s 262144 -t 426F6F74-0000-11AA-AA11-00306543ECAC -i 3 disk4

  • la commande crée une partition de type "Apple_Boot" > à partir du bloc n°2725505336 > sur une extension de 262144 blocs (134 Mo) > au rang3

Poste le retour.
 
Partition créée.

Profites-en pour passer la commande :
Bloc de code:
diskutil repairDisk disk4

  • à validation > un avertissement s'affiche : tape y (= yes) et revalide
  • la commande répare la table de partition GPT du disque. Je me suis demandé si elle n'était pas corrompue > ce qui bloquait une création de partition d'une extension valide

Poste le retour.
 
Bloc de code:
diskutil repairDisk disk4
Repairing the partition map might erase disk4s1, proceed? (y/N) y
Started partition map repair on disk4
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
Repairing the EFI system partition's file system
Updating boot support partitions for the volume as required
Creating a new EFI system partition
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking booter partition disk4s3
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
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Updating Windows boot.ini files as required
The partition map has been repaired
Finished partition map repair on disk4
 
Réparation effectuée. Petite inspection de l'état des lieux. Passe les 2 commandes :
Bloc de code:
sudp gpt show disk4
diskutil list

  • qui affichent les blocs et les disques

Poste ces tableaux.
 
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        
  2725505336      262144      2  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  2725767480  3134765651        
  5860533131          32         Sec GPT table
  5860533163           1         Sec GPT header

Bloc de code:
/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:                 Apple_Boot Boot OS X               134.2 MB   disk4s3
 
Un point de marqué ! --> cette ligne -->
Bloc de code:
   2:                 Apple_Boot Boot OS X               134.2 MB   disk4s3

  • montre que la partition du « booter » a récupéré en bloc 0 le super-bloc intact de cette partition > portant le header du système de fichiers jhfs+. Ce qui a permis la reprise en charge par le kernel du volume Boot OS X du booter. Volume non monté par défaut.
----------

Voyons si on peut remplir le vide entre la partition EFI & la partition du booter = recréer la partition CoreStorage > qui essuyait un refus incompréhensible (numériquement parlant). Passe les commandes :
Bloc de code:
diskutil umount force disk4
sudo gpt add -b 409640 -s 2725095696 -t 53746F72-6167-11AA-AA11-00306543ECAC disk4

  • qui démontent le disque & créent un descripteur de partition CoreStorage intercalaire

Poste l'affichage retourné par la 2è.
 
Bloc de code:
disk4s3 added

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

Bloc de code:
/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:                 Apple_Boot Boot OS X               134.2 MB   disk4s2
   3:          Apple_CoreStorage Sans titre              1.4 TB     disk4s3
 
Hé ! hé ! - situation décoincée. Mais cette nouvelle partition ajoutée en 3è instance va hériter du rang3 > alors qu'il faut à toute force qu'elle ait le rang2 dans la table GPT. On va faire le forcing pour réaligner les rangs des partitions dans la GPT.

Repasse la commande :
Bloc de code:
diskutil repairDisk disk4

  • qui répare de nouveau la table (tu tapes y et tu revalides quand demandé)

Poste l'affichage retourné.
 
Merci encore du temps que tu prends pour moi !

Bloc de code:
diskutil repairDisk disk4
Repairing the partition map might erase disk4s1, proceed? (y/N) y
Started partition map repair on disk4
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 disk4s2
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
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Verifying storage system
Checking volume
disk4s3: Scan for Volume Headers
disk4s3: Scan for Disk Labels
Invalid Disk Label @ 4096: invalid field value
Invalid Disk Label @ 4198400: invalid field value
Logical Volume Group 9EE60ADE-712E-42D9-A5E6-95A754128064 on 1 device
disk4s3: Scan for Metadata Volume
Logical Volume Group has a 24 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Unable to bootstrap transaction group 11: cksum mismatch
Continue scanning metadata for an older checkpoint
Load and verify Segment Headers
Unable to bootstrap transaction group 10: cksum mismatch
No valid commit checkpoint found
The volume 9EE60ADE-712E-42D9-A5E6-95A754128064 was found corrupt and needs to be repaired
Storage system check exit code is 1
Repairing storage system
Checking volume
disk4s3: Scan for Volume Headers
disk4s3: Scan for Disk Labels
Invalid Disk Label @ 4096: invalid field value
Invalid Disk Label @ 4198400: invalid field value
Logical Volume Group 9EE60ADE-712E-42D9-A5E6-95A754128064 on 1 device
disk4s3: Scan for Metadata Volume
Logical Volume Group has a 24 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Unable to bootstrap transaction group 11: cksum mismatch
Continue scanning metadata for an older checkpoint
Load and verify Segment Headers
Unable to bootstrap transaction group 10: cksum mismatch
No valid commit checkpoint found
The volume 9EE60ADE-712E-42D9-A5E6-95A754128064 was found corrupt and can not be repaired
Storage system check exit code is 1
Repairing storage system
The volume disk4s3+disk0s2+disk1s3+disk1s5 cannot be repaired when it is in use
Checking volume
disk4s3: Scan for Volume Headers
disk0s2: Scan for Volume Headers
disk1s3: Scan for Volume Headers
disk1s5: Scan for Volume Headers
disk4s3: Scan for Disk Labels
Invalid Disk Label @ 4096: invalid field value
Invalid Disk Label @ 4198400: invalid field value
disk0s2: Scan for Disk Labels
disk1s3: Scan for Disk Labels
disk1s5: Scan for Disk Labels
Logical Volume Group 31C7681C-D38F-4B76-B934-4B727513B018 on 1 device
Incomplete or inconsistent CoreStorage Physical Volume set
Storage system check exit code is 1
Problems were encountered during repair of the partition map
Error: -69716: Storage system verify or repair failed
Underlying error: 1: Operation not permitted
 
Il s'en passe des choses en coulisses ! -->

- à présent redémarre absolument une fois > ta session réouverte > passe la commande :
Bloc de code:
diskutil list

  • poste le tableau des disques : ce sera un moment de vérité.
 
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
 
Tout a bien été réaligné. Mais... (il y a un mais) cette ligne -->
Bloc de code:
   2:          Apple_CoreStorage Sans titre              1.4 TB     disk5s2

  • montre bien la partition CoreStorage recréée. Le nom "Sans titre" n'est pas un nom de volume > mais l'intitulé du Conteneur CoreStorage qui a sa base sur cette partition. Le problème est que cette partition devrait exporter un espace-disque virtuel secondaire dit : Logical Volume. Ce qu'elle ne fait pas.
  • je crains que la "zéroïsation" de 500 Mo de blocs n'ait laminé les headers du CoreStorage inscrits sur la partition.

Passe la commande informative :
Bloc de code:
diskutil cs list

  • qui affiche le tableau détaillé du CoreStorage > s'il en est un de valide

Poste le retour.
 
Je n'ai que ça qui concerne le disk5

Bloc de code:
    +-< Physical Volume CD903024-727F-421C-A8BA-8AB3DE625A2A

        ----------------------------------------------------

        Index:    0

        Disk:     disk5s2

        Status:   Checking

        Size:     1395248996352 B (1.4 TB)
 
Dernière édition:
La recréation de la partition a bien récupéré l'entité d'un Conteneur (= Groupe de Volumes Logiques) avec son UUID = 9EE60ADE-712E-42D9-A5E6-95A754128064 + le magasin de stockage physique Physical Volume inscrit dans la partition disk5s2 > avec son UUID = CD903024-727F-421C-A8BA-8AB3DE625A2A.

Comment est-ce possible > si la "zéroïsation" a laminé environ 300 Mo de la partition disk0s2 après avoir laminé les 209 Mo de la partition EFI1 ? -->

  • car le bloc 0 de la partition disk0s2 était d'origine le super-bloc du système de fichiers jhfs+ inscrit sur cette partition. Lorsque la conversion au CoreStorage a été effectuée (afin de permettre un chiffrement) --> il était impossible sans reformatage de déloger le système de fichiers jhfs+ du super-bloc de tête de la partition et des blocs suivants. Ce qui fait que les headers du CoreStorage s'installent en pied de partition > afin de déployer leur processus de virtualisation. Étant en queue d'une partition de 1,4 To > ils n'ont pas été touchés par la "zéroïsation" > par contre le super-bloc du système de fichiers jhfs+ (générateur du volume terminal) a été effacé ainsi que 300 Mo de blocs suivants environ. C'est ce qui fait que le CoreStorage ne peut pas exporter un Logical Volume porteur du volume jhfs+ terminal.

Passe encore la commande :
Bloc de code:
diskutil repairDisk disk5

  • qui répare la table GPT > mais aussi la partition EFI (dont tu remarqueras qu'elle a récupéré un volume EFI) > toute architecture CoreStorage trouvée sur le disque > toute partition booter trouvée > toute partition jhfs+ trouvée. C'est une réparation "totale".

Poste le retour (mais je pense qu'une réparation de ce qui manque à la partition est impossible).