10.15 Catalina DD non reconnu au démarrage avec partition type FFFF

[Plinn]

Bonjour, j'ai le même type de problème que plusieurs présentés ici. J'ai lu pas mal de résolutions du forum et essayé pas mal de manip mais ai plutôt l'impression d'avoir empirer les choses.
Pour expliquer j'avais mon macbookpro (mi-2012 13") avec MacOs Catalina et Windows X avec Bootcamp. J'ai essayé d'y ajouté Linux, ça a foiré.. ^^ Je me suis donc retrouvé avec ma partition MacOs impossible à booter, de format FFFFF.....

Avant mes différentes manip, j'avais ça :



(désolé pour la qualité des photos)

Aujourd'hui, j'en suis là :



Et avec la commande gpt add j'ai constamment un retour "Ressource busy"

Voilà voilà, si vous avez un peu de temps pour me donner un coup de main avec tout ça, ça me rendrait un grand service !
Je ne sais pas trop si je fais bien de poster ça à la suite d'un problème du même ordre ou s'il aurait mieux fallut que je crée un nouveau post ?

 

[Membre supprimé 1060554]

Bonjour Plinn

Quand la partition affectée à macOS se trouve désignée dans un tableau de diskutil par :

FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

• c'est que le descripteur GPT (= l'entrée de la table GPT décrivant cette partition) a été corrompu en ce qui concerne le paramètre du "type de partition". Comme la partition était une partition originellement de type "Apple_APFS" > ce type était désigné par l'UUID = 7C3457EF-0000-11AA-AA11-00306543ECAC qui désigne universellement le type : "Apple_APFS". Mais cet UUID une fois corrompu dans le descripteur GPT de la partition => on obtient donc la mention de : FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF dans le tableau de diskutil - ce qui correspond à un "pseudo-UUID". Je ne peux pas dire ce qui a fait que le descripteur GPT de la partition macOS a été corrompu dans sa désignation de type de partition. Càd. ce qui a bien pu se passer lors de ta tentative d'installation de Linux pour qu'il y ait un effet de corruption sur le descripteur GPT de la partition macOS qui n'était pas a priori concerné par cette installation.

• lorsque cet incident de descripteur corrompu intervient --> le contenu des blocs de la partition concernée n'est pas affecté en principe. Ni donc le système de fichiers (inscrit sur les blocs de tête de la partiton) qui est le formateur d'un volume simple ou le générateur d'un conteneur logique > ni non plus les écritures des fichiers sur les blocs suivants de la partition. Il suffit donc de restaurer le type valide de la partition en supprimant le descripteur GPT correspondant > puis en le recréant de manière idoine. Opération qui ne touche aucunement les blocs de la partition > mais qui affecte uniquement la table GPT inscrite sur les blocs 1 > 33 d'en-tête du disque.

• ce qui me donne l'occation de préciser ce qui suit : une partition n'existe jamais "matériellement" sur un disque > au sens où les blocs de départ et de fin de cette partition ne sont pas marqués par des balises. Mais une partition existe toujours "logiquement" sur un disque > au sens où elle est décrite (dans son bloc de tête > son extension > son type et son rang) par la table GPT de manière "immatérielle" > et où c'est le moteur du Système démarré (le kernel) qui en lisant le descriptif de la partition "fait exister comme appareil logique" cette partition virtuellement projetée par la table de partition. Tout autre est la situation du système de fichiers formateur de volume ou de conteneur > et des fichiers qu'il gère : il s'agit là d'écritures matérielles sur les blocs correspondant à la partition > le bloc initial du système de fichiers coïncidant matériellement avec le bloc de tête logique de la partition. Cette petite esquisse "théorique" permet de conclure ceci : la corruption d'une partition dans la table GPT n'affecte que le descriptif logique (immatériel) de cette partition > sans affecter a priori les écritures matérielles de la partition. En restaurant la description logique de la partition => on peut donc récupérer les écritures intouchées des blocs de la partition. Car le kernel peut réactiver le système de fichiers et remonter le volume ou le conteneur qu'il forme, la condition de cette activation étant la coïncidence entre le bloc de tête logique de la partition décrite et le bloc initial matériel du système de fichiers.

Dans le contexte que je viens d'esquisser > la démarche que tu as suivie était tout à fait pertinente. Car tu as utilisé le terminal d'une session de secours pour tenter de supprimer le descripteur GPT corrompu > puis de le recréer de manière valide. C'est toujours ce qu'il convient de faire en cas de corruption d'un type de partition > et il n'y a pas d'autre mode d'intervention que le terminal pour cela. Ton intervention avait donc en principe toutes les chances de réussir > mais son succès a été compromis par l'intervention d'une variable intempestive.

 

[Membre supprimé 1060554]

En effet > la passation de ta commande = "gpt add ..." a été déniée par le message d'erreur :

Suspicious MBR at sector 0

• ce qui demande une explication. Sur tout disque Mac > la table GPT directrice inscrite sur les blocs 1 > 33 => se trouve toujours doublée par une table alternative MBR inscrite sur le seul bloc n°0 (1er bloc du disque). C'est ce bloc n°0 de résidence d'une MBR alternative qui est désigné comme "sector 0".

• la table MBR alternative du bloc 0 est susceptible de 2 formes logiques : une PMBR (Protective_MBR ou pseudo-MBR) vs une HMBR (Hybrid_MBR ou MBR au sens fort). Une PMBR est le défaut pour le bloc 0 : il s'agit d'une table MBR n'incluant qu'un unique descripteur (dans l'encodage MBR) > lequel décrit l'entièreté des blocs du disque (du n°1 ou second bloc => au dernier bloc = n° 1953525168 dans le cas de ton disque) comme constituant une partition unique de type EFI (hexcode : 0xEE). Le propre d'une telle description ne correspondant pas à celles de la GPT directrice => est que la PMBR "mono-descriptive" d'une partition de type EFI ne porte pas ombrage à la GPT principale > mais se trouve en quelque sorte neutralisée (invalidée).

• a contrario > la forme HMBR contient des descripteurs MBR de partitions du disque qui : a) empruntent à la table GPT directrice les déterminations de ces partitions (en bloc de tête > extension > type et rang) > mais b) les décrivent concurrentiellement selon l'encodage MBR. Dès qu'existe une HMBR sur le bloc 0 du disque > des descriptions concurrentielles des partitions (mode GPT vs mode MBR) existent donc en parallèle.

• une HMBR se trouvait automatiquement générée sur le bloc 0 dès la création sur le disque d'une partition de type Windows > dans les versions d'OS X allant de Lion 10.7 => à El Capitan 10.11. Cet effet d'ingéniérie logique servait à permettre un boot MBR des versions Legacy de Windows comme Windows-7 > quand il y avait installation dans un volume BOOTCAMP. Cette génération automatique d'une HMBR (par conversion de la PMBR par défaut) sur le bloc 0 a été abandonnée à partir de l'OS Sierra 10.12 > parce que la version contemporaine de Windows était devenue Windows 10 : OS de type UEFI bootant en mode GPT et plus MBR. Aucune création d'une partition de type Windows (Microsoft Basic Data = hexcode 0x07) dans un environnement Catalina > ce pour installer Windows 10 en boot GPT => n'induit plus de génération d'une HMBR sur le bloc 0 d'un disque Mac > mais préserve la PMBR par défaut.

• il est donc étonnant que sur ton disque il soit fait mention d'une "Suspicious MBR at sector 0" > désignée comme MBR tout court dans le tableau de la commande gpt => toutes choses montrant qu'une HMBR descriptive des partitions du disque existe sur le bloc 0. Quoi qu'il en soit des causes de cette conversion => tu tiens là ce que j'ai appelé la variable intempestive qui a fait échouer ta tentative de recréation d'un descripteur GPT valide de la partition macOS. Car si un descripteur MBR de la partition macOS existe la décrivant dans un type déterminé (qui peut être invalide) > il est impossible de rééditer dans la GPT le descripteur analogue avec un type de partition qui contredirait (ou même simplement redoublerait) celui du descripteur MBR. Effet de blocage tout à fait fâcheux dû à l'existence d'une HMBR sur le bloc 0.

On est alors contraint à une démarche préalable supplémentaire : supprimer dans la table MBR du bloc 0 le descripteur correspondant à la partition macOS => afin de libérer la possibilité de restaurer dans la GPT un descripteur valide de cette même partition. Cela peut apparaître compliqué logiquement > mais l'informatique est une chose compliquée en essence et seulement simple en apparence.

 

[Plinn]

Un grand merci pour ton explication. Je commençais à comprendre tout ça après la lecture de tes nombreux messages sur ce forum. Si tu te demandes comment sont apparues certaines des modifications, c'est probablement moi qui ai dû les faire manuellement en tâtonnant dans mes recherches. J'avais en effet compris que je n'empirerais pas tant le problème en bougeant les tables. Mais je ne comprenais pas bien le lien entre ces deux tables parallèles. J'avais en effet essayé de libérer l'écriture MBR du secteur 0 mais apparemment sans succès. Bon, je ne serai pas chez moi aujourd'hui mais aurai du temps demain pour me replonger un peu là dedans. Pourrais-tu me donner un coup de main ?
Merci en tout cas pour la clarté de toutes tes explications !

 

[Membre supprimé 1060554]

À demain alors pour la suite. Et je devance cette échéance avec quelques items -->

- Windows 10 était bien installé dans son volume dédié ? Démarrait-il encore après le plantage de l'installation Linux ? Avais-tu installé cet OS directement dans l'environnement Catalina et en mode UEFI (boot GPT) => ce qui se signalait à l'écran de choix du volume de démarrage par le choix de l'option : EFI Boot et pas Windows lors de l'installation ? - ou bien s'agissait-il d'une mise-à-niveau à Windows-10 d'un OS Legacy pré-installé avant Catalina genre Windows 7 ? - Windows 7 tributaire d'un boot MBR => ce qui expliquerait la préservation d'une HMBR sur le bloc 0 de ton disque (= héritage d'un installation ancienne dans un environnement d'OS X convertissant automatiquement la PMBR en HMBR dès la création d'une partition de type Windows) ?​

​

- et en effet : tant que tu manipules les tables de partition (GPT / MBR) sans reformatage => tu manipules des dispositifs descripteurs de partitions logiques > sans agir sur les écritures matérielles des blocs du disque. Donc si tu as le tableau primitif de la GPT (ce que tu as publié ici) => tu peux toujours envisager de recréer les partitions logiques à l'identique > et par là de permettre la réactivation (par le kernel) des systèmes de fichiers restés inscrits intacts sur les blocs > et donc le remontage des volumes qui en dépendent.​

​

- de ce point de vue j'ai une question : que s'est-il passé exactement entre les 2 tableaux du haut et celui du bas ? Car ceux du haut montrent les partitions au complet définies par la GPT > 2 d'entre elles étant invalides. Alors que celui du bas n'affiche plus de table GPT carrément > mais seulement la HMBR "vue sous l'angle GPT" > avec 2 seules partitions qui n'ont plus le statut de GPT part (partitions GPT) > mais de MBR part (partitions MBR).​

​

- enfin je te signale que l'intitulé du volume de secours démarré est : Mac OS X Base System. Cet intitulé avec le préfixe Mac n'est partagé que par les volumes de secours des 2 OS : Lion 10.7 & Mountain Lion 10.8. Volume de secours dépendant d'une image-disque qui a été téléchargée en RAM suite à un démarrage par internet. Il s'agit donc de l'OS de secours d'usine de ton Mac de 2012 : Mountain Lion va-t-on dire. Un OS antérieur à l'apfs et incapable d'en reconnaître le format ni le type de partition. Il convient donc que tu redémarres > les 3 touches ⌘⌥R (cmd alt R) tenues pressées ensemble (= seconde sorte de démarrage par internet supporté par ton Mac) => ce qui va télécharger en RAM un OS de secours correspondant au plus récent OS public = Catalina. Parfaitement apte lui à gérer le format apfs et son type de partition.​

 

[Plinn]

Bon, désolé, je ne suis pas dispo de manière très régulière en ce moment.
Pour te répondre, Windows était effectivement installé dans un volume dédié. De base j'avais installé Catalina puis installation classique de Windows 10 faite avec Bootcamp. Lorsque je bootais avec alt j'avais le cchoix entre mac ou windows. avec l'intitulé "windows". Puis j'avais essayé d'installer rEFInd pour tester le triple boot. C'est ça qui m'a rendu impossible le boot sur Mac OS.
Est-il d'ailleurs réellement possible de faire un triple boot sans réellement si connaitre avec tout ça ?

Pour l'effacement des tables, tout ce qui a bougé ensuite, c'est moi qui l'ai causé, essayant différentes commandes au fil de mes lectures de forums sans trop comprendre au début ce que je faisais....
Aujourd'hui la partition windows qui apparait est en fait une copie de l'ancienne partition windows. Et il me semble qu'elle ne démarrait plus non plus.

Oui, ça marche pour le ⌘⌥R, j'ai compris la distinction au cours de mes recherches, je redémarerai comme ça.
Pour ce qui est de la partition Windows je n'ai que peu de choses dedans et je peux encore y accéder lorsque je boot via un live linux par exemple. J'aimerais seulement récupérer la partition Catalina, pour ça que je m'étais aussi permis de supprimer le reste.

 

[Membre supprimé 1060554]

Donc on pourrait ne récupérer que la partition macOS et tu te débrouillerais ensuite pour réinstaller Windows si tu le souhaites ?

 

[Plinn]

Oui, tout à fait

 

[Membre supprimé 1060554]

Es-tu dans une session de secours Catalina actuellement (⌘⌥R) ?

 

[Plinn]

oui

 

[Membre supprimé 1060554]

Passe une commande :

diskutil list internal

• qui va n'afficher que la configuration du disque interne

Voici comment tu vas pouvoir poster ici ce tableau sans avoir besoin de prendre de photo -->

• 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 ...▾ (à droite de la bobine souriante) 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.

=> ces informations montreront la configuration logique actuelle de ton disque.

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.

 

[Plinn]

-bash-3.2# diskutil list internal
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 TB     disk0
   1:                       0xEE                         209.7 MB   disk0s1
   2:                  Apple_HFS MacOS                   182.2 GB   disk0s3
   3:               Windows_NTFS Windows                 141.6 GB   disk0s4

-bash-3.2#

Pour info, la partition en disk0s3 est un MacOS Mountain Lion installé avec la récupération

 

[Membre supprimé 1060554]

Il n'y a que la table HMBR inscrite sur le bloc n°0 du disque. La table GPT des blocs 1 > 33 a sauté.

- mais je note qu'une partition Apple_HFS se trouve décrite avec un volume affiché MacOS. Je crains qu'il n'y ait eu un reformatage : reste à savoir quels blocs se trouvent concernés.​

Passe la commande :

gpt show disk0

• et poste le retour => qu'on voie ce que donne la lecture gpt du disque.

 

[Plinn]

Non, pas de reform, ça j'en suis sur. Nouvelle partition Mountain Lion écrite à côté.

La partition Mac Catalina est restée comme dans les premières photos de 409640 à 1258854400. Mais n'a plus d'entrée dans la table
Ok, je fais ça

-bash-3.2# gpt show disk0
gpt show: disk0: Suspicious MBR at sector 0
       start        size  index  contents
           0           1         MBR
           1  1259264039         
  1259264040   355947664      3  MBR part 175
  1615211704         840         
  1615212544   276609024      4  MBR part 7
  1891821568    61703600         
-bash-3.2#

 

[Membre supprimé 1060554]

Es-tu actuellement dans une session de secours Catalina ?

 

[Plinn]

Je démarre la session. 7 min

 

[Membre supprimé 1060554]

Quand tu auras l'écran aux 4 Utilitaires macOS > passe les 2 commandes (séparément) :

diskutil list internal
gpt show disk0

• qui affichent : la configuration du disque interne & la distribution de ses blocs

Poste les 2 retours dans un Bloc de code => que je voie la situation présente.

 

[Plinn]

C'est bon, j'y suis. Je n'y ai pas touché depuis la dernière fois.

-bash-3.2# diskutil list internal
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 TB     disk0
   1:                       0xEE                         209.7 MB   disk0s1
   2:                  Apple_HFS MacOS                   182.2 GB   disk0s3
   3:               Windows_NTFS Windows                 141.6 GB   disk0s4

-bash-3.2# gpt show disk0
gpt show: disk0: Suspicious MBR at sector 0
       start        size  index  contents
           0           1         MBR
           1  1259264039         
  1259264040   355947664      3  MBR part 175
  1615211704         840         
  1615212544   276609024      4  MBR part 7
  1891821568    61703600         
-bash-3.2#

L'idée serait donc d'essayer de restaurer la partition Catalina diskOs2 présente de 409640 à 1258854400.

 

[Membre supprimé 1060554]

Passe la commande :

gpt create -f disk0

• la commande réinscrit une table GPT > l'option -f détruisant l'actuelle MBR (= HMBR) du boc 0 décrivant des partitions => pour la remplacer par une PMBR (table MBR par défaut décrivant l'entièreté du disque du bloc 1 au dernier bloc comme s'il s'agissait d'une partition de type EFI). La commande passe en mode muet si elle passe.

Si ça a été le cas > repasse ensuite une commande :

gpt show disk0

• et poste le nouveau tableau des blocs décrit en mode GPT.

 

[Plinn]

-bash-3.2# gpt create -f disk0
gpt create: unable to open device 'disk0': Resource busy
-bash-3.2#