Partitions Mac manquantes - système de fichiers non reconnu

La gestion des disques de Windows a remplacé la table de partition GUID par une table de partition MBR. Cela n'affecte généralement que la table de partition mais pas le contenu de votre disque (bien qu'il semble avoir disparu) ! Pour restaurer une table de partition GUID correcte, le MBR doit être supprimé et une table de partition GUID correcte doit être restaurée.

L'obstacle particulier ici est le suivant : le PO ne dispose ni d'une clé USB, ni d'un second Mac, ni d'un disque externe.

La réponse ci-dessous est PAS destiné aux utilisateurs AVEC une clé USB ou un disque externe ! Si vous disposez de l'un de ces dispositifs, des solutions beaucoup plus simples existent.

Préparation :

• Redémarrez en mode de récupération Internet en appuyant sur alt cmd R au démarrage.

  Les conditions préalables sont la dernière mise à jour du micrologiciel installée, l'utilisation d'un réseau Ethernet ou WLAN (WPA/WPA2) et un routeur avec DHCP activé.
  Sur une ligne de 50 Mbps, il faut environ 4 minutes (en présentant un petit globe animé) pour démarrer dans une image de récupération par le réseau qui est généralement chargée depuis un serveur Apple/Akamai.

  Je recommande l'Ethernet car il est plus fiable. Si vous êtes limité au WIFI et que le processus de démarrage échoue, redémarrez simplement votre Mac jusqu'à ce que vous réussissiez à démarrer.

  Vous pouvez également démarrer à partir d'une clé d'installation amorçable (de préférence Yosemite ou El Capitan) ou d'une clé contenant un système complet (de préférence Yosemite ou El Capitan). Si vous démarrez sur un système complet et que vous vous connectez en tant qu'administrateur, vous devez ajouter en préambule sudo pour exécuter des commandes comme gpt ... ou newfs_hfs ... !

Suppression du MBR et modification de la table de partition GUID

• Entrez diskutil list y gpt -r show /dev/diskX (avec diskX : l'identifiant de votre disque interne (probablement disk0) pour avoir un aperçu. Dans les commandes ci-dessous, je suppose que l'identifiant du disque est disk0.

  Vous devriez obtenir la sortie suivante (les types peuvent être différents dans votre liste diskutil :

  -bash-3.2# diskutil list
  /dev/disk0
      #:                       TYPE NAME                    SIZE       IDENTIFIER
      0:     FDisk_partition_scheme                        *500.0 GB   disk0
      1:                       NTFS                         253.5 GB   disk0s1
      2:                       NTFS                         122.4 GB   disk0s2
      3:                       NTFS                         124.1 GB   disk0s3
  /dev/disk1...~/dev/disk12 belong to the recovery system
  
  -bash-3.2# gpt -r show /dev/disk0
        start       size index   contents
            0          1         MBR
            1  488493055     1   MBR  part  66
    488493056  248700928     2   MBR  part  66
    737193984  239577136     3   MBR  part  66
    976771120       2048

• Remplacez maintenant le MBR par une table de partition GUID :

  diskutil umountDisk /dev/disk0
  dd if=/dev/random of=/dev/disk0 count=1 bs=512
  gpt create /dev/disk0

• Ajoutez la partition EFI dans la table des partitions :

  gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk0

Maintenant vous pouvez soit deviner l'ancien contenu de la table de partition GUID, soit installer OS X sur une nouvelle partition - sans écraser vos anciennes partitions OS X - et essayer de détecter les tailles des anciennes partitions avec des outils appropriés (comme Test Disk/wxHexEditor).

Installation d'un nouvel OS X

Cela détruira le contenu de la ou des partition(s) Windows.

• Ajoutez une nouvelle partition dans la (vieille) partie OS X de votre disque pour la protéger.

  gpt add -b 409640 -i 2 -s 488083416 -t FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF /dev/disk0

  Cela pourrait être superflu.

• Ajoutez de nouvelles partitions dans la (vieille) partie Windows de votre disque. La première est une nouvelle partition système, la seconde une partition de récupération :

  gpt add -b 800000000 -i 4 -s 100000000 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0
  gpt add -b 900000000 -i 5 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0

• Vous devez maintenant formater les nouvelles partitions :

  diskutil list
  newfs_hfs -v "TempSystem" -J /dev/disk0s4 #use the proper partition found in diskutil list. It should have a size of ~50 GB
  newfs_hfs -v "Recovery HD" -J /dev/disk0s5
  diskutil mount /dev/disk0s4

• Quitter le terminal en entrant exit et l'abandonner.

• Ouvrir Restaurer OS X et installer OS X sur la partition TempSystem

• Configurez le nouveau système et activez l'accès à Internet. N'initialisez pas de volumes "inconnus" si on vous le demande.

• Activez l'utilisateur Root

• Déconnectez-vous en tant qu'administrateur et connectez-vous en tant que Root.

• Télécharger et installer wxHexEditor

Détectez le bloc de départ et le type de votre vieux volume OS X et le bloc de départ de votre vieux Récupération du disque dur avec wxHexEditor :

L'approche est similaire à celle de ma réponse ici : HFS+ nombre de blocs d'allocation invalide

Comme le bloc de départ d'une partition principale et la taille d'une partition de récupération ont des tailles/limites fixes, vous pouvez généralement calculer les entrées de partition GUID appropriées de votre ou vos anciennes partitions.

Conseil : En travaillant avec wxHexEditor, n'utilisez pas le copier-coller. Saisissez tout manuellement ! Vous pourriez accidentellement écrire directement sur votre disque.

• Partition JHFS+ ou CoreStorage ?

  Vous devez d'abord déterminer si vous aviez une partition JHFS+ ou CoreStorage à l'index numéro 2.

  Ouvrez la calculatrice. Ouvrez wxHexEditor. Vérifiez que vous travaillez en mode lecture seule ("Options" -> "Mode fichier" -> "Lecture seule"). Dans la barre de menu, allez dans "Devices" -> "Open disk device" -> choisissez le diskNumber approprié. Il s'agit probablement du disque 0. Le disque devrait avoir d'autres partitions (disk0s1 - disk0s5). Essayez de disposer la fenêtre wxHexEditor comme dans les exemples ci-dessous avec des lignes rouges droites.

  Ensuite, cliquez sur le bouton "Go to offset" (marqué par le cercle vert) et entrez 409640 exactement comme dans l'image ci-dessous. Parfois, vous devez le faire deux fois pour atteindre le bon secteur. Vérifiez à nouveau le secteur correct en entrant le décalage (marqué en rouge) dans la calculatrice et divisez-le par 512.

  Les trois premiers secteurs d'une partition CoreStorage ressemblent à ceci :

  Les 3 premiers secteurs d'une partition JHFS+ ressemblent à ceci :

  Si vous obtenez une image fondamentalement différente, arrêtez-vous ici.

• Où commence la partition Recovery HD ?

  C'est probablement la partie la plus difficile car vous devez trouver une chaîne de caractères qui n'est pas très spécifique. Sauter presque jusqu'à la fin de votre ancienne seconde partition (dans votre cas ~1000 Mo/1953125 secteurs de moins que 488493056 = 486539931)

  Puis entrez "HFSJ" comme dans l'image ci-dessous, recherchez cette chaîne deux fois et rendez-la lisible ! écrit à la main notes des différents décalages. Pour restaurer votre ancien OS X, vous devez ensuite démarrer en mode de récupération Internet et toutes les constatations à l'écran dans l'OS X temporaire actuel seront perdues !

  La raison pour laquelle il faut rechercher la chaîne "HFSJ" est que tous les volumes HFSJ+ contiennent cette chaîne dans le troisième secteur de leur partition. La chaîne peut également apparaître plus tard et à la fin !

  Vous pouvez avoir deux résultats vraiment différents selon le type de partition :

  1. Calculez le numéro de secteur de la première découverte. Dans mon exemple (voir image ci-dessus) c'est 68069452800/512=132948150. Continuez à chercher et calculez le secteur de la deuxième découverte. Dans mon cas, c'était 68069454848/512=132948154 (pas d'image). La différence entre les deux résultats est de 4 blocs (=2 KB).

     Ceci est typique de la limite entre une partition JHFS+ et le disque dur de récupération. Le disque dur de récupération commence alors au secteur de la deuxième découverte - 2 (dans mon exemple 132948154-2=132948152).

  2. Calculez le numéro de secteur de la première découverte. Dans mon exemple, c'était 67733904384/512=132292782 (pas d'image). Continuez à chercher et calculez le secteur de la deuxième découverte. Dans mon cas, c'était 68069454848/512=132948154 (pas de photo). La différence entre les deux résultats est de 655372 (~336 MB).

     Ceci est typique de la limite entre une partition CoreStorage et le disque dur de restauration. Le disque dur de récupération commence alors au secteur de la deuxième découverte - 2 (dans mon exemple 132948154-2=132948152).

Avec ces résultats, vous devriez être en mesure de restaurer votre GPT correctement. Quittez wxHexEditor. Si l'on vous demande de sauvegarder les modifications, ne le faites pas !

• Redémarrez en mode de récupération Internet et ouvrez le terminal

• Entrez diskutil list et gpt -r show /dev/disk0

• Retirez la deuxième partition (la partition de protection de type FFFFFFFF-FFFF-FFFF-FFFFFF-FFFFFFFFFF) :

  diskutil umountDisk /dev/disk0
  gpt remove -i 2 /dev/disk0

• Comme l'EFI et le Recovery HD ont généralement des tailles fixes, vous pouvez calculer le bloc de début et de fin de votre volume principal.

  Calculer la taille du volume principal : le bloc de départ est 409640. Le bloc de fin a été trouvé dans la section "Où commence la partition du Recovery HD" : 1 de moins que le bloc de départ du Recovery HD. La taille est donc StartBlockOfRecoveryHD-409640.

• Si vous avez trouvé un JHFS+ classique plus tôt, la commande suivante devrait réparer la partition 2 :

  diskutil umountDisk /dev/disk0
  gpt add -b 409640 -i 2 -s StartBlockOfRecoveryHD-409640 -t 48465300-0000-11AA-AA11-00306543ECAC disk0

• Si vous avez trouvé une partition CoreStorage plus tôt, la commande suivante devrait réparer la partition 2 :

  diskutil umountDisk /dev/disk0
  gpt add -b 409640 -i 2 -s StartBlockOfRecoveryHD-409640 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0

• Pour reconstruire le disque dur de récupération, entrez :

  diskutil umountDisk /dev/disk0
  gpt add -b StartBlockOfRecoveryHD -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0

• Vous pouvez maintenant essayer de monter et de vérifier votre ancien volume OS X :

  diskutil mount /dev/disk0s2
  diskutil verifyVolume /dev/disk0s2

  Si vous obtenez une erreur lors du montage ou de la vérification du volume, il se peut que ses limites soient erronées. Arrêtez-vous ici et consultez-moi.

• Si la vérification a réussi, vous pouvez soit démarrer sur votre ancien volume OS X et vérifier s'il fonctionne, soit supprimer l'ancienne version. TempSystem et le nouveau disque de récupération plus tard ou supprimer les deux immédiatement. L'inconvénient de démarrer d'abord sur votre ancien volume OS X est que vous devez démarrer en mode de récupération Internet une fois de plus pour supprimer TempSystem et le nouveau disque de récupération.

• Pour supprimer les deux partitions dispensables démarrées en mode de récupération Internet, entrez :

  diskutil list
  gpt -r show /dev/disk0
  diskutil umountDisk /dev/disk0
  gpt remove -i 4 /dev/disk0 # remove the partition starting at block 800000000
  diskutil umountDisk /dev/disk0 # remove the partition starting at block 900000000
  gpt remove -i 5 /dev/disk0

• Selon le type de partition (HFSJ+ ou CoreStorage), vous pouvez utiliser soit diskutil resizeVolume ... ou diskutil cs resizeStack ... pour développer votre volume OS X récupéré.

Estimer (deviner) les entrées de table de partition GUID appropriées

Le fait de deviner la partition fonctionne souvent parce qu'une " un volume visible " L'installation d'OS X a des blocs de départ et des tailles de toutes les partitions très caractéristiques :

Une carte de partition classique d'une installation de Yosemite sans aucune partition Boot Camp ressemblerait probablement à ceci sur votre Mac :

sudo gpt -r show disk0
      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   975093952      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  975503592     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  976773128           7 
  976773135          32         Sec GPT table
  976773167           1         Sec GPT header

Tous les blocs de départ et les tailles des partitions sont alignés sur des blocs de 4096 octets - ils sont tous divisibles par 8 (par exemple 975093952:8=121886744) !

Après avoir installé Windows avec l'assistant Boot Camp, la partition principale d'OS X est réduite et le disque dur de récupération est déplacé :

sudo gpt -r show disk0
      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   486813880      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  487223520     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  488493056   488280072      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  976773128           7 
  976773135          32         Sec GPT table
  976773167           1         Sec GPT header

La quatrième partition est la partition NTFS. Certaines installations de Windows ajoutent une deuxième partition EFI :

  488493056   488280072      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

->

  488493056      204800      4  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
  488697856   488075272      5  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Après avoir partitionné la partition Windows à partir de Windows, la carte de partition a été écrasée et remplacée par une carte de partition MBR :

gpt -r show /dev/disk0
      start       size index   contents
          0          1         MBR
          1  488493055     1   MBR  part  66
  488493056  248700928     2   MBR  part  66
  737193984  239577136     3   MBR  part  66
  976771120       2048

Maintenant, on peut supposer que les 488493056 premiers blocs (bloc 0 - bloc 488493055) sont intacts (à l'exception du MBT bien sûr) et représentent toujours l'ancienne partie d'OS X. Puisque vous avez déjà remplacé le MBR par une table de partition GUID et récupéré la partition EFI dans une étape précédente, vous n'avez plus qu'à restaurer la partition OS X principale et le disque de récupération.

Ici, l'hypothèse est la suivante : le dernier bloc de la première partition MBR est le dernier bloc du disque dur de récupération. En comptant à rebours, vous pouvez maintenant restaurer le disque de récupération et l'ancien volume OS X :

Taille fixe du disque dur de récupération : 1269536
Bloc de départ de la deuxième partition : 488493056 - 1269536 = 487223520 (le bloc de départ de la partition Recovery)

Le dernier bloc fixe de la partition EFI et le bloc de départ de la partition Recovery déterminent le bloc de départ et la taille du volume OS X :

Taille : 487223520 - 409640 = 486813880
Bloc de départ fixe : 409640

Maintenant, dérivez les commandes appropriées pour restaurer la table de partition GUID :

gpt add -b 487223520 -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0 # add the recovery partition
gpt add -b 409640 -i 2 -s 486813880 -t 48465300-0000-11AA-AA11-00306543ECAC disk0 # add the main OS X partition

Vérifier le volume principal avec :

diskutil verifyVolume /dev/disk0s2

Cette approche peut échouer car parfois de l'espace disque non alloué (généralement 2048, 102400 ou 204800 blocs) est ajouté par les outils de partitionnement de disque. L'espace disque non alloué peut être ajouté à la fin d'une partition MBR.

Après avoir accédé au Mac distant et inspecté le disque, la solution finale probable - suivant la partie wxHexEditor de la réponse - semble être la suivante :

gpt add -b 487222344 -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
gpt add -b 409640 -i 2 -s 486812704 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0

Puisque certains volumes montés existent sur le disque0 et que la partition de protection (i=2) doit être supprimée avant que les anciennes partitions d'origine puissent être restaurées, la file d'attente complète des commandes ressemble à ceci :

diskutil umountDisk /dev/disk0
gpt remove -i 2 /dev/disk0
diskutil umountDisk /dev/disk0
gpt add -b 487222344 -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
diskutil umountDisk /dev/disk0
gpt add -b 409640 -i 2 -s 486812704 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0