10.15 Catalina SSD non reconnu au démarrage - Problème partition EFI

[Janusz Klucke]

Bonsoir, ma copine vient d’avoir un gros souci sur son MacBook Pro 2012. Impossible d’ouvrir la session, il y a un symbole avec un point d’interrogation à la place. J’ai tenté une réparation via l’utilitaire en passant par commande R mais impossible « Vous devez réparer la carte de partition car un problème s’est présenté avec le système de fichiers de la partition système de l’EFI ».

J’ai tenté de réinstaller l’OS mais impossible car le SSD ne monte pas. J’ai fait alt commande R et sur la console j’ai entré la commande diskutil list internal et là aucune trace de l’EFI ! Y a t-il un super héros pour venir à mon secours s’il vous plait ?

 

[Membre supprimé 1060554]

Bonsoir JK

Est- ce qu'on peut réinitialiser le SSD ? - est-ce que c'est bien Catalina qui est proposé à la réinstallation par l'option : "Réinstaller macOS" (dans la fenêtre d'accueil des 4 Utilitaires macOS) ?

 

[Janusz Klucke]

Réinitialiser le SSD n’est pas mon objectif car elle veut coûte que coûte récupérer toutes ses données qui sont extrêmement importantes et malgré mes avertissements elle n’a pas de sauvegarde... Oui c’est bien Catalina qui est proposé.
—————————————————————
Désolé Ouroboros je ne t’ai pas salué merci de t’être manifesté. Je suis exténué j’y suis depuis 14h

Macomaniac pardon ...

 

[Membre supprimé 1060554]

Voici la configuration actuelle du SSD :

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                         500,1 GB   disk0
   1:                       0xEE                         500,1 GB   disk0s1

• la table de partition est mentionnée FDisk_partition_scheme (= MBR ou schéma Windows) à la place de GUID_partition_scheme (= GPT appropriée à un disque de démarrage Mac).

• une unique partition est affichée > avec seulement un type : 0xEE. Il s'agit du hex code (encodage MBR) d'un type de partition EFI qui couvrirait la totalité de l'espace du disque de démarrage.

Interprétation : je pense que la table de partition GPT du disque a sauté > et qu'est restée seule la table alternative MBR qui réside sur l'unique bloc n°0 (1er bloc du disque). Qu'est-ce qui s'est passé pour que la table GPT principale du disque (celle qui définit les partitions) saute ?

- note : il y a toujours 2 tables de partition concurrentes sur un disque Mac : une MBR de type protecteur sur le bloc n°0 > qui décrit l'entièreté du disque comme une partition de type EFI > et une GPT directrice sur les blocs suivants 1 > 33 qui décrit les partitions effectives du disque.​

 

[Janusz Klucke]

Et bien justement c’est bien un mystère... elle travaillait dessus ce matin nous nous sommes absentés pour aller au marché en laissant l’ordi en veille et dès notre retour l’ordi était buggé. Elle a donc forcé l’extinction et point d’interrogation...

Macomaniac, es-tu en train de te préparer à me dire que les données sont perdues ?

 

[Membre supprimé 1060554]

Bon. Passe la commande :

gpt show disk0

• qui affiche l'actuelle distribution des blocs du disque

Voici comment tu vas pouvoir poster ici ce tableau sans avoir besoin de prendre de photo (ça vaudrait mieux pour la suite) -->

• tu sélectionnes le tableau > ⌘C pour le copier dans le presse-papier > ⌘Q pour quitter le «Terminal» > option  : "Obtenir de l'aide en ligne" (dans la fenêtre des 4 Utilitaires) > ce qui lance un navigateur «Safari»

• page Apple par défaut > un clic sur l'adresse de haut de page pour l'éditer > saisis  : macgénération (tout court  : c'est une barre de recherche Google) et valide > tu atteins le site MacGé > Forums > te connectes > ce fil

• en bas de cette page des forums MacGé => utilise le menu ⫶ (le 16è depuis la gauche = vers le milieu de la barre) dans la barre de menus au-dessus du champ de saisie d'un message > sous-menu : </> (= Bloc de code) => tu fais ton coller dans la fenêtre de code et Continuer.

Note 1 : si tu ne peux pas poster via le Safari de la session de secours (ça arrive) --> poste une photo du tableau comme tu as déjà fait.

Note 2 : dans la session de secours > les applications se lancent en mode "alternatif" et pas parallèle. Il faut quitter le Terminal pour lancer Safari. Vice-versa > quitter Safari pour récupérer l'écran général de la session de secours et pouvoir relancer le Terminal. Aucun redémarrage n'est requis.

----------

Question : quel était l'OS installé avant le plantage ? - Catalina aussi ou un autre OS ? - et remarque : il est envisageable de reconstruire la table GPT directrice > mais c'est une opération délicate disons.

 

[Janusz Klucke]

-bash-3.2# gpt show disk0
      start       size  index  contents
          0          1         PMBR
          1  976773134         
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header
-bash-3.2#

Oui c'était Catalina. Envisageable de reconstruire la table GPT ? Je me débrouille bien en informatique mais je t'avoue que je ne sais pas ce que cela peut entrainer. Si cela n'efface pas les données je veux bien essayer.

Et si c’est le seul moyen de récupérer les données je le ferai mais je n’ai pas les compétences pour le faire seul.

 

[Membre supprimé 1060554]

Hé ! hé ! je comprends tout -->

- il y a toujours une table MBR alternative sur le bloc 0 > de type PMBR (Protective_MBR). C'est elle seule qui décrit actuellement le disque du Mac comme s'il n'était constitué que d'une unique partition de type EFI.​

​

- il y a encore en queue de disque (sur les 33 derniers blocs) la sauvegarde de la table GPT directrice (intitulée ici Sec GPT = Secondary GPT). Ce backup de la table GPT directrice qui occupait les blocs n°1 > 33 d'en-tête du disque peut peut-être servir comme base pour reconstruire la table GPT principale. Si ça ne fonctionnait pas => je sais exactement comment recréer à la main la GPT directrice.​

Passe la commande :

gpt recover disk0 ; diskutil list internal

• tu peux la passer en copier-coller à rebours : copier ici avec Safari > coller dans le terminal > exécution

• la commande restaure la GPT directrice d'après le backup de la GPT secondaire préservée > puis affiche la configuration interne résultante

Poste le retour.

Note : on ne manipule actuellement que l'espace de boot (des tables de partition) du disque > sans aucune sur-écriture des blocs suivants qui portent les systèmes de fichiers des volumes.

 

[Janusz Klucke]

-bash-3.2# gpt recover disk0 ; diskutil list internal
gpt recover: disk0: recovered primary GPT table from secondary
gpt recover: disk0: recovered primary GPT header from secondary
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *500.1 GB   disk0
   1:                       0xEE                         500.1 GB   disk0s1

-bash-3.2#

As tu une idée de la raison de cet accident ?

 

[Membre supprimé 1060554]

La table GPT directrice est déclarée récupérée > mais le kernel (le moteur logique de l'OS de secours démarré) ne paraît pas s'en être aperçu.

- passe la commande :​

diskutil repairDisk disk0 ; diskutil list internal

• à validation > une demande de confirmation s'affiche : tape y (yes) et revalide

• la commande répare la GPT censément recréée puis affiche la configuration interne

Poste le retour.

Note : aucune idée de la cause de la disparition de la GPT directrice.

 

[Janusz Klucke]

bash-3.2# diskutil repairDisk disk0 ; diskutil list internal
Unable to repair this whole disk: A GUID Partition Table (GPT) partitioning scheme is required (-69773)
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *500.1 GB   disk0
   1:                       0xEE                         500.1 GB   disk0s1

-bash-3.2#

Pas de demande de confirmation...
C'est pas bon signe...

 

[Membre supprimé 1060554]

Passe la commande :

diskutil mountDisk disk0

• qui remonte le disque interne de ses volumes --> une façon de forcer le kernel à prendre en charge la GPT recréée (si c'est bien le cas)

Poste le retour.

 

[Janusz Klucke]

-bash-3.2# diskutil mountDisk disk0
Volume(s) mounted successfully
-bash-3.2#

 

[Membre supprimé 1060554]

Hé ! hé ! --> volumes remontés avec succès.

- repasse la commande :​

diskutil list internal

• et poste le retour.

 

[Janusz Klucke]

-bash-3.2# diskutil list internal

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *500.1 GB   disk0
   1:                       0xEE                         500.1 GB   disk0s1

-bash-3.2#

 

[Membre supprimé 1060554]

Bon. Repasse la commande :

gpt show disk0

• et reposte la distribution des blocs du disque.

 

[Janusz Klucke]

-bash-3.2# gpt show disk0
      start       size  index  contents
          0          1         PMBR
          1  976773134         
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header
-bash-3.2#

 

[Membre supprimé 1060554]

Bon : il est clair que la table GPT directrice n'a pas été recréée à sa place. On bascule sur le plan B : recréation à la main.

- passe d'abord la commande :​

diskutil eraseDisk free null gpt disk0 ; gpt show disk0 ; diskutil list internal

• attention à bien interpréter le sens de cette commande : elle recrée la GPT directrice sur les blocs 1 > 33 du disque > et la partition EFI associée sur les blocs 40 > 409600 > mais n'effectue aucun reformatage des blocs suivants en laissant le reste de l'espace disque en espace libre. Puis elle affiche la distribution des blocs > enfin la configuration manifeste du disque

Poste le retour.

 

[Janusz Klucke]

-bash-3.2# diskutil eraseDisk free null gpt disk0 ; gpt show disk0 ; diskutil list internal
Started erase on disk0
Unmounting disk
Creating the partition map
Error: -69825: Wiping volume data to prevent future accidental probing failed
      start       size  index  contents
          0  976773168         
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *500.1 GB   disk0

-bash-3.2#

 

[Membre supprimé 1060554]

Il y a eu un échec d'écriture au disque. Si le Mac est le célèbre MacBook Pro 13" mi-2012 > notoire pour la défaillance de sa nappe SATA avec le temps => je dirai qu'il y a un problème de la nappe SATA qui relie le disque au processeur.