10.10 Yosemite Impossible de démarrer, situation étrange

[Saxobar]

Bonsoir !

Alors voila, c'est un la première fois qu'OSX me tien en échec comme ça. C'est pas que je sache particulièrement comment tout fonctionne, mais en général j'arrive a comprendre, et grâce à vous tous je trouve des solutions viables. Mais la...

Je vous explique :
MacBook Pro 13" de 2009 (la fin je crois)
OSX 10.10

- Au re-démarrage, après un arrêt forcé, icône de rond barré. Je n'en sais pas beaucoup plus sur les conditions de cet arrêt forcé, la cause, etc.
- J'arrive à monter le disque en mode disque cible dans un autre mac et copier des données. Les réparations de l'utilitaire de disque se passe bien selon lui, rien a faire, tout roule.
- Par contre, impossible de démarrer sur la partition de Recovery, et aucun mode de démarrage avancé ne fonctionne. réinitialiser la nvram non plus. Les démarrages dans ces cas se soldent par un affichage rapide de ligne de texte blanc sur fond noir.
- finalement, le rond barré n'apparait plus que rarement. A la place, la pomme apparait, avec la barre de chargement. Le chargement dure treeeees longtemps (en fait se bloque a moitié) et quelque bonnes dizaines de minutes plus tard : le même texte. Je vais essayer de faire une photo, mais ça arrive on ne sait pas quand et ça part vite.

Petite particularité étrange :
- un autre MacBook Pro parvient a démarrer le système du mac en panne, passé en disque cible
le problème n'est donc pas OSX, ni le disque dur.
- le mac en panne parvient a démarrer le système de l'autre MacBook Pro, a son tour passé en mode disque cible. (OSX10.9, il me semble)
le problème ne vient donc pas de la ram, de la carte mère, ou de je ne sais quel programme interne, a priori.
toujours impossible pour le mac en panne de démarrer son propre système.
MAIS ALORS POURQUOI ?

Bon, qu'a cela ne tienne, je me suis débrouillé pour réinstaller un OSX 10.10 neuf, je l'avais justement sous la main.
Pour des histoires de câbles, j'ai lancé l'instal a partir d'un autre mac, sur le disque de celui en panne, passé en mode disque cible. il ne me semble pas que ça pose de problème ?

Le nouveau système du MacBook en panne boot sur l'autre mac en disque cible, mais toujours pas sur la machine qui héberge le disque dur !

Il faudrai lui faire la poussière et changer la pâte thermique, mais je voulais attendre de parvenir a réinstaller d'abord, il ne me semble pas que cela pourrait être la cause... mais bon, au point ou j'en suis, je vais peut-être m'y coller.

Est-ce que quelqu'un y comprend quelque chose ???

 

[Saxobar]

Bon, maintenant, la barre de chargement reste bloqué tellement longtemps que je ne prend plus la peine d'attendre, j'éteins avant d'avoir un message d'erreur. probablement au bout de 30 minutes, barre de chargement a moitié.
Le rond barré à refait une apparition, et le démarrage en mode sans échec s'est aussi soldé par un rond barré, mais plus aucun texte.
Cette inconstance est elle aussi plutôt étrange.
Autre chose : impossible de démarrer l'apple hardware test.

 

[Membre supprimé 1060554]

Salut Saxobar

Le cas que tu décris a toutes les allures d'un paradoxe logique :

- un autre MacBook Pro parvient a démarrer le système du mac en panne, passé en disque cible
le problème n'est donc pas OSX, ni le disque dur.
- le mac en panne parvient a démarrer le système de l'autre MacBook Pro, a son tour passé en mode disque cible. (OSX10.9, il me semble)
le problème ne vient donc pas de la ram, de la carte mère, ou de je ne sais quel programme interne, a priori.
toujours impossible pour le mac en panne de démarrer son propre système.

Je te propose une interprétation permettant de le dénouer (interprétation simplement conjecturelle) -->

Lorsque tu démarres ton Mac > l'EFI (programme interne de boot) exécute dans le volume interne le boot_loader : boot.efi (programme de lancement - affichage d'une ) > lequel active le kernel (noyau du Système - affichage d'une barre de chargement) et procède à l'injection des kexts (extensions du noyau ou pilotes du hardware) - ce qui constitue le processus intra-kernel ou première phase du démarrage logiciel. Cette phase accomplie, le kernel exécute l'utilitaire launchd, qui est le programme INIT d'initialisation de l'OS proprement - ce qui constitue le processus extra-kernel ou seconde phase du démarrage.

Si je me réfère à la scansion des phases de démarrage que je viens de résumer > il me semble que le plantage intervient pendant le processus intra-kernel d'injection des kexts dans le kernel. La très grande lenteur de progression de la barre de chargement > soldée à un moment donné soit par un logo d'interdiction de stationner soit par un kernel_panic (affichage d'un texte en blanc de déboguage) --> me suggère que l'injection des kexts s'opère au compte-goutte (càd. en terme à terme : l'une après l'autre, et pas en bloc --> ce qui donne lieu à une injection "élémentaire" toujours longue) et que parvenu à une kext particulière le kernel ne parvienne pas à la charger (càd. à engager le pilotage d'un composant du hardware auquel est dédiée cette kext).

Cette conjecture permet de dénouer (« théoriquement ») le paradoxe. L'OS de l'autre Mac n'est pas le même : il s'agit d'une version antérieure = «Mavericks 10.9» qui est le dernier OS de la série des OS X à utiliser un kernel de type mach_kernel (avec, je le présume, un panel d'extensions en rapport). Par contre, l'OS du disque interne du Mac est «Yosemite 10.10» --> qui est le 1er OS à introduire un kernel de type kernel (une nouvelle architecture logicielle) avec un panel d'extensions qui doit présenter des variations par rapport à celui de «Mavericks».

Donc (déductions logiques à partir de la conjecture) -->

• quand tu démarres en mode cible l'autre Mac sur le Système «Yosemite 10.10» du Mac qui plante --> l'autre Mac démarre, ce qui veut dire que : le système logiciel du volume «Yosemite» est intègre > le disque du Mac est fonctionnel > sa nappe aussi > le montage du volume en mode cible fonctionne => mais que dans la phase d'injection des kexts dans le kernel de «Yosemite» --> ce sont les composants du hardware de l'autre Mac qui se trouvent impliqués et pilotés. À l'issue de cette phase > le kernel (du Système «Yosemite» du Mac en position-cible) n'a rencontré aucun incident lors du chargement des extensions et a donc pris en charge le pilotage du hardware de l'autre Mac.

• quand tu tentes de démarrer en mode interne --> parvenu à une extension particulière le kernel de «Yosemite» plante, parce qu'un des composants du hardware interne du Mac ne répond pas au chargement du pilote (d'où kernel_panic ou interdiction de stationner).

• quand tu démarres le Mac qui plante sur le Système «Mavericks» de l'autre Mac en position cible --> c'est un OS plus ancien que tu démarres > avec un noyau de type mach_kernel > qui va se faire injecter le panel des extensions classiques. Apparemment > dans ce cas de figure le composant du hardware du Mac qui ne répond pas au pilotage par le noyau de «Yosemite» > ne plante pas le chargement du noyau mach_kernel de «Mavericks» : soit parce que l'extension correspondante, qui a une autre structure logicielle, réussit sa tâche, soit parce que le kernel "old school" de «Mavericks» parvient à échapper ce chargement sans planter (à la différence du kernel "new school" de «Yosemite» qui prend un coup d'air : bref, qui témoigne d'une "sensibilité" plus grande en ne parvenant pas à échapper ce chargement).

Si tu as suivi cet exercice d'« imagination logique » qui est pure exploration conjecturelle "hypothético-déductive" --> il s'ensuit que tu devrais essayer d'installer l'OS «Mavericks 10.9» sur le disque interne du Mac qui plante. Si ma conjecture est valide > le kernel de type mach_kernel de «Mavericks» devrait parvenir, en interne aussi, à échapper la difficulté en mettant une extension en quarantaine du chargement.

Une expérimentation croisée (peut-être plus difficile à mettre en place pour toi) --> consisterait à créer une partition sur le disque de l'autre Mac > afin d'installer dans son volume une version «Yosemite 10.10» en clean install > puis à mettre l'autre Mac en mode cible pour lancer le démarrage du Mac qui plante sur le système «Yosemite» de l'autre Mac. Si ma conjecture était valide > le Mac qui plante devrait... planter encore, le kernel "new school" du «Yosemite» externe coinçant à un moment donné de la phase d'injection des kexts à charger un pilote > parce qu'il correspondrait à un composant défaillant du hardware du Mac qui plante.

 

[Saxobar]

Salut Macomaniac ! Voila en substance une réponse que j'espérais, merci vraiment d'avoir pris le temps de la rédiger ainsi !

Ton interpretation semble tout à fait plausible.
Je vais essayer d'installer OSX 10.9 et voir ce que ça donne.
Par contre, installer 10.10 sur l'autre mac ne me tente guère. Ce mac héberge déjà 10.9 et high sierra en multiboot et j'ai du boulot important en ce moment. Comme high sierra a passé sa partition en APFS (merci, maintenant cette partition n'est plus accessible depuis le système 10.9) la seule partition que je peux modifier est donc celle de 10.9 et il est hors de question que j'y touche maintenant !! c'est ma partition de travail.

Maintenant, la question que je me pose est : qu'est ce qui dans le hardware du mac pose problème.
J'ai donc démarré en mode détaillé, voila ce qui apparait :

l'opération se solde par ceci :

 

[Saxobar]

J'ai refais une tentative de démarrage en mode détaillé, pour vérifier.
Cette fois la réaction est différente :

le dernier message est survenu plusieurs fois, puis ensuite tout se brouille, mais impossible de transférer la photo...
en gros sur fond gris avec le rond barré, le même texte en blanc, et sous lui, pleins de caractères en noir remplissent tout l'espace. On repère les mot driver, stock et AHCI.
Bon, j'ai bien l'impression qu'il y a quand même un problème du côté du disque dur.

 

[Membre supprimé 1060554]

D'après ce que je comprends du dernier journal (message #5) -->

le boot_device ou appareil de démarrage pour l'EFI (BSD root) est identifié comme disk0s2 > mais le media disk0s2 n'est pas présent > un appel à l'utilitaire hfs_mountfs retourne un échec > impossible de monter le device > une alternative par l'UUID de l'appareil de boot est tentée > qui ramène à l'identification de disk0s2 comme appareil de boot > mais le media n'est pas présent > et n'est pas montable etc.

On ne peut pas reprocher à la programmation de démarrage de l'EFI de ne pas être insistante : d'innombrables tentatives pour accéder à l'appareil de boot sont tentées (comportant explorations de variantes et redondances). Je présume qu'une limitation est inscrite dans le programme (temporelle ou du nombre de tentatives) --> bref le signe d'interdiction de stationner n'intervient qu'après une insistance grandiose à tenter de forcer le boot.

Ce petit exercice de décodage ne vient pas corroborer l'interprétation de mon message antérieur -->

dans la mémoire NVRAM de la Carte-Mère > à la variable intitulée : efi-boot-device (appareil de démarrage automatique de l'EFI) > se trouve inscrit le chemin d'accès à l'appareil de boot. À la fois sous la forme d'une identité de device (en règle générale : disk0s2 : disk0 ou premier disque > s2 ou slice - tranche logique - n°2) et d'un UUID (genre : XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX).

Le morceau de journal de boot que tu as posté équivaut à un « soliloque » de l'EFI en train de se dire : j'ai l'identité de l'appareil de boot --> c'est la partition disk0s2 > mais m..de ! je ne trouve pas l'appareil correspondant à la partition (= le volume) > bon : j'envoie l'ilote "monteur de système de fichiers - spécialisé HFS" > l'ilote me retourne qu'il est incapable de monter le volume à partir du point de montage du système de fichiers > donc re-m..de ! le media (volume) correspondant à la partition disk0s2 n'est pas "présent" (monté - online) > alors qu'est-ce que je fais ? > je tente l'accès par l'UUID [là je dis : mauvais raisonnement de l'EFI --> l'UUID est identique à disk0s2 > donc ça va conduire à la même impasse --> ce n'est pas ça qu'il faudrait tenter] > et c'est reparti pour un tour : disk0s2 > volume pas monté > non montable etc.

Donc en résumé : l'EFI ne peut pas exécuter le boot.efi du volume Macintosh HD > car le volume n'est pas monté sur la partition disk0s2 > et n'est pas montable.

----------

Il n'a s'agit donc pas ici d'un problème d'injection de kext dans le kernel (ce qui suppose le volume Macintosh HD monté sur la partition disk0s2 > un accès réussi de l'EFI au volume > l'exécution du boot.efi (qui est en somme l'application de boot de l'EFI) > l'activation du kernel > le début du processus d'injection des extensions) ; il s'agit d'un échec à accéder au volume Macintosh HD (bien identifié comme cible --> "le media monté sur le device disk0s2") > car le volume n'est pas monté sur la partition et que son montage ne peut pas être forcé.

Il se pourrait que le système de fichiers JHFS+ de la partition disk0s2 comporte des erreurs proscrivant le montage du volume dans le temps du boot. Tu devrais tenter, en mode cible, de le vérifier avec l'«Utilitaire de Disque» de l'autre Mac.

Mais il se pourrait que la nappe SATA du disque (câble plat reliant le disque à la Carte-Mère) soit défaillante. Tu pourrais extraire le HDD du Mac > le mettre dans un boîtier SATA-USB pour disque 2,5 pouces comme montré sur cette page de MacWay ☞Boîtier disque dur 2,5"☜ et tenter le boot avec la touche "alt".

Procédé alternatif : le Mac en mode cible et en opérant depuis l'autre Mac --> effacer le disque complet du Mac cible > installer «Mavericks 10.9» (et pas «Yosemite 10.10») --> vérifier si le Mac boote normalement sur 10.9 ou pas (test qui mettrait à l'épreuve ma 1ère conjecture).