10.13 High Sierra Mon SSD clone externe ne monte pas au secours

Là on est au delà des vérifications classiques.
On trouve 2 partitions APFS sans Container, donc inutilisables.

Le Conteneur n'est qu'une manifestation du système de fichiers apfs - exactement comme un volume standard avec un nom est une manifestation du système de fichiers jhfs+. Systèmes de fichiers constitués de « headers » inscrits sur l'en-tête de la partition de résidence. Par exemple ici la disk2s3.

Par conséquent : si l'on a 2 partitions de type apfs qui ne montrent actuellement ni magasin de stockage physique Physical Store > si Conteneur virtuel --> cela ne veut pas dire pour autant que les headers apfs, càd. le système de fichiers générateur a déserté pschuttt ! l'en-tête des 2 partitions. Mais on peut tout aussi bien supposer qu'il ne déterminent plus actuellement la génération des structures manifestes : Physical Store et Conteneur.

Auquel cas une commande de vérification du système de fichiers inscrit dans la partition (headers) comme celle de bompi -->
Bloc de code:
sudo diskutil verifyVolume /dev/disk2s3

est plus pertinente qu'une commande de réparation de la table de partition GPT de l'en-tête du disque -->
Bloc de code:
diskutil repairdisk disk2

parce que la première va prouver s'il y a encore dans la tranche logique de la partition un système de fichiers apfs plutôt que rien. À la réaction à la commande précisément.
 
C'est un warning. Normalement il n'y a pas d'effacement.
De toutes façons dans l'état actuel, il n'est pas possible de lire tes 2 partitions APFS.


Auquel cas une commande de vérification du système de fichiers inscrit dans la partition (headers) comme celle de bompi -->
Bloc de code:
sudo diskutil verifyVolume /dev/disk2s3
[/QUOTE]

Bloc de code:
Last login: Tue Dec  5 10:37:27 on ttys000
icii:~ JPG$ sudo diskutil verifyVolume /dev/disk2s3
Password:
Started file system verification on disk2s3
Error: -69564: Unable to find an APFS Container Reference
icii:~ JPG$
 
En re-survolant le tableau retourné par diskutil -->
Bloc de code:
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.1 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS                         250.2 GB   disk2s2
   3:                 Apple_APFS                         400.1 GB   disk2s3
   4:                 Apple_APFS                         399.5 GB   disk2s4
il apparaît que la partition n°2 de type Apple_HFS est également dépourvue de nom de volume associé.

Une commande :
Bloc de code:
diskutil repairVolume disk2s2
serait aussi intéressante à passer > pour voir si la commande trouve un système de fichiers jhfs+ dans le conteneur logique de cette partition ou... rien (à l'instar de la précédente commande adressée à la partition n°3 de type Apple_APFS).
 
En re-survolant le tableau retourné par diskutil -->
Bloc de code:
/dev/disk2 (external, physical):
il apparaît que la partition n°2 de type Apple_HFS est également dépourvue de nom de volume associé.

Une  commande :
[code]diskutil repairVolume disk2s2
serait aussi intéressante

Bloc de code:
Last login: Tue Dec  5 10:59:59 on ttys000
icii:~ JPG$ diskutil repairVolume disk2s2
Started file system repair on disk2s2
Repairing file system
Volume is already unmounted
Performing fsck_hfs -fy -x /dev/rdisk2s2
Checking Journaled HFS Plus volume
Invalid B-tree node size
The volume   could not be verified completely
File system check exit code is 8
Restoring the original state found as unmounted
Error: -69845: File system verify or repair failed
Underlying error: 8: Exec format error
icii:~ JPG$
 
La commande a bien trouvé un système de fichiers jhfs+ dans le conteneur Apple_HFS de la partition n°2 > mais lorsque je contemple le retour de commande :
Bloc de code:
Repairing file system
Volume is already unmounted
Performing fsck_hfs -fy -x /dev/rdisk2s2
Checking Journaled HFS Plus volume
Invalid B-tree node size
The volume   could not be verified completely

je me dis que un peu n'importe quoi > parce qu'au lieu d'afficher le parcours ordonné des fichiers de la structure :
Bloc de code:
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
avec au moins la mention du fichier des segments en excès (extents overflow) au préalable > l'examen saute tout à trac au catalog B-tree pour déclarer qu'il y a une taille de nœud (embranchement) erronée.

Ce manquement à l'ordre régulier de l'examen me fait douter de l'« objectivité » de la commande - si je puis m'exprimer ainsi. C'est comme s'il y avait un problème de reconnaissance des partitions du disque avec leurs systèmes de fichiers > plutôt qu'une disparition (apfs) ou une invalidité (jhfs+) des systèmes de fichiers. Telle est la conjecture que je soumets.

J'ai re-démarré sur un volume «Sierra» et cet OS voit très bien mon volume APFS et son contenu. Je suggérerais de faire un test de ce DDE en démarrant sur un volume recelant l'OS «Sierra 10.12.6» pour voir si les 3 partitions sont toujours tenues pour vides.
 
Je pense qu'il faudrait quand même tenter un :
diskutil repairdisk disk2

Tu n'as pas grand chose à perdre.:D
 
Je n'ai pas de Sierra sous la main, j 'ai migré il y a quelques temps directement de Yosemite.
je vais tacher de trouver mac avec Sierra.
Quelle grosse :poo::poo::poo: ce système de fichier APFS, c'est la première fois de ma vis que je me trouve dans une tel pétrin.
 
Je n'ai pas de Sierra sous la main, j 'ai migré il y a quelques temps directement de Yosemite.
je vais tacher de trouver mac avec Sierra.
Quelle grosse :poo::poo::poo: ce système de fichier APFS, c'est la première fois de ma vis que je me trouve dans une tel pétrin.
En même temps, rien ne t'obligeait à migrer tes DDE en APFS.o_O