Ecran gris au démarage

[yha689]

Bonjour à tous.
J'ai un problème au démarrage de mon macbook Pro " mid 2009.
J'ai un ssd 120Go qui est le system et à la place du lecteur cd un Hdd de 500Go
Depuis ce matin au démarrage j'ai l'écran gris avec le sigle rond barré.
En démarrant avec alt enfoncé, je trouve bien le SSD et la partition recovery ainsi que le HDD de stockageEn bootant sur la recovery j'ai l'utilitaire disque et je peux faire les vérifs du SSD (permissions réparation) Tout est marqué ok sauf :
attention le fichier SUID "system/lybrairie ...Dagent" a été modifié et ne sera pas réparé
puis autorisation différente sur "library attendu lrwxr-xr-x actuellement drwxr-xr-x
ACL trouvé mais inattendue sur private/var/root/library

ACL trouvé mais inattendue sur private/var/root/library/préférence
Vérification des permissions terminées.
en rebootant, iden écran gris.
Par contre j'ai retiré le ssd du mac et je l'ai installé en USB __ et là au poil, le mac démarre oarfaitement et je retrouve tous mes petits
Ouf, je remet le SSD à sa place et plouf re écran gris meme en sélectionnant avec alt ce disque de boot
Je sèche
Ma question ou ça bloque ??

Merci de vos lumières en espérant ne pas avoir été trop long dnas mes expliq

 

[Anonyme]

Bonjour et bienvenue,

sous quel OS es-tu, et utilises-tu Trim Enabler ?

 

[Deleted member 1099514]

Salut

Ne serais-tu pas victime du problème de nappe sata?
Pour t'en assurer il faudrait tenter d'inverser les DD 500 Go et SSD 120 Go.

@+

 

[yha689]

Merci de vos réponses rapides
tout fonctionnait parfaitement , jusqu'a ce redémarrage j'avais arrété au lieu de suspendre.
Je suis sous Yosemit, trimenableur fonctionne,
pour la nappe, non parceque je boot sur la partition recovery, je vois bien les deux partitions et l'utilitaire disque vérifie bien la partition principale (permission et secteurs)

 

[Anonyme]

Yosemite + Trim Enabler.

Deux liens pour toi :

http://www.macg.co/os-x/2014/10/trim-sur-yosemite-tout-ce-quil-faut-savoir-84953

http://www.cindori.org/trim-enabler-and-yosemite/

Et un bonus : https://forums.macg.co/threads/maj-yosemite-10-10-2-et-trim-enabler.1260915/

 

[yha689]

comme je peux booter en le mettant en usb, je vais virer trimenable et refaire un test de boot, si c'est ça c'est une sacrée vacherie pour reste polie
je teste et je reviens

 

[Deleted member 1099514]

Je ne vois pas trop pourquoi Trim Enabler poserai pb en interne et pas en USB...
Mais sait-on jamais?????

 

[yha689]

Bingo, alors là chapeau bas . J'avais lu cet article en installant trimenabler quand j'ai changé mis ce ssd kingston, et cela m'était sorti de la tête, bravo pour le coup de main, et en plus j'ai aussi compris maintenant pourquoi je n'ai pu démarrer: j'avais fair un démarrage sans échec pour vérifier un autre disque WD en USB(pb de smart) et en finissant ma manip j'ai tout étein et c'est au redémarrage que je me suis fait ...disons "blouser" par Apple, ces gens là sont terriblement sympatiques. Une aprem de perdue juste pour que ceux qui ne sont pas trop top bidouille soient coincés. Avant j'étais sur Windows il y avait des truc pas triste, mais pas sulfureux à ce point.

Un sacré Merci Renaud31 (toulouse?) on peut marquer comme résolu.

 

[Anonyme]

Nan, plein sud, dans la montagne maintenant

Pour marquer le sujet comme résolu : http://forums.macg.co/help/bestanswer/

(précise ce que tu as fait, pour ceux qui liront le sujet plus tard, merci)

 

[Membre supprimé 1060554]

Salut yha689.

Comme Renaud l'a détecté, tu es victime du kext_signing : le nouveau protocole sous «Yosemite» de vérification de l'intégrité des kexts (extensions du noyau) natives Apple au démarrage. C'est un argument de boot stocké dans la mémoire statique NVRAM de la Carte-Mère, qui est lu par l'EFI (le programme interne en charge du départ de démarrage) et passé au chargeur de l'OS : le Boot-Loader : boot.efi qui en refile l'instruction au kernel (le noyau du Système) --> comme tu vois, un enchaînement fatal, lorsque le disque du Mac est un SSD de tierce-partie (non Apple) et que le Trim a été activé par «Trim Enabler», parce que ce dernier altère une kext Apple native en charge du Trim sur les SSD Apple afin de la rendre opérationnelle au-delà. Et hop! le pot-au-rose est découvert et le kernel interrompt son chargement --> affichage du panneau d'interdiction de stationner.

Normalement, le logiciel «Trim Enabler» prend ses précautions pour éviter ce genre de désagrément : 1° en modifiant l'argument de boot en NVRAM pour une version autorisant les développeurs à faire charger des extensions expérimentales (boot-args=kext-dev-mode=1) ; 2° en reconstruisant le kernelcache qui est un "bloc logique" solidarisant un clone du code du kernel avec le bloc des kexts assorti de l'option : --all-loaded qui les fait charger sans examen préalable comme un tout. Or ce que charge le Boot-Loader : boot.efi au démarrage, ce n'est pas le kernel solitaire qui aurait à examiner/charger chaque kext l'une après l'autre (ça prendrait un temps fou), mais le bloc du kernelcache directement, ce qui assure un gain de temps appréciable. Mais pour «Trim Enabler», c'est aussi une garantie de non-examen individuel kext à kext.

Mais il arrive que l'utilisateur, sans en avoir conscience, fasse s'ébouler ce fragile échaffaudage : soit en ré-initialisant la NVRAM au démarrage, soit en vidant les caches de démarrage-Système - dont le kernelcache (par un démarrage "sans extensions" ou en utilisant un logiciel de maintenance/nettoyage qui ne prévient pas des dangers - noter qu'«Onyx» est le seul à prévenir les utilisateurs de ce danger dans sa version pour «Yosemite») --> hop! le chargement de l'OS bloque. Et c'est ton cas.

Mon expérience m'a montré que la solution, non la plus rapide mais la seule à 100% garantie, consiste à démarrer sur la «Recovery HD» et à activer l'option : Ré-Installer OS X --> il y a téléchargement depuis les serveurs Apple des packages d'installation de la version d'OSX exactement synchrone de celle du disque du Mac (+ 5 Go --> + 2H), puis ré-installation "sur" le Système de fichiers de l'OS déjà en place, qui se borne à les ré-écrire en conservant les comptes et données d'utilisateurs et applications tierces ajoutées. Cette ré-écriture, en restaurant la kext altérée par «Trim Enabler» désactive automatiquement le Trim, restaure l'argument de boot standard en NVRAM et re-crée un kernelcache new-age --> résultat, boot réussi à 100%. Il n'y a plus après qu'à ... ré-activer le Trim !

La méthode en utilisant le «Terminal» de la «Recovery HD» est loin d'avoir une garantie de 100% de réussite : je l'ai pratiquée expérimentalement une dizaine de fois et j'ai échoué 2 fois malgré des des réitérations et des prises de tête poussées. Mais rien ne t'empêche de la tenter d'après les liens donnés par Renaud.

--------------------​

<Évidemment, le temps que je rédige mon topo en aveugle, l'affaire était déjà conclue et j'arrive après la bataille comme les Carabiniers d'Offenbach

J'en profite quand même pour noter le point suivant : le kext_signing, d'après un certain nombre d'expériences, n'opère que si le SSD de tierce-partie est placé en interne dans le Mac en position de remplacement d'un HDD natif Apple ; dès lors qu'on place le même SSD en externe (boîtier USB), en position de DDE donc, il n'y a plus aucun problème de boot quand bien même il y aurait eu ré-intialisation de la NVRAM et/ou suppression du kernelcache.>

 

[yha689]

J'avais pensé tout réinstaller MAIS ..avec la recovery impossible de le faire : erreur inatendue (ouaf) réessayez etc etc.
Et pour le disque en usb qui boot c'est parce que TRIMENABLEUR ne fonctionne pas en USB (ce que je viens de découvrir)

 

[yha689]

merci macomaniac là j'ai toute l'explique je vais mettre les mains dans le camboui

 

[yha689]

Pour résoudre le pb comme j'avais une baise usb, j'ai installé le ssd dedans, botté dessus, et désactivé trimenable et pour § de précauution désinstallé proprement remis le ssd en place redemarrer et réinstaller trimenabler et tout fonctinne sans avoir à trapatouiller autre chose que du hard.
Merci à tous