MacBook Pro Écran gris démarrage

Voir la pièce jointe 133241 "Bjr Macomaniac,
Merci pour ces instructions on ne peux pas plus claires.
Je n'ai pas réussi à ouvrir la page macgen... Parce que la date erronée de mon ordi fait qu'il ne reconnaît pas le certificat de Google, il me demande un mot de passe que je ne comprend pas et en suite ça bug... (Ce n'est pas le mdp admin).
Du coup je t'envoie la photo... En espérant que cela sera utile...
 
Je vois que le volume Macintosh HD est en format classique. Non chiffré.

Passe la commande :
Bloc de code:
diskutil info /Volumes/Mac*

  • respecte les espaces libres ; mets Mac* à la fin (abréviation commode)
  • la commande affiche un tableau d'informations sur le volume

Poste ce tableau.
 
J'ai du mal à transférer le fichier, le site m'envoie plusieurs messages d'erreur- du coup je fais la manip plusieurs fois, bref...
 
Une maintenance des forums a mis un bazar pas possible : il est quasi impossible d'ouvrir des fils et encore plus de poster...
 
Ça me rassure... Je commençais à penser qu'une force occulte m'empêchait d'aller au bout de la résurrection de ma machine...
Macomaniac, tu voudrait qu'on trouve un autre moyen de communication, où tu penses que la tempête sera passée bientôt?
 
Je pense qu'on peut continuer ici. Je vois ton tableau -->

- volume monté en lecture & écriture. Réinstallable. 335 Go d'occupation. Aucune anomalie formelle.​

Passe encore la commande :
Bloc de code:
diskutil verifyVolume disk0s2

  • le 0 de disk0s2 = zéro
  • la commande vérifie le système de fichiers jhfs+ (Mac OS étendu journalisé) > qui est le formateur du volume sur la partition
Poste l'affichage retourné.

----------

- question a) : aurais-tu un DDE USB avec dans les 400 Go de libres --> qui permettrait d'effectue une copie de Macintosh HD (via une commande du Terminal) ?​

- question b) : aurais-tu un câble SATA <=> USB (ou un boîtier SATA <=> USB) --> qui permettrait de brancher le HDD du Mac en externe (après l'avoir sorti du Mac) ?​
 
Ça a l'air d'être bon.

Ton idée est de faire une copie du hd et de remettre l'ordi à zéro?

Je n'ai pas de SATA, ni un deuxième Mac pour gerer ça, du coup j'essaye de trouver un disque au plus viteimage.jpeg
 
Aucune erreur dans le système de fichiers jhfs+ > formateur du volume Macintosh HD.

Comme tu l'as compris > l'idée est de suivre la procédure dite des « 4 r » : recopie > reformatage > réinstallation > récupération. Une opération un peu longuette mais qui a fait ses preuves. À l'arrivée > tu aurais un Système restauré de manière intègre + ton compte d'utilisateur et tes applications tierces récupérés à l'identique -->

- il sera facile de vérifier alors si l'OS restauré démarre et si tu peux réouvrir ta session.​

Il faut pour effectuer cette manœuvre que tu puisses disposer d'un DDE USB capable d'accueillir les 335 Go de données de Macintosh HD. En te faisant prêter cet appareil si tu n'en disposes pas.
 
Salut Macomaniac,

Ça y est, j'ai un disque... Je me pose la question, vu que tu vas me guider pour les 3 r, tu penses pas qu'on devrait se mettre dans un autre tropical plus adapté à la manip, je pense aux personnes qui pourront mieux bénéficier par la suite...
 
J'ai réussi a me connecter avec le Mac, mais je te laisse voir ce que ça donne... Peut être que c'est possible de reprendre du texte pour le coller sur le terminal, mais si c'est trop galère, je ferai avec de la patience...

image.jpeg
 
Je pense qu'on peut rester dans ce fil (autant que le parcours complet depuis le plantage jusqu'à sa solution se trouve exprimé d'un seul tenant).

Donc branche ton DDE au Mac. Puis dans le Terminal de la session de secours > passe les 2 commandes (l'une après l'autre) :
Bloc de code:
diskutil list
df -H

  • qui affichent la configuration des disques & l'occupation des volumes montés

Poste les 2 tableaux.
 
On a perdu pour l'instant tous les messages compris entre mercredi et dimanche : je crois qu'il vaut mieux attendre que le serveur fonctionne de nouveau normalement.

- quant à ta capture : il est clair que tu ne parviens pas à utiliser Safari pour accéder aux forums.​
 
On a perdu pour l'instant tous les messages compris entre mercredi et dimanche : je crois qu'il vaut mieux attendre que le serveur fonctionne de nouveau normalement.

- quant à ta capture : il est clair que tu ne parviens pas à utiliser Safari pour accéder aux forums.​
Je pourrai peut être trouver un autre disque (vide) utilisable plus facilement, tu en penses quoi?
Entre le décalage horaires et les bugs du site on n'avance pas très vite...
 
Le disque du DDE est disk13. Sa table de partition est GPT (GUID_Partition_Table). Le volume moovies relève d'une partition de type : Microsoft Basic Data. Il a 257 Go d'occupation et 743 Go d'espace dispononible.

- le type Microsoft Basic Data de la partition annonce un format Windows du volume. Passe la commande :​
Bloc de code:
diskutil info disk13s1

  • qui affiche un tableau d'informations sur le volume

Poste ce tableau --> il fera connaître la personnalité du système de fichiers qui est le formateur du volume sur la partition.

----------
 
On va reprendre où on en était > car on peut considérer les messages intercalaires entre vendredi et lundi comme perdus. Une perte qui pourrait se montrer critique > car faisait partie de ces messages perdus le tableau des blocs du DDE retourné par la commande gpt.

- or ce tableau de la distribution des blocs constituait le paradigme du descripteur de la partition de type "Windows_NTFS" sur ce disque. Surtout en établissant le 1er bloc de la partition > en tant qu'identique au super-bloc du système de fichiers ntfs du volume moovies. Supprimer le descripteur d'une partition dans une table GPT > sans connaître exactement le du bloc constituant le 1er bloc de la partition décrite --> a pour effet de ne pas permettre de recréer un descripteur reprenant à l'identique ce 1er bloc --> et donc de ne pas récupérer en bloc de tête de la partition le super-bloc du système de fichiers toujours écrit sur les blocs du disque. Ce qui équivant à perdre la capacité de redéfinir le volume de départ sur la nouvelle partition décrite.​

- heureusement > par un simple effort de mémoire --> je peux revisionner le tableau des blocs de ton DDE => ce qui me révèle que : une table alternative PMBR est inscrite sur le seul bloc n°0 > une table GPT primaire sur les blocs suivants 1 à 33 > qu'il n'y pas (d'une manière exceptionnelle) de partition de type EFI à partir du bloc n° 40 avec une extension de 409600 blocs comme c'est le défaut avec une GPT > mais que la partition de type "Windows_NTFS" commence abruptement au bloc n° 2048 en tant que 1er bloc --> lequel est donc le super-bloc du système de fichiers ntfs formateur du volume moovies. À partir de là > la partition de type "Windows_NTFS" a pour extension l'ensemble des blocs restants du disque moins les 33 derniers blocs où se trouve inscrite la GPT secondaire (une bande d'espace libre de 7 blocs entre la partition et la GPT secondaire n'ayant pas cours pour un type "Windows_NTFS" de partition comme c'aurait été le cas si la partition avait été de type "Apple_HFS").​

J'ai mentionné ce qui précède > pour le cas où tu aurais passé la dernière commande que j'avais donnée --> qui consistait en la suppression du descripteur de la partition du volume moovies. Afin de le vérifier > ton DDE branché au Mac > passe la commande (dans le terminal de la session de secours) :
Bloc de code:
diskutil list

  • et poste le tableau des disques

Si le disque du DDE montre une table de partition GPT sans la partition du volume moovies --> c'est que le descripteur aura été supprimé de la table et on pourra enchaîner à partir de là.

Note : depuis environ une semaine on devait subir des décrochages d'affichage des messages récents > des absences d'affichage dans les fils à pages nombreuses du dernier message posté > des désordres d'affichages des messages postés > des impossibilités d'édition d'un message posté => depuis hier lundi on subit carrément une suppression de tous les messages postés entre vendredi et lundi fin de matinée.
 
Théorie -->

- d'une manière "normale" --> un volume de format Windows n'est pas repartitionnable (de manière non destructive) > pour créer un second volume (qsui servirait ici de destination au clone). Càd. que le système de fichiers formateur du volume --> n'est pas adressable pour qu'il prenne en charge un rétrécissement de l'extension des blocs qu'il gère et libère ainsi de l'espace libre.​

- d'une manière "hors-norme" --> il est possible d'adresser la table de partition GPT de l'en-tête du disque > afin d'éditer le descripteur de la partition de type Microsoft Basic Data. Édition consistant en une unique modification de l'extension de blocs allouée à la partition. Cette édition de la taille d'une partition par suppression / recréation de son descripteur dans la table GPT --> a l'effet suivant : le système de fichiers Windows inscrit sur les blocs de départ de la partition n'est pas touché > non plus que ne le sont les blocs de la partition supportant les écritures des fichiers du volume. Mais le système de fichiers Windows se trouve abruptement confronté à une extension de blocs de la partition déterminée par la table GPT --> plus restreinte que ce que le gestionnaire de l'allocation des blocs (le space_manager) du système de fichiers comporte comme valeur enregistrée. En conséquence => une erreur de taille se trouve injectée dans le système de fichiers Windows de la partition. Cette erreur de taille n'invalide pas la capacité du système de fichiers à former le volume sur la partition > ce qui fait que le volume se trouve monté comme avant. Mais une erreur logique de taille se trouve incorporée à un des composants du système de fichiers (erreur réparable à la fin des opérations via la suppression du 2è volume et la redéfinition du descripteur de la partition à sa taille originelle).​

- la possibilité de cette manipulation "hors norme" --> découle du statut logiquement "équivoque" d'un volume : a) la partition de résidence d'un volume se trouve déterminée sur l'espace du disque par un descripteur de la table de partition (aucune partition n'existe donc "en soi" sur l'espace du disque > elle ne fait que s'y trouver "projetée" logiquement par un descripteur de la table) ; mais b) un volume se trouve formé sur l'espace imparti à la partition par une structure logique résidente de la partition elle : un système de fichiers dont le 1er bloc de la partition constitue le "super-bloc" (le bloc d'ancrage où réside son header). Ce système de fichiers inscrit sur l'en-tête de la partition --> assume l'extension de blocs définie par le descripteur de la table comme étant la taille de la partition => comme constituant son espace propre. Ainsi > l'espace que s'approprie un système de fichiers (comme espace dédié à un volume) --> lui est alloué extrinsèquement par une autorité supérieure qui est le descripteur de la table de partition. La manipulation hors-norme que j'ai décrite plus haut exploite cette "équivocité" du statut de l'espace : alloué par un descripteur de la table de partition vs approprié par un système de fichiers de l'en-tête de la partition. En modifiant la taille de l'extension allouée par la table à la partition --> le système de fichiers se trouve "forcé" d'adapter son appropriation d'espace (pour la formation du volume) à une allocation rétrécie. Il en résulte une "erreur de taille non invalidante". C'est en méditant sur le caractère "équivoque" (hétéroclite) de la définition d'espace d'un volume (sa double dépendance de la table et du système de fichiers) => que j'ai eu l'idée d'une révision de l'extension allouée par le descripteur d'une table à un volume déjà formé. Manipulation jamais documentée auparavant. L'effet produit passe l'épreuve de l'expérience (comme en témoignent une dizaine de cas des forums où j'ai dirigé cette opération) : les volumes pré-existants se trouvent préservés avec une taille rétrécie.​
 
Dernière édition par un modérateur:
J'ai du mal à comprendre l'intégralité, mais j'essaie de reformuler en langage néophyte: tu comptes mentir au disque par rapport à ces caractéristiques afin de faire oublier la partie Windows et pouvoir l'utiliser et faire des partitions Mac sans toucher les fichiers existants...?
Si c'est ça, je suis impressionné... Comme tu me dis que tu as déjà fait ça plusieurs fois, je suis partant!
Voici le nouveau tableau demandé:

Voir la pièce jointe 133472
 
Bonjour Macomaniac, entre les bugs et mon emploi du temps j'ai un peu lâché m'affaire, je reviens plein d'énergie...
Tu veux que je passe la commande diskutil lost pour voir où on est? Si c'est le cas, je pourrai faire ça dans une heure environ, le temps de rentrer.
 
On voit que la personnalité du système de fichiers (formateur du volumes moovies) = ntfs. Le volume n'est pas scriptible par macOS sans un pilote tiers dédié (genre Paragon). Pilote non disponible avec l'OS de secours.

Passe la commande :
Bloc de code:
gpt show disk13

  • la commande affiche le tableau de la distribution des blocs du DDE

Poste le tableau.
 
Les forums ont été secoués pendant une bonne semaine par des problèmes multiples d'affichage. Les choses paraissent rentrées dans l'ordre à présent mais ce fil-ci n'a pas été épargné par des pertes de messages critiques (notamment la perte du message affichant le tableau de la distribution des blocs du disque du DDE).

Oui : quand tu en as l'occation > ton DDE branché au Mac > passe la commande :
Bloc de code:
diskutil list

  • et poste le tableau des disques => que je voie où en est actuellement la configuration du disque de ton DDE.
 
Passe la commande préalable :
Bloc de code:
diskutil umountDisk force disk13

  • la commande démonte le disque du DDE (condition requise pour pouvoir écrire à la table GPT)

Poste le retour.
 
Je vois que tu n'as pas modifié la table de partition du DDE (le volume moovies est toujours là).

Passe la commande :
Bloc de code:
gpt show disk13

  • qui va afficher le tableau de la distribution des blocs du disque de DDE (on va récupérer ce précieux paradigme)

Poste le tableau.

Note : j'ai l'impression qu'il a encore un sacré désordre d'affichage dans ce fil...
 
Alors passe la commande :
Bloc de code:
gpt remove -i 1 disk13

  • la commande supprime le descripteur de la partition du volume moovies dans la table GPT. Cette suppression ne touche en rien le système de fichiers ntfs (dont le super-bloc est le n°2048) > non plus que les fichiers du volumes inscrits sur des blocs subséquents. Elle se contente d'écrire à la table GPT résidente des seuls blocs 1 > 33 du disque.

Poste le retour.
 
Je vois que tu n'as pas modifié la table de partition du DDE (le volume moovies est toujours là).

Passe la commande :
Bloc de code:
gpt show disk13

  • qui va afficher le tableau de la distribution des blocs du disque de DDE (on va récupérer ce précieux paradigme)

Poste le tableau.

Note : j'ai l'impression qu'il a encore un sacré désordre d'affichage dans ce fil...
Effectivement il y a du désordre...
image.jpeg
 
Hé ! hé ! le bloc de tête est bien 2048 comme dans mon souvenir.

Passe la commande :
Bloc de code:
diskutil umountDisk force disk13

  • qui démonte le disque du DDE

Poste le retour.
 
  • J’aime
Réactions: Federico NC