MacBook Pro disque dur illisible en changeant pour un SSD

misterflou

Membre confirmé
17 Janvier 2019
67
0
45
Bonjour le forum,
hier matin, j'ai installé Sierra sur un SSD que j'ai acheté, installation en externe réussie sans problème.
Au redémarrage de l'installation sur le SSD ça m'a proposé un time machine que j'ai refusé,
et ensuite j'ai essayé de relancer à partir de mon HDD interne d'origine et là il m'indique qu'il se nomme Récupération 10.12.6 et impossible d'avoir accès aux données, ni à quoi que ce soit dessus, je l'ai branché en externe ensuite et dans l'utilitaire de disque il me met ça :
 

Fichiers joints

  • Capture d’écran 2019-01-17 à 14.13.28.png
    Capture d’écran 2019-01-17 à 14.13.28.png
    100,4 KB · Affichages: 122
J'ai regardé la réponse du sujet :
Disque dur illisible et récupération des données
j'ai donc fait le terminal comme indiqué et voilà ce qu'il me donne :
Bloc de code:
MacBook-Pro-de-FLORIAN:~ fbs$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS flo                     999.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        +197.2 MB   disk1
   1:        Apple_partition_map                         32.3 KB    disk1s1
   2:         Apple_Driver_ATAPI                         4.1 KB     disk1s2
   3:                 Apple_HFSX Firefox                 197.1 MB   disk1s3

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *750.2 GB   disk2
   1:                       0xEE                         750.2 GB   disk2s1

MacBook-Pro-de-FLORIAN:~ fbs$ diskutil cs list
No CoreStorage logical volume groups found
 
Bonjour misterflou

Est-ce que tu confirmes que ce disque actuellement en interne :
Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS flo                     999.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

  • disque de 1 To --> est ton nouveau SSD ? - le volume flo contenant l'OS Sierra 10.12.6 installé en mode propre ? - le volume Recovery HD de la partition de secours de 650 Mo --> s'affichant à l'écran du gestionnaire de démarrage (touche "alt") sous le label (= intitulé spécifique de boot) : "Récupération 10.12.6" ?
----------

Si oui > ce disque actuellement en externe :
Bloc de code:
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *750.2 GB   disk2
   1:                       0xEE                         750.2 GB   disk2s1

  • disque de 750 Go --> est-il bien l'ancien HDD ? - qui n'apparaît plus porteur d'aucun volume montable ? - et dont tu voudrais pouvoir accéder les données au lieu de le réinitialiser ?
----------

Dans l'attente de ta confirmation > je réserve mon exposé de la situation logique du disque externe. Juste une question : est-ce que tu as fait quelque chose de spécial --> pour que ce disque externe présente actuellement la configuration qu'on lui voit dans le second tableau ci-dessus ?
 
Salut Macomaniac,
merci pour ta réponse, je te confirme que le SSD de 1To est celui qui est actuellement en interne sur le mac,
le disque de 750 Go est bien l'ancien HDD et je n'ai malheureusement rien fait de particulier quand j'ai installé le SSD (OS parlant au redémarrage de l'OS il m'a bien affiché les 2 disques tels qu'ils étaient. c'est après mise en interne du SSD que le HDD en étant branché en externe est devenu comme ça.)
 
Le HDD de 750 Go était le disque qui supportait avant ton volume de démarrage ? -->

- est-ce qu'il n'y avait qu'un volume principal - nommé Macintosh HD ?​

- est-ce que FileVault était activé ou non ?​

- quel était l'OS installé dans le volume ?​
 
alors oui c'était le disque supportant le volume de démarrage,
un seul volume principal sous Sierra,
et je ne sais pas si Filevault était activé...
l'est il nativement ?
 
Avant de te proposer des manipulations de tables de partitions / partitions -->

- est-ce que tu pourrais expérimentalement permuter les 2 disques (mettre le SSD en externe et remettre le HDD en interne) > afin de vérifier > démarré avec "alt" sur le volume flo du SSD externe > comment le HDD interne se trouve affiché dans le tableau d'un diskutil list ?​
 
Mon HDD réapparait bien quand je boot avec alt ;)
voilà ce qui apparait, sur le terminal :
Bloc de code:
MBP-de-FLORIAN:~ fbs$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *750.2 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage MAC OS X                749.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS MAC OS X               +748.9 GB   disk1
                                 Logical Volume on disk0s2
                                 44579C6B-7493-4890-B262-08B64CBA1E22
                                 Unencrypted

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS flo                     999.3 GB   disk2s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3
 
Il y a un système de stockage CoreStorage (non chiffré) sur la partition principale du HDD. C'est un dispositif qui virtualise un espace-disque secondaire appelé Logical Volume (ici disk1) > sur lequel monte le volume MAC OS X standard.

Et il y une partition de secours Recovery HD.

Passe la commande (copier-coller) :
Bloc de code:
sudo gpt show /dev/disk0

  • à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide
  • la commande affiche la distribution des blocs du disque. En cas de problème > il serait possible de reconstruire une table de partition GPT valide d'après le paradigme de ce tableau.

=> poste ce tableau dans une fenêtre de code.

----------

Pourquoi ce même HDD > placé en externe > offre-t-il une configuration logique invalide ? --> je n'en ai aucune idée.
 
voilà
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  1463469952      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  1463879592     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1465149128           7        
  1465149135          32         Sec GPT table
  1465149167           1         Sec GPT header
 
Très bien. Ce tableau des blocs sera précieux > archivé ici > en cas de problèmes.

Passe la commande :
Bloc de code:
diskutil repairDisk disk0

  • une demande de confirmation s'affiche (avec un avertissement concernant la partition EFI) --> tape y (comme yes) et revalide
  • la commande lance une réparation totale du disque : de sa table de partition GPT > de la partition EFI1 > des structures du CoreStorage > de la partition booter Recovery HD > du bloc de prise en charge du système de fichiers jhfs+

Poste l'affichage d'ensemble retourné.
 
Bloc de code:
MBP-de-FLORIAN:~ fbs$ diskutil repairDisk disk0
Repairing the partition map might erase disk0s1, proceed? (y/N) y
Started partition map repair on disk0
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 disk0s3
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 Recovery HD 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
disk0s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
Logical Volume Group 5CB86675-496E-46CD-9911-C73B8E2F3333 on 1 device
disk0s2: 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
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify 0535536D-62D3-4C84-8FAF-9B9424DFA264
Load and verify 44579C6B-7493-4890-B262-08B64CBA1E22
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 5CB86675-496E-46CD-9911-C73B8E2F3333 appears to be OK
Storage system check exit code is 0
Repairing storage system
The volume disk0s2 cannot be repaired when it is in use
Checking volume
disk0s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
Logical Volume Group 5CB86675-496E-46CD-9911-C73B8E2F3333 on 1 device
disk0s2: 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
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify 0535536D-62D3-4C84-8FAF-9B9424DFA264
Load and verify 44579C6B-7493-4890-B262-08B64CBA1E22
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 5CB86675-496E-46CD-9911-C73B8E2F3333 appears to be OK
Storage system check exit code is 0
Updating Windows boot.ini files as required
The partition map appears to be OK
Finished partition map repair on disk0
voilà ce que ça donne
 
Tout a l'air sans erreur. RAS.

Tu n'as plus qu'à faire l'opération matérielle inverse : remettre le SSD en interne > et le HDD en externe. Rebooter sur le volume flo du SSD. Repasser une commande :
Bloc de code:
diskutil list

  • et poster le tableau des disques --> qu'on voie si le HDD en externe a gardé sa configuration actuelle.
 
bizarre, voilà le résultat
Bloc de code:
MBP-de-FLORIAN:~ fbs$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS flo                     999.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *750.2 GB   disk1
   1:                       0xEE                         750.2 GB   disk1s1
 
Ouaip ! super bizarre -->

- en résumé : tu te retrouves avec une table de partition MBR (FDisk_partition_scheme = schéma Windows) au lieu de la table GPT principale ; et une seule partition de type 0xEE = code pour le type EFI d'une partition qui englobe tout l'espace du disque. Bref : tout se passe comme si la table de partition GPT principale se trouvait neutralisée lorsque le disque est en position externe. C'est la 1ère fois que je vois ça.​

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

  • qui affiche le tableau des blocs du disque

Poste le retour.
 
Oui : on voit que la seule table de partition reconnue est une PMBR (Protective_MBR) inscrite sur le seul bloc 0 (1er bloc) du disque -->

  • sur tout disque Mac > il existe toujours 2 tables de partitions : une PMBR comme ici sur le seul bloc 0 > dont la caractéristique est de décrire la totalité des blocs suivants du disque (ici du bloc n°1 au bloc n° 183143646) comme relevant d'un type de partition 0xEE (= type EFI) > sans système de fichiers inscrit ni volume = sans formatage). C'est ce que tu vois dans ce tableau -->
Bloc de code:
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *750.2 GB   disk1
   1:                       0xEE                         750.2 GB   disk1s1

  • tu ne le vois > que parce que la seconde table de partition d'un disque Mac : la table principale ou directrice GPT > inscrite régulièrement sur les blocs 1 à 33 du disque --> ne se trouve plus du tout reconnue actuellement. Sa disparition inexplicable --> laisse donc la seule table alternative PMBR décrire le disque de manière "bidonnée" comme relevant d'une pseudo partition de type EFI (0xEE). Ce qui n'arrive jamais lorsque la GPT principale est en service > car c'est elle qui assure la description dominante des partitions du disque. Ce qui devrait donc donner le tableau suivant -->
Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *750.2 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage MAC OS X                749.3 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS MAC OS X               +748.9 GB   disk2
                                 Logical Volume on disk1s2
                                 44579C6B-7493-4890-B262-08B64CBA1E22
                                 Unencrypted

  • puisque le paradigme de la distribution des blocs des partitions selon la GPT est connu -->
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  1463469952      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  1463879592     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1465149128           7       
  1465149135          32         Sec GPT table
  1465149167           1         Sec GPT header

  • je peux si tu veux te passer les commandes qui vont > sur le HDD placé en externe --> recréer une table GPT principale qui va décrire exactement (au bloc près) les 3 partitions de ce disque - dont la partition CoreStorage qui virtualise l'espace-disque secondaire d'un Logical Volume portant le volume MAC OS X.
 
Wow, alors là tu me scotche carrément, je prends le temps de comprendre ce que tu as mis (désolé mais c'est un poil complexe pour le pauvre noob que je suis ;) ).
Par contre je l'ai remis en interne pour faire les sauvegardes de ce qui était important et il n'y a eu aucun problème.
 
C'est bien ce que je n'arrive pas à concevoir -->

- manifestement la table GPT (GUID_Partition_Table) principale --> existe toujours bien inscrite sur les blocs 1 à 33 -->
Bloc de code:
           1           1         Pri GPT header
           2          32         Pri GPT table

  • puisqu'à peine le disque replacé en interne --> hop ! elle redécrit les partitions GPT du disque. Mais à peine le HDD replacé en externe --> hop ! la GPT disparaît littéralement de l'affiche et c'est la PMBR du bloc 0 -->
Bloc de code:
           0           1         PMBR
  • qui prend l'ascendant pour décrire un pseudo-partitionnement du disque.
=> c'est la 1ère fois que j'observe un pareil phénomène...