10.14 Mojave Le disque que vous avez inséré n'est pas lisible par cet ordinateur... ?

Riket

Membre confirmé
25 Octobre 2005
80
1
Bonjour,
j'essaie de récupérer des données sur un disque qui tournait sur un Mac mini mais lorsque je le branche en externe j'ai le message suivant :
"Le disque que vous avez inséré n'est pas lisible par cet ordinateur"
J'ai déjà essayé un certain nombre de manip dans Terminal, voilà ce que j'obtiens :


/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *500.1 GB disk3
1: 0xEE 500.1 GB disk3s1


mais je n'ai pas trouvé quoi faire ensuite...
Merci de votre aide.
 
Ton problème est simple, la table de partition du disque externe indique qu'il est dans un format pour Windows. Par défaut macOS sait lire les formats FAT32 et NTFS, mais pour ce dernier il est incapable d'écrire dessus sans un logiciel tiers, du genre Microsoft NTFS

J'ai déjà essayé un certain nombre de manip dans Terminal, voilà ce que j'obtiens :
Tu as donc joué a l'apprenti sorcier, relance le Terminal, fais un Copier/Coller de cette commande...
Bloc de code:
diskutil list
...en validant avec la touche Entrée, puis en donnant le résultat entre des balises < > Code.

Petit rappel...
Pour diffuser un rapport EtreCheck ou un retour de commandes via le Terminal dans les forums, dans votre réponse, un clic sur cette icône , sélectionnez les Balises </> Code, dans la fenêtre qui s’ouvrira faites un Copier/Coller du rapport et/ou du résultat du Terminal, un clic sur Insérer et validez votre réponse.
 
Bonsoir Riket

  • la table de partition du disque est désignée comme : FDisk_partition_scheme. Ce qui est une autre façon de désigner une MBR (schéma Windows)
  • le type de la partition est désigné comme : 0xEE. Il s'agit de l'hex code (code de type de partition) d'une partition de type EFI -->
- il est tout à fait douteux qu'une partition unique ait existé sur ce disque avec le type EFI. Il est conjecturable au contraire que le type de cette partition ait été corrompu > alors qu'il était au départ un : DOS_FAT_32 (hex_code : 0x0B) => la destinant à héberger un système de fichiers FAT-32 ; ou un Windows_NTFS (hex code : 0x07) => la destinant à héberger un système de fichiers exFAT ou NTFS. Il s'agirait alors d'éditer le descripteur de cette partition dans l'actuelle table MBR => afin de restaurer le type valide de cette partition.​


=> te souviens-tu quel était le format du volume qui existait sur la grande partition de disque ? - FAT-32 ? - exFAT ? - NTFS ?

=> quand tu dis que ce disque "tournait" sur un Mac mini : il ne s'agissait pas d'un disque de démarrage mais de stockage de données ?
 
Merci de vos réponses, tout d'abord voici ce que donne le résultat du Terminal :


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 Macintosh HD Photos     999.9 GB   disk0s2

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                 Apple_APFS Container disk2         1000.0 GB  disk1s2

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk2
                                 Physical Store disk1s2
   1:                APFS Volume Macintosh SSD           132.8 GB   disk2s1
   2:                APFS Volume Preboot                 62.7 MB    disk2s2
   3:                APFS Volume Recovery                507.2 MB   disk2s3
   4:                APFS Volume VM                      3.2 GB     disk2s4

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *500.1 GB   disk3
   1:                       0xEE                         500.1 GB   disk3s1

Pour répondre à Macomaniac, ce disque était d'origine dans un Mac mini et tournait je crois (c'est le Mac de mes parents) sous Yosemite.
Suite à une panne, ils ont fait remplacer ce disque qui était HS, leur a-t-on dit, mais dont les données ont toutes été récupérées, sauf quelques dizaines de photos dans Iphoto.
Je viens donc de récupérer ce disque pour essayer de les retrouver. J'en suis là...
 
Pour répondre à Macomaniac, ce disque était d'origine dans un Mac mini et tournait je crois (c'est le Mac de mes parents) sous Yosemite.
Utilisé en disque de stockage de données dans un format Windows sûrement, mais en aucun cas il eu été possible de démarrer une version d’OS X Yosemite depuis ce disque dur externe...
/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *500.1 GB disk3
1: 0xEE 500.1 GB disk3s1
...c'est impossible. La seule alternative et hypothèse est peut-être une erreur dans le type de formatage.
 
@ Riket

Passe la commande (copier-coller) :
Bloc de code:
sudo fdisk /dev/disk3

  • à 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 disques - selon le descriptif MBR

Poste le tableau.
 
Alors je ne comprends pas : qu'a fait le gars qui a remplacé le disque et récupéré les données ?
Voilà le résultat que me donne le Terminal :

Bloc de code:
Password:
Disk: /dev/disk3    geometry: 7600/255/63 [122096646 sectors]
Sector size: 4096 bytes
Signature: 0xAA55
         Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
1: EE 1023 254  63 - 1023 254  63 [         1 -  976773167] <Unknown ID>
2: 00    0   0   0 -    0   0   0 [         0 -          0] unused     
3: 00    0   0   0 -    0   0   0 [         0 -          0] unused     
4: 00    0   0   0 -    0   0   0 [         0 -          0] unused
 
Voici le descriptif MBR du partitionnement :
Bloc de code:
         Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
1: EE 1023 254  63 - 1023 254  63 [         1 -  976773167] <Unknown ID>

  • une table de partition MBR est un procédé désuet de décrire des partitions > qui a été longtemps la caractérisque de Windows. Procédé de type : "CHS" ou : Cylinder_Head_Sector (cylindre - tête - secteur) --> à peu près aussi biscornu que les mesures anglo-saxonnes en inches et autres yards. Ce procédé désuet "dès l'origine" (si je puis dire ironiquement) n'a jamais été employé sur Mac comme table de partition directrice d'un disque de démarrage > les Mac Intel recourant à une table de partition GPT (GUID_Partition_Table) dont la caractéristique essentielle est de n'utiliser qu'une numérotation arithmétique simple des blocs. Tu trouves cette retraduction GPT dans la partie droite du tableau : où start désigne arithmétiquement le n° de départ de la partition (= bloc n°1) et size désigne arithmétiquement l'extension de blocs de la partition (= 976773167 blocs de 512 octets => soit 500,1 Go).
  • ces déclarations caustiques effectuées > tu remarques en tête du descripteur MBR1 la mention : EE. Il s'agit en abrégé du hex code : 0xEE > qui est la désignation codée du type : "EFI" de partition. Il faut savoir (en effet) qu'un descripteur de partition dans une table de partition --> ne décrit pas simplement le départ de la partition (le n° de son bloc de tête) > ni l'extension de la partition (le nombre total de blocs ou taille qui la caractérise) > non plus que le rang de la partition (son n° d'ordre) => mais aussi le type de la partition. Le type d'une partition est un encodage qui la destine à héberger tel genre de système de fichiers (dispositif logiciel formateur d'un volume sur la partition) plutôt que tel autre genre. Le type d'une partition prévient le kernel (le noyau du système démarré) du genre de système de fichiers à prendre à charge dans la partition.
  • un système de fichiers se loge dans une partition sur la série des blocs d'en-tête (pour une extension d'environ 500 Mo en moyenne) > le bloc de tête de la partition (son bloc n°1) constituant le "super-bloc" du système de fichiers (le bloc sur lequel se trouve inscrit son header). C'est donc le bloc d'ancrage du système de fichiers. Suppose que dans la partition unique du disque de 500 Go ait été logé un système de fichiers exFAT (spécifique de Windows). Le type adéquat pour décrire cette partition devrait alors être : 0x07 = hex code du type : "Windows_NTFS". Or actuellement on a affaire à un hex code : 0xEE = hex code du type : "EFI". Le kernel (de macOS démarré) va donc attendre à la lecture de ce type : "EFI" => l'existence d'un système de fichiers "adéquat à ce type" - soit par défaut un système de fichiers FAT-32. Or le système de fichiers trouvé étant un exFAT > càd. un système de fichiers inadéquat au type 0xEE de la partition --> le kernel rejette immédiatement la prise en charge de ce système de fichiers et dénie le montage du volume qu'il forme sur la partition.
 
Dernière édition par un modérateur:
  • il conviendrait alors d'éditer à rebours le type de la partition > pour restaurer le type originel en adéquation avec le genre de système de fichiers (le "format") existant dans la partition. Oui mais : quel était ce système de fichiers (ce "format de volume") ? Ce qui fait que > connaissant le système de fichiers => on puisse prédire le type légitime qui l'annonce adéquatement au kernel ? Tu dis : "qu'a fait le gars qui a remplacé le disque et récupéré les données ?". Quelqu'un est donc intervenu sur ce disque > qui serait le responsable de la corruption du type de la partition (à supposer que la table de partition ait été MBR à l'origine) ? - ou bien > si c'était le disque de démarrage du mini > alors la table de partition aurait été nécessairement GPT et l'actuelle table de partition MBR n'aurait jamais été la table directrice du disque ? - je peux diriger la manœuvre pour effectuer une édition de table de partition => mais ce que je ne sais pas avec certitude c'est : a) ce disque était-il un disque de stockage du mini avec une table MBR d'origine ou un disque de démarrage avec une GPT d'origine ? b) en conséquence du 1er point > le type EFI pour une partition unique est-il une corruption d'un type Windows pour un système de fichiers Windows ? - ou est-ce la corruption d'un type Apple de partition de démarrage comme "Apple_HFS" ?
  • il faut savoir que sur tout disque de démarrage Mac existe toujours 2 tables de partitions : une table GPT directrice et une table MBR alternative. Cette dualité a été mise en place afin de permettre un éventuel boot de Windows sur une partition locale de disques de démarrage Mac. Sur un disque de démarrage Mac à GPT directrice > sans partition BOOTCAMP => la table MBR alternative a toujours sans exception les caractéristiques suivantes : a) elle est résidente du seul bloc n°0 du disque (ou son 1er bloc) > b) elle a la forme d'une PMBR (Protective_MBR) = table MBR n'incluant aucun descripteur de partition correspondant à ceux de la GPT directrice > mais décrivant toujours la totalité de l'espace disque passé le bloc n°0 (donc à partir du boc n°1) comme s'il s'agissait d'une partition unique de type : EFI (hex code : 0xEE). Ce qui fait d'une PMBR un "fake" : une table bidonnée ne faisant pas d'ombrage à la GPT directrice. Lorsqu'on a affaire par contre à un disque de stockage décrit d'origine en mode Windows > alors il n'y a pas de table GPT mais uniquement une table MBR directrice toujours sur le bloc 0. Dans cette configuration > le descripteur MBR de la partition unique du disque ne désigne jamais le bloc n°1 (le 1er bloc vacant à partir du bloc n°0 portant la MBR) comme bloc de départ de la partition > mais toujours le bloc n°2048 (en ménageant un tampon initial d'espace libre de 2047 blocs (de 512 octets = 1,04 Mo).
 
Dernière édition par un modérateur:
  • ces considérations qui ont dû peut-être te paraître suprêmement oiseuses par leur caractère à la fois théorique et minutieux --> me permettent quand même d'avancer une conjecture : je note que la table MBR actuelle décrit la totalité de l'espace du disque comme étant de type : "EFI" à partir du bloc n°1 (second bloc du disque après le n°0 de résidence de la MBR) > pour une extension de 500,1 Go soit la totalité des blocs du disque jusqu'au dernier. Si la table de partition de ce disque avait été d'origine une MBR décrivant une partition de stockage > le bloc de tête assigné à la partition n'aurait jamais été le n°1 mais toujours le n° 2048. Or l'actuelle MBR décrit une partition unique qui commence au bloc n°1 & elle le fait dans le type : "EFI" comme une PMBR (Protective_MBR) alternative de la GPT directrice d'un disque de démarrage Mac. Il faudrait alors conjecturer nécessairement qu'on a bien affaire ici à un disque de démarrage Mac > dont la table GPT directrice (inscrite sur les blocs n°1 à 33 du disque) aurait été supprimée > de telle manière que demeure seule la table PMBR alternative du bloc n°0 > décrivant en mode "fake" (bidonné) l'espace du disque comme s'il n'était constitué que d'une partition unique de type : "EFI" - ce qui serait faux du point de vue de la GPT disparue. Il faudrait alors non pas éditer le descripteur MBR du bloc 0 > mais recréer une table GPT directrice vide > puis recréer dans cette table les descripteurs GPT des partitions attendues en mode Apple.

Si tu as suivi mon argumentation => alors il devient décisif de savoir si ce disque était le disque interne unique du mini (qui n'en contenait aucun autre). Si tel a bien été le cas > c'était le disque de démarrage et ma conjecture d'une suppression de la GPT directrice du disque et de la simple persistance de la PMBR alternative du bloc n°0 décrivant une partition "fake" de tout l'espace disque dans le type : "EFI" => tiendrait la corde. Peux-tu t'informer à ce sujet et donner une réponse certaine ?

Par ailleurs > passe la commande :
Bloc de code:
sudo gpt show /dev/disk3

  • la commande affiche la distribution des blocs du disque > non plus selon l'ordonnance MBR > mais selon l'ordonnance GPT.

Poste le tableau retourné. Si jamais se trouve mentionné en regard de la table MBR du bloc 0 (la seule actuellement existante) : PMBR (Protective_MBR) = alors la preuve serait faite que cette table n'a jamais décrit de manière principale un disque de stockage > mais est la subsistance d'une table "fake" décrivant la totalité de l'espace-disque comme s'il ne s'agissait que d'une partition de type : "EFI" - ce pour ne pas perturber la GPT directrice actuellement disparue et qu'il faudrait recréer.

Question : tu évoquais quelqu'un qui aurait récupéré les données du disque --> si cela a été effectué > y a-t-il un enjeu à recréer la GPT disparue pour tenter de refaire eixster le volume de la partition principale ? - plutôt que de réinitialiser le disque entier pour s'en servir de DDE ?
 
Dernière édition par un modérateur:
  • J’aime
Réactions: litobar71
Je confirme que ce disque était le disque interne unique du mini (qui n'en contenait aucun autre).
Voilà les infos retournées par le Terminal :

Bloc de code:
gpt show: unable to open device '/dev/disk3': No such file or directory

Il y a sur ce disque quelques dizaines de photos que je souhaite récupérer.
Merci de ta disponibilité !

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

Pardon, je viens de voir que le disque était déconnecté !!!
Je recommence.

Bloc de code:
      start       size  index  contents
          0          1         PMBR
          1  122096645
 
Dernière édition par un modérateur:
Cette mention est décisive -->
Bloc de code:
          0          1         PMBR

  • car elle déclare que l'actuelle table MBR inscrite sur l'unique bloc n°0 du disque est une PMBR. Cette table n'existe jamais en tant que telle sur le bloc n°0 d'un disque de stockage paramétré en mode Windows > mais exclusivement sur un disque paramétré en mode de table GPT directrice - comme un disque de démarrage Mac. Elle n'a jamais décrit une partition déterminée > mais est une table "fake" décrivant le disque entier depuis le bloc n°1 compris (premier vacant) --> comme s'il s'agissait d'une partition de type : EFI (hex code : 0xEE).
  • c'est corroboré par ton assertion que ce disque était l'unique disque interne du mini => c'était donc son disque de démarrage > qui avait donc une table GPT directrice > et une PMBR alternative "fake" sur le bloc n°0.

=> ces considérations décident entièrement de la problématique : il ne s'agit absolument pas d'éditer un descripteur MBR > mais il faut laisser l'actuelle PMBR "fake" là où elle est comme elle est. Elle n'a jamais joué aucun rôle actif sur ce disque. Il s'agit au contraire de recréer une table GPT > d'abord ne décrivant qu'une partition de type : EFI régulière (209,7 Mo) => ensuite de lui injecter 1 descripteur de partition principale (macOS) de manière entièrement spéculative (= à partir d'une théorie de ce que le type de cette partition doit être et où exactement - au bloc près - elles doit être localisée).

----------

Est-ce que tu t'accordes avec mon raisonnement et avec les conséquences techniques (recréation d'une GPT) que j'en ai tirées ?

- a) question technique : est-ce que tu te souviens si FileVault (logiciel de chiffrement) était activé ou pas ? - quel était l'OS installé sur le disque ? - le disque est-il un HDD (rotatif) ou un SSD (statique) ?​

- b) question contextuelle : est-ce qu'un technicien est intervenu sur de disque ? - si oui > pourquoi faire ?​
 
Dernière édition par un modérateur:
N'ayant aucune connaissances en informatique, je te fais confiance sur ton raisonnement !
Ce dont je suis sûr, c'est que Filevault n'était pas activé, c'est un HDD, quant à l'OS installé il me semble que c'était Yosemite.
Un technicien est intervenu pour constater que le "disque était HS et qu'il fallait le remplacer". Il a réussi à en récupérer les données mais je ne sais pas comment.
 
  • J’aime
Réactions: litobar71
Alors on a le choix de 2 types de partitions : soit "Apple_HFS" (si le volume Macintosh HD était standard et non chiffré) > soit "Apple_CoreStorage" (au cas où ce format aurait été créé sur la partition par le programme d'installation de l'OS - même en l'absence de chiffrement).

Pour ce qui est de la localisation de cette partition d'OS X sur le disque > on verra après la recréation primaire d'une table de partition. On sait que par défaut une petite partition de type EFI de 209,7 Mo doit se trouver créée en n°1 avec la table GPT.

Vérifie si le disque externe est toujours disk3. Donc passe la commande (copier-coller) :
Bloc de code:
sudo diskutil eraseDisk free null gpt disk3 ; diskutil list disk3 ; sudo gpt show disk3

  • la commande recrée une table GPT sur les blocs 1 - 33 du disque > avec création d'une partition EFI de 209,7 Go > sans formatage d'aucune autre partition pour ne pas réécrire le système de fichiers principal du disque (s'il est toujours inscrit) > affiche la nouvelle configuration du disque > affiche la nouvelle distribution des blocs du disque

Poste l'ensemble de l'affichage retourrné.
 
  • J’aime
Réactions: litobar71
Merci.
Voilà le retour :

Bloc de code:
Started erase on disk3
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Finished erase on disk3
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk3
   1:                        EFI EFI                     314.6 MB   disk3s1
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2          4         Pri GPT table
          6      76800      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      76806  122019835        
  122096641          4         Sec GPT table
  122096645          1         Sec GPT header
 
Voici comment se trouve définie la petite partition de type : EFI (créée par défaut avec une table GPT) -->
Bloc de code:
   1:                        EFI EFI                     314.6 MB   disk3s1

  • tu notes qu'elle a une taille de 314,6 Mo au lieu des 209,7 Mo classiques. Je pense que c'est dû au Mac auquel tu as connecté le disque --> qui doit avoir un OS très récent > peut-être de format apfs (genre : Mojave). Il faut supprimer le descripteur de cette partition > pour créer un nouveau descripteur définissant la taille classique de 209,7 Mo. Car telle quelle > l'extension de la partition empiète sur le super-bloc du système de fichiers de la partition OS X qui doit être créée ensuite.

Passe la commande :
Bloc de code:
sudo gpt remove -i 1 disk3

  • qui supprime le descripteur GPT de la partition EFI

Poste le retour.
 
Mojave est le responsable alors de cette nouvelle définition par défaut d'une partition EFI de 314,6 Mo.

Le descripteur a bien été supprimé. On engage à présent la recréation de la partition. Passe la commande :
Bloc de code:
sudo gpt add -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B -i 1 disk3 ; diskutil list disk3

  • la commande recrée un descripteur GPT de partition telle que : bloc de tête = n° 40 > extension = 409600 blocs (de 512 octets = 209,7 Mo) > type : EFI (via son UUID de type) > rang = n°1. Le bloc de tête & l'extension de blocs => sont donnés ici de manière canonique (de manière conforme aux standards classiques de création de cette partition). Puis la commande réaffiche la configuration du disque.

Poste le retour.
 
Bloc de code:
disk3s1 added
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk3
   1:                        EFI                         1.7 GB     disk3s1
 
Une taille de 1,7 Go se trouve affectée à la partition > parce que la définition par défaut de la taille du bloc par ton OS Mojave est de 4098 octets > soit une valeur octuple du standard de 512 octets. Alors les 409600 blocs d'extension de la partition ont été convertis à une valeur de 3276800 blocs classiques = 1.677 Go.

- est-ce que tu aurais un autre Mac utilisant un OS non apfs (= antérieur à Mojave - voire à High Sierra) --> afin d'éditer la table de partition avec une valeur de bloc par défaut de 512 octets ?​