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

Ce qui serait peut être intéressant, serait de lister la table GUID de ton DDE :
sudo gpt -r show /dev/disk2
 
Sinon, vous êtes à unanimité d'accord aves cette commande ?
Si j'ai à perdre l'espoir .
diskutil repairdisk disk2

La commande de Jean vérifie / répare la table de partition GPT de l'en-tête (32 premiers blocs logiques) du disque.

Régulièrement, en préambule de cette opération, un message d'avertissement dit que la partition disk0s1 pourrait être reformatée. Cette partition est la petite partition EFI de 209,7 Mo inscrite en première tranche sur le disque et dont le volume est susceptible de receler des exécutables pour l'EFI (le programme de boot du Mac).

S'agissant d'un disque de stockage ici --> le rôle de l'EFI est nul > car le disque est pris en charge seulement après le démarrage > la session d'utilisateur ouverte, par le seul kernel de l'OS démarré. Un re-formatage recréant éventuellement un volume EFI du même type ne peut donc avoir aucune incidence > le kernel ne recourant pas à cette partition pour monter les volumes sur les partitions.
 
L 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.
J'ai testé sur Mac Sierra et idem, rien, nada, peau de balle, rien ne monte :(
Capture 5.jpg
En même temps, rien ne t'obligeait à migrer tes DDE en APFS.o_O
Binnnn si, c'était un clone de High Sierra, soit deux partitions Apfs et une de données (sans importances) en HFS+
Ce qui serait peut être intéressant, serait de lister la table GUID de ton DDE :
sudo gpt -r show /dev/disk2
Bloc de code:
Last login: Tue Dec  5 12:08:21 on console
icii:~ JPG$ sudo gpt -r show /dev/disk2
Password:
       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   488700368      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   489110008      262144     
   489372152   781512144      3  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  1270884296   780316032      4  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  2051200328           7     
  2051200335          32         Sec GPT table
  2051200367           1         Sec GPT header
icii:~ JPG$
 
La commande de Jean vérifie / répare la table de partition GPT de l'en-tête (32 premiers blocs logiques) du disque.

Régulièrement, en préambule de cette opération, un message d'avertissement dit que la partition disk0s1 pourrait être reformatée. Cette partition est la petite partition EFI de 209,7 Mo inscrite en première tranche sur le disque et dont le volume est susceptible de receler des exécutables pour l'EFI (le programme de boot du Mac).

S'agissant d'un disque de stockage ici --> le rôle de l'EFI est nul > car le disque est pris en charge seulement après le démarrage > la session d'utilisateur ouverte, par le seul kernel de l'OS démarré. Un re-formatage recréant éventuellement un volume EFI du même type ne peut donc avoir aucune incidence > le kernel ne recourant pas à cette partition pour monter les volumes sur les partitions.
Donc , je le fais ou pas ?
ça sert ou pas pour les APFS ?
Risque ou pas ?
 
J'ai fait un test sur une clé que voici-voila :
1) Creation d'une partition HFS+
2) Ajout de 2 partitions APFS

Bloc de code:
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *7.7 GB     disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS Test_Hfs                3.0 GB     disk3s2
   3:                 Apple_APFS Container disk4         4.4 GB     disk3s3

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +4.4 GB     disk4
                                 Physical Store disk3s3
   1:                APFS Volume Test1_APFS              946.2 KB   disk4s1
   2:                APFS Volume Test2_APFS              946.2 KB   disk4s2

Et voici les résultats du :
sudo gpt -r show /dev/disk3
Bloc de code:
Jean:~ jean$ sudo gpt -r show /dev/disk3
     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   5859368      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   6269008    262144        
   6531152   8578328      3  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  15109480         3        
  15109483        32         Sec GPT table
  15109515         1         Sec GPT header
Jean:~ jean$
 
Tu ne risques rien à passer la commande de réparation de la table de partition.

Dans le tableau retourné par gpt > on voit bien les 4 conteneurs-blocs des partitions (1 > 2 > 3 > 4 GPT part<tition>). Les UUID qui les flanquent désignent les types de ces partitions -->

  • C12A7328-F81F-11D2-BA4B-00A0C93EC93B pour la n°1 = type EFI
  • 48465300-0000-11AA-AA11-00306543ECAC pour la n°2 = type Apple_HFS
  • 7C3457EF-0000-11AA-AA11-00306543ECAC pour les n° 3 & 4 = type Apple_APFS

Il y a une bande d'espace libre de 262144 blocs entre les partitions 1-2 et 3-4 = RAS. Les 6 blocs libres entre les descripteurs de la GPT et la partition EFI et les 7 blocs libres entre la queue de la partition n°4 et le backup de la GPT sont de règle = RAS. La PMBR (Protective_MBR) sur le blocs 0 est réglementaire. La GPT primaire sur les blocs 1 à 33 (table GPT) et la GPT secondaire sur les 33 derniers blocs (backup) = RAS.

Aucune anomalie détectée. Pas d'erreur dans la table GPT.
 
On peut voir que lorsque cela fonctionne, il n'y a qu'un identifiant APFS :
6531152 8578328 3 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
le container qui prend tout le lit (si j'ose dire) et distribue ensuite à ses enfants ( les 2 volumes APFS)
Dans le cas de @subsole on trouve 2 enfants orphelins. Le container (parent indigne) s'étant fait la malle.

Dans un message précédent il me semble que dans le cas de @subsole la mise à jour vers 10.13.1 n'a pas été faite :
post #26
Ce qui expliquerait le bug indiqué ici : https://apple.stackexchange.com/questions/304228/howto-recover-apfs-without-container-new-apfs-bug

Est-ce réparable????
 
Tu ne risques rien à passer la commande de réparation de la table de partition.

Dans le tableau retourné par gpt > on voit bien les 4 conteneurs-blocs des partitions (1 > 2 > 3 > 4 GPT part<tition>). Les UUID qui les flanquent désignent les types de ces partitions -->

  • C12A7328-F81F-11D2-BA4B-00A0C93EC93B pour la n°1 = type EFI
  • 48465300-0000-11AA-AA11-00306543ECAC pour la n°2 = type Apple_HFS
  • 7C3457EF-0000-11AA-AA11-00306543ECAC pour les n° 3 & 4 = type Apple_APFS
Il y a une bande d'espace libre de 262144 blocs entre les partitions 1-2 et 3-4 = RAS. Les 6 blocs libres entre les descripteurs de la GPT et la partition EFI et les 7 blocs libres entre la queue de la partition n°4 et le backup de la GPT sont de règle = RAS. La PMBR (Protective_MBR) sur le blocs 0 est réglementaire. La GPT primaire sur les blocs 1 à 33 (table GPT) et la GPT secondaire sur les 33 derniers blocs (backup) = RAS.

Aucune anomalie détectée. Pas d'erreur dans la table GPT.
C'est bien cette cette commande que je dois passer ?
Bloc de code:
diskutil repairdisk disk2

On peut voir que lorsque cela fonctionne, il n'y a qu'un identifiant APFS :
6531152 8578328 3 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
le container qui prend tout le lit (si j'ose dire) et distribue ensuite à ses enfants ( les 2 volumes APFS)
Dans le cas de @subsole on trouve 2 enfants orphelins. Le container (parent indigne) s'étant fait la malle.

Dans un message précédent il me semble que dans le cas de @subsole la mise à jour vers 10.13.1 n'a pas été faite :
post #26
Ce qui expliquerait le bug indiqué ici : https://apple.stackexchange.com/questions/304228/howto-recover-apfs-without-container-new-apfs-bug

Est-ce réparable????
Pendant que j’étais parti testé le SSD externe sur Sierra , J’ai laissé l’iMac faire la mise à jour en 10.13.1 il semble que la rustine 2017-001 soit de nouveau appliquée. Toujours rien le SSD externe ne monte pas
 
C'est bien cette cette commande que je dois passer ?
Bloc de code:
diskutil repairdisk disk2


Pendant que j’étais parti testé le SSD externe sur Sierra , J’ai laissé l’iMac faire la mise à jour en 10.13.1 il semble que la rustine 2017-001 soit de nouveau appliquée. Toujours rien le SSD externe ne monte pas
Oui c'est cela.
La mise à jour aurait pu éviter le bug, mais elle ne le corrigera certainement pas.:(
 
Bloc de code:
Last login: Tue Dec  5 16:59:32 on ttys000
icii:~ JPG$ diskutil repairdisk disk2
Repairing the partition map might erase disk2s1, proceed? (y/N) y
Started partition map repair on disk2
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
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
The partition map appears to be OK
Finished partition map repair on disk2
voilà
 
@ Jean

Tu as créé un seul Conteneur APFS avec 2 volumes sur une seule partition --> donc la commande gpt montre qu'il n'y a qu'une seule partition de type 7C3457EF-0000-11AA-AA11-00306543ECAC = Apple_APFS. Le reste est l'affaire du système de fichiers injecté dans la partition --> de définir un Conteneur avec tant de volumes. La commande gpt s'en fout.

subsole est dans un cas différent : il avait créé deux Conteneurs APFS distincts sur 2 partitions distinctes (avec je le présume un seul volume de stockage par Conteneur). Il y a donc 2 partitions de type 7C3457EF-0000-11AA-AA11-00306543ECAC = Apple_APFS > donc un système de fichiers apfs par partition (= 2 systèmes de fichiers apfs en tout) > dont aucun actuellement ne génère de Conteneur formel avec un volume monté dessus.

Sont-ils présents mais non reconnus ou ont-ils déserté le contenant de chaque partition ?
 
Dernière édition par un modérateur:
La question à te poser maintenant est : as-tu besoin des données perdues de ces partitions?
Si oui il va falloir passer par des outils tiers du style StellarDataRecovery mais un doute m'assaille sur leur efficacité.
Sinon contacter le développeur de CCC s'il aurait une idée : https://bombich.com/blog
 
En fait, la partition du SSD interne (qui es un clone la partition Macintosh HD2 du (feu)SSD externe fait avec SuperDuper) m'irait s'il n'y avait pas ce n'est le problème avec Dreamweaver et les OAM,
Bloc de code:
Le nom de fichier ou le chemin indiqué contient des caractères Unicode ou à deux octets. Réessayer en employant ACII pour le nom de ficher et le chemin d’accès
voir message#1


J'ai testé à partir du SSD externe et le problème n'existait pas sur la partition Macintosh HD2 du SSD externe.
J'ai pensé que le problème de liens venait peut être du clone fait par SuperDuper, j'ai lancé CCC pour cloner la partition Macintosh HD2 du SSD externe sur le SSD interne.
CCC m'a dit un truc du genre "période d'essai dépassée" voulez vous une rallonge, j 'ai fais annuler ". et boummmm

réinstaller tout serais vraiment la loosse absolue et une perte de temps énorme , reconfigurer le serveur, php, toutes les applications.

Pour moi le mieux est de récupérer le clone, et/ou de résoudre le problème de chemin avec caractères Unicode ou à deux octets rencontré par Dreamweaver et les OAM :(
 
Dernière édition:
@ Jean

Tu as créé un seul Conteneur APFS avec 2 volumes sur une seule partition --> donc la commande gpt montre qu'il n'y a qu'une seule partition de type 7C3457EF-0000-11AA-AA11-00306543ECAC = Apple_APFS. Le reste est l'affaire du système de fichiers injecté dans la partition --> de définir un Conteneur avec tant de volumes. La commande gpt s'en fout.

subsole est dans un cas différent : il avait créé deux Conteneurs APFS distincts sur 2 partitions distinctes (avec je le présume un seul volume de stockage par Conteneur). Il y a donc 2 partitions de type 7C3457EF-0000-11AA-AA11-00306543ECAC = Apple_APFS > donc un système de fichiers apfs par partition (= 2 systèmes de fichiers apfs en tout) > dont aucun actuellement ne génère de Conteneur formel avec un volume monté dessus.

Sont-ils présents mais non reconnus ou ont-ils déserté le contenant de chaque partition ?
Donc qq chose du style :
Bloc de code:
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *7.7 GB     disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS HFS                     3.0 GB     disk3s2
   3:                 Apple_APFS Container disk5         2.0 GB     disk3s3
   4:                 Apple_APFS Container disk4         2.3 GB     disk3s4

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.3 GB     disk4
                                 Physical Store disk3s4
   1:                APFS Volume APFS_2                  946.2 KB   disk4s1

/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.0 GB     disk5
                                 Physical Store disk3s3
   1:                APFS Volume APFS_1                  978.9 KB   disk5s1

Bloc de code:
Jean:~ jean$ sudo gpt -r show disk3
Password:
     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   5859368      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   6269008    262144        
   6531152   3906248      3  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  10437400    262144        
  10699544   4409936      4  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  15109480         3        
  15109483        32         Sec GPT table
  15109515         1         Sec GPT header
 
Bloc de code:
Last login: Tue Dec  5 16:59:32 on ttys000
icii:~ JPG$ diskutil repairdisk disk2
Repairing the partition map might erase disk2s1, proceed? (y/N) y
Started partition map repair on disk2
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
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
The partition map appears to be OK
Finished partition map repair on disk2
voilà
Que renvoie maintenant un
diskutil list
 
Que renvoie maintenant un
diskutil list
Bloc de code:
Last login: Tue Dec  5 17:47:03 on ttys000
icii:~ JPG$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         500.1 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.1 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            340.3 GB   disk1s1
   2:                APFS Volume Preboot                 23.5 MB    disk1s2
   3:                APFS Volume Recovery                520.8 MB   disk1s3
   4:                APFS Volume VM                      12.9 GB    disk1s4

/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

icii:~ JPG$
 
Logiquement --> on a fait le tour des options disponibles - malheureusement.

Comment est alimenté ce DDE ?