DDI non reconnu au démarrage, partition type FFFF

[Saucy]

Bonjour,

Je vous met en situation :
Je souhaite installer une version de linux en dualboot sur mon macbook pro.
Je formate une clé usb pour permettre l’installation de mon os.
Avant d'installer mon os, je partitionne 25Gb de mon disque dur interne pour ce nouvel os.
L'installation commence, je suppose que j'ai du faire une fausse manip dans mon terminal en sélectionnant le mauvais disque car lorsque je reviens sur mon os mac, le disque dur interne qui me servais à boot est reconnu comme externe (ce qui me met la puce à l'oreille sur ce que ça pourrais entraîner comme soucis ...)
Je décide de redémarrer mon mac en maintenant la touche alt enfoncée pour choisir mon disque de démarrage, et là surprise, le disque dur principal n’apparaît plus.

Je redémarre en mode sans échec (Pomme+R) et me dirige dans l'utilitaire de disque.
Voici ce que j'observe :

Je décide ensuite d'aller dans mon terminal pour faire un

diskutil list

et voici ce que j'observe :

/dev/disk1 (internal, physical):
0: GUID_partition_sheme *251.0GB disk1
1: EFI EFI 209.7MB disk1s1
2: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF 228.8BG disk1s2
3: Linux Filesystem 4.9GB disk1s3
4: Apple_APFS 16.9GB disk1s4

A ce stade, le support Apple n'a pas réussi à m'aider et tout ce que je souhaite c'est récupérer certains fichiers sur mon mac sans lesquels je ne peux travailler !
Je n'ai pas de sauvegarde Time Machine ...
Faire une image de mon disque nécessite 250Gb d'espace libre que je n'ai malheureusement pas à ma disposition.

Merci d'avance à ceux qui souhaitent m'aider à trouver une solution, si vous avez besoin de plus de renseignements, je suis disposé à vous les fournir !



Note de la modération: pas trop de rapport avec les portables Mac, je déplace dans le forum adéquat.

 

[r e m y]

La version de macOS c'était bien 10.13 (HighSierra)?

Là j'ai l'impression que la structure APFS du SSD a volé en éclats... ton dernier espoir est de faire appel à Magic Macomaniac, mais j'ai peur que ce soit irrécupérable.

 

[Saucy]

Oui dernière mise à jour High Sierra 10.13

Vraiment aucun moyen de récupérer ce qu'il y a dedans ?
Quelle démarche à suivre pour MagicMacomaniac ?

Merci.

 

[r e m y]

Macomaniac ne devrait pas tarder à intervenir sur ce fil de discussion. C'est le type de problème auquel il aime bien se confronter.

Peut-être saura-t-il reconstituer proprement la structure du formatage APFS, mais j'ai quand même de grosses craintes que ce ne soit pas possible.

 

[bompi]

Je profite de l'occasion pour rappeler une bonne pratique : lorsqu'on veut installer Linux (ou un autre système, comme FreeBSD) sur son Mac, il faut préparer le partitionnement depuis macOS, par exemple avec un démarrage sur la partition de secours.
En effet, la gestion des partitions est devenue particulièrement compliquée avec les dernières versions de macOS et les seuls outils capables de bien gérer les tables des partitions sont ceux de macOS.

Donc :

• créer la partition de swap et la (ou les) partitions systèmes/données de Linux avec macOS, en les formatant en FAT pour mieux les identifier
• ensuite, lorsqu'on démarre sur la clef de Linux pour l'installation, on a juste à définir les points de montage et demander un formatage des partitions.

Pour le problème d'aujourd'hui, je dirais que là, c'est fichu : il faut espérer que tu avais fait des sauvegardes au préalable...
Tu vas sans doute devoir tout réinstaller donc :

• installer macOS avec réinitialisation du disque ;
• en profiter pour préparer le terrain des partitions (au moins deux pour Linux, une de n GB correspondant à la RAM et une de k GB pour le système et les données ; une pour macOS) ; l'ordre dépend surtout de ce que tu comptes faire : si tu gardes Linux, autant créer ses partitions en début de liste mais si c'est juste pour un test, autant les mettre à la fin de la liste
• réinstaller macOS
• installer Linux.

 

[Saucy]

L'erreur viens bien de moi malheureusement ... J'avais préparé ma partition avec le gestionnaire de disques mac, mais j'ai du me précipiter dans l'installation de Linux et sélectionner le mauvais disque.
Sur ce disque j'ai des fichiers d'une très grande valeur et auxquels j'apporte grande importance. Je n'ai pas de sauvegarde time machine, j'espère que je ne serais pas contraint de formater complètement le disque et perdre tout son contenu.

En faisant des recherches, je ne suis pas le seul à qui s'est arrivé :
http://fr.appledv.com/type-de-partition-ffffffff-ffff-ffff-ffff-ffffffffffff-macbook-pro.html
Apparemment c'est réparable dans le cas ci dessus.

Je continue les recherches de mon côté, si quelqu'un a une idée ou une suggestion, qu'il n'hésite pas !

 

[Membre supprimé 1060554]

Salut Saucy

Voici la configuration du SSD retournée par diskutil list -->

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *525.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:   FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF             228.8 GB   disk1s2
   3:           Linux Filesystem                            4.9GB   disk1s3
   4:                 Apple_APFS                           16.9GB   disk1s4

La question se concentre sur la partition n°2 (disk1s2) de 228 Go --> pourquoi se trouve-t-elle décrite par le "pseudo" UUID = FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF ?

----------

la 1ère conjecture que j'ai formulée est la suivante : cette partition qui était la base d'exportation d'un Conteneur apfs avec ses 4 volumes étant illisible --> il est impossible qu'un démarrage par ⌘R ait fait démarrer le Mac sur l'OS de secours local > car cet OS réside dans le volume apfs Recovery --> son lancement impliquerait nécessairement que la partition d'exportation du Conteneur apfs soit lisible --> ce qui n'est pas le cas. On pourrait concevoir alors que la commande aurait été redirigée sur un démarrage par internet permettant de lancer l'OS de secours correspondant à l'OS d'usine du Mac téléchargé en RAM. Cet OS antérieur à l'apfs ne saurait pas identifier ce format et y substituerait un UUID.

Cette conjecture séduisante (par ses promesses de solution express = démarrer sur un OS de secours 10.13) est manifestement fausse pour 2 raisons -->

• un OS antérieur à l'apfs et incapable d'identifier ce format --> ne désigne jamais la partition apfs par un "pseudo" UUID = FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF > mais toujours par l'UUID de la partition qui lui est lisible (indépendamment du système de fichiers contenu). Donc on aurait eu affaire à un UUID vrai > ce qui n'est pas le cas

• la partition n°4 > quoiqu'aucun Conteneur incluant au moins un volume ne s'en trouve exporté --> est très bien identifiée en tant qu'ayant un type : Apple_APFS. Ce constat détruit la conjecture qu'on aurait affaire à un OS d'usine incapable d'identifier un type APFS de partition. Soit on a bien affaire à l'OS de secours correspondant à l'OS d'usine du Mac > mais cet OS est alors Sierra 10.12 capable de reconnaître et de manipuler l'apfs (le Mac est alors très récent) > soit le démarrage par internet a été redirigé sur le téléchargement d'un OS de secours de type 10.13.

En ce qui concerne cette question secondaire --> elle est facile à régler : dans le panneau des 4 Utilitaires macOS > quel est l'OS proposé à la ré-installation si tu simules le lancement de cette option ?

----------

Note : je suis obligé de répartir mon topo en 2 messages > à cause d'une nouvelle limitation du nombre de caractères par message.

 

[Membre supprimé 1060554]

[Suite]

Le raisonnement précédent peut paraître un exercice vain de la spéculation. Non pas, car il conduit nécessairement à une réponse à la question : "pourquoi la partition n°2 se trouve-t-elle décrite par le "pseudo" UUID = FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF ?

La réponse est : le type "Apple_APFS" de la partition disk1s2 a été corrompu par une tentative d'installation de Linux. Càd. l'hex code associé à la partition n°2 dans la table GPT est soit "foireux" > soit "inapproprié". Cette corruption du code déterminant le type de la partition dans la table GPT --> fait que diskutil est obligé de la désigner par un "pseudo" UUID.

Rien de plus aisé que de restaurer le type adéquat de la partition disk1s2 (càd. de lui restituer son hex code approprié dans la table GPT). Passe la commande (avec exactitude) -->

asr adjust --t /dev/disk1s2 --settype "Apple_APFS"

• cette commande asr non documentée établit à Apple_APFS le type de la partition disk1s2

Attention ! --> cet emploi d'asr est fréquemment délicat. Si tu obtiens le retour -->

asr: Volume adjustment failed: Invalid argument

• ne te démonte pas --> fais se réafficher la même commande dans le Terminal en pressant la touche de navigation ▲ (dans le carré des 4 touches de navigation dans la partie droite inférieure du clavier) et ré-exécute la même commande :

asr adjust --t /dev/disk1s2 --settype "Apple_APFS"

• tu devrais obtenir le retour :

Adjust completed successfully

• (ce qui a peut-être été le cas d'entrée de jeu)

Dans ce cas --> ne t'imagine pas que le kernel en exercice (celui de l'OS de secours en RAM) va instantanément charger la modification du type de la partition n°2 dans la table GPT --> il faut que tu redémarres une fois (Menu  > Redémarrer) > et tiens aussitôt pressées les 3 touches ⌘⌥R (cmd alt R) --> pour être sûr de télécharger en RAM un OS de secours 10.13.

Quand tu auras récupéré une session de secours > passe alors une commande :

diskutil list

• et poste le tableau en utilisant ce procédé pour ton "coller" -->
  
  
  • dans la page de ce fil de MacGé > presse le bouton ⌹ (carré avec un + inscrit - juste au milieu de la largeur de la fenêtre totale) dans la barre de menus au-dessus du champ de saisie d'un message > menu  : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)

=> si l'installateur de Linux n'a corrompu que le type de la partition sans reformater --> tu devrais avoir ton Conteneur APFS redéployé avec tous ses volumes comme au sortir d'une pochette surprise. S'il y a eu reformatage du système de fichiers de la partition --> je ne peux plus rien faire.

 

[Saucy]

Tout d'abord, je te remercie pour cette analyse très poussée du problème.
En revanche comme tu l'as prédit, la commande asr adjust --t /dev/disk1s2 --settype "Apple_APFS"
renvoie l'erreur asr: Volume adjustment failed: Invalid argument
Peu importe que je le fasse 1 ou 15 fois :/
Je vais tenter de redémarrer en mode sans échec et tester de nouveau la commande !

 

[Membre supprimé 1060554]

Si tu n'arrives pas à restaurer le type de la partition principale à Apple_APFS en utilisant asr (ce qui était le procédé le plus simple) --> je peux te proposer un procédé alternatif.

• d'abord --> il faut que ton Mac soit bien démarré sur un OS de secours de type 10.13. Regarde quel OS t'est proposé à l'option : "Ré-installer macOS" de la fenêtre des 4 Utilitaires macOS. Tu peux redémarrer en tenant pressées les 3 touches : ⌘⌥R (cmd alt R) --> ainsi tu seras sûr d'accéder à une session de secours de type 10.13.

• ensuite --> il faut que tu sois sûr de l'index de disque du SSD interne. Rien ne dit qu'il ne sera pas disk0 au lieu de disk1 (je me demande même si > quand tu as passé la commande asr > l'index du SSD était bien disk1 et pas disk0). Donc passe la commande :

  diskutil list

  et vérifie l'index de disque du disque interne. Je vais supposer que c'est toujours disk1 (ce qui m'étonne > le disque interne étant régulièrement indexé disk0). Si l'index était disk0 > tu le changes en rapport dans la commande qui suit.

• enfin > tu passes la commande (simplement informative à ce stade) -->

  gpt show /dev/disk1

  (utilise l'index de disque adéquat à la fin) --> la commande recourt à l'exécutable gpt (guid_partition_table_uti-lity) > pour afficher le tableau de la distribution des blocs du SSD : secteurs des tables de partition > secteurs des partitions > secteurs des espaces libres > secteurs de la sauvegarde de la GPT principale

Poste ce tableau ici en utilisant le procédé suivant -->

• 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 

• dans la page de ce fil de MacGé > presse le bouton ⌹ (carré avec un + inscrit - juste au milieu de la largeur de la fenêtre totale) dans la barre de menus au-dessus du champ de saisie d'un message > menu  : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)

=> ce tableau me permettra de te passer 2 commandes qui restaureront le type de la partition n°2 du SSD à "Apple_APFS". C'est uniquement si on parvient à restaurer le type de la partition n°2 à "Apple_APFS" dans la table de partition GPT de l'en-tête du disque --> que tu as une chance de récupérer ton Conteneur apfs avec ses volumes - dont le volume de démarrage principal. Car c'est le descripteur de cette partition dans la GPT qui est corrompu actuellement --> il convient donc de restaurer ce descripteur GPT.

 

[Saucy]

-bash-3.2# gpt show /dev/disk1
      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  446856320      2  GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
  447265960        856        
  447266816    9666560      3  GPT part - 0FC63DAF-8483-4772-8E79-3D69D8477DE4
  456933376   33038336      4  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  489971712     263007        
  490234719         32         Sec GPT table
  490234751          1         Sec GPT header

 

[Saucy]

edit : J'ai installer un OS de secour, pour je ne sait quelle raison il s'est déployé en 10.12 (Sierra) o_O
La commande d'assignation asr ne fonctionne toujours pas. Je vais mettre à jour mon OS de secours en 10.13 (High Sierra) et voir si je peux réessayer les manips cités plus haut !
edit : Impossible de mettre à jour l'os de secour ! Il est bloqué en 10.12 (Sierra)

Voici mon tableau :

MBPdeAlexandre2-001:~ alex$ sudo gpt show /dev/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  446856320      2  GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
  447265960        856       
  447266816    9666560      3  GPT part - 0FC63DAF-8483-4772-8E79-3D69D8477DE4
  456933376   33038336      4  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  489971712     263007       
  490234719         32         Sec GPT table
  490234751          1         Sec GPT header

 

[Membre supprimé 1060554]

Je suis connecté --> est-ce que tu es prêt de ton côté ?

Note : même si tu as installé un OS de secours (dans un volume de la partition n°4 je le présume) --> tu ne peux pas faire les manipulations que j'envisage en étant démarré dessus.

En effet, l'utilitaire de tierce partie gdisk (capable d'écire à la table de partition GPT d'un disque en mode "live") --> ne sait pas gérer le type "Apple_APFS" d'une partition.

Or l'utilitaire gpt qu'il s'agit d'utiliser > lui > est incapable d'écrire à la table GPT d'un disque en mode "live" (un volume au moins défini par cette table qui soit monté). Il faut que tous les volumes du disque concerné soient démontés. Donc tu ne pourras passer les 2 commandes gpt que j'envisage qu'après être démarré par internet par ⌘⌥R --> ce fait que ton Mac sera démarré à la fin sur un OS de secours 10.13 en RAM = indépendant du disque. Ce qui permettra de démonter le volume dans lequel tu as installé ton OS Sierra.

=> fais signe dans ce fil quand tu seras disponible.

 

[Saucy]

Disponible, je redémarre en mode internet !

 

[Membre supprimé 1060554]

Disponible moi aussi --> fais signe quand tu y es.

 

[Saucy]

J'y suis.

 

[Membre supprimé 1060554]

Commence par passer la commande :

diskutil list

• qui affiche le tableau des disques

Poste ce tableau --> je veux voir ce qu'il en est du volume que tu as dû créer sur la partition n°4. Ça me donnera aussi l'index de disque du SDD.

 

[Saucy]

-bash-3.2# diskutil list
/dev/disk0 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +2.1 GB     disk0
   1:                  Apple_HFS OS X Base System        2.0 GB     disk0s1

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF               228.8 GB   disk1s2
   3:           Linux Filesystem                         4.9 GB     disk1s3
   4:                 Apple_APFS                         16.9 GB    disk1s4

/dev/disk2 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +5.2 MB     disk2

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *30.8 GB    disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS Disk                    29.9 GB    disk3s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk3s3

/dev/disk4 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk4

disk3 est ma clé usb sur laquelle se trouve l'os de secours. Je peut la retirée au besoin.

 

[Membre supprimé 1060554]

Ah oui ! je vois que tu as installé ton OS de secours sur un disque externe. Aucun volume n'est à démonter sur le SSD > qui est redevenu disk1 (il faut toujours vérifier).

Passe la commande :

gpt remove -i 2 /dev/disk1

• la commande supprime le descripteur de la partition de rang 2 du disk1 dans la table GPT

• cette suppression du descripteur n'affecte en rien les écritures portées sur les blocs du disque correspondant à la partition > dont le système de fichiers APFS dont les headers (en-têtes) continuent de résider sur les premiers blocs correspondant à la partition

=> est-ce que tu as obtenu comme retour de commande un -->

/dev/disk1s2 removed

• ou pas ?

 

[Saucy]

Je confirme, j'ai bien un retour :

/dev/disk1s2 removed