Maj Yosemite 10.10.2 et Trim Enabler

[macdou84]

Bonjour,
J'ai besoin d'un renseignement sur la mise à jour de Yosemite 10.10.1 en 10.10.2 sur mon mac pro 3.1, faut-il désactivé Trim Enabler avant de faire la mise à jour de mon SSD. merci d'avance.
Jean-François

 

[subsole]

Bonjour, bienvenue sur MacG.
Certains ont oublié , il parait qu'au reboote TrimEnabler demande de réactiver le TRIM.
Personnellment, je ne tenterais pas le diable et désactiverais le TRIM.

 

[macdou84]

Bonjour, bienvenue sur MacG.
Certains ont oublier , il parait qu'au reboote TrimEnabler demande de réactiver le TRIM.
Personnellment, je ne tenterais pas le diable et désactiverais le TRIM.

Merci pour cette réponse rapide, je poste le résultat une fois la mise à jour faite.

 

[Membre supprimé 1060554]

Personnellement [«Yosemite» x SSD Crucial x «Trim Enabler»], je n'ai pas désactivé le Trim avant l'application de la MÀJ 10.10.2 à mon OS 10.10.1 --> la MÀJ, en restaurant la kext : IOAHCIFamily.kext + maj du kernelcache + restauration de l'argument de boot régulier en NVRAM, a de ce chef invalidé le Trim sans poser de problème de re-démarrage.

Comme indiqué par subsole, à la ré-ouverture de session, «Trim Enabler» a affiché une fenêtre constatant l'état de chose et proposant de ré-activer le Trim - ce que j'ai effectué --> s'en est ensuivi le triple "classique" du logiciel (altération de la IOAHCIFamily.kext + reconstruction du kernelcache + virement de l'argument de boot en NVRAM à boot-args kext-dev-mode=1) et après un nouveau re-démarrage, tout était remis en place comme avant.

 

[macdou84]

Personnellement [«Yosemite» x SSD Crucial x «Trim Enabler»], je n'ai pas désactivé le Trim avant l'application de la MÀJ 10.10.2 à mon OS 10.10.1 --> la MÀJ, en restaurant la kext : IOAHCIFamily.kext + maj du kernelcache + restauration de l'argument de boot régulier en NVRAM, a de ce chef invalidé le Trim sans poser de problème de re-démarrage.

Comme indiqué par subsole, à la ré-ouverture de session, «Trim Enabler» a affiché une fenêtre constatant l'état de chose et proposant de ré-activer le Trim - ce que j'ai effectué --> s'en est ensuivi le triple "classique" du logiciel (altération de la IOAHCIFamily.kext + reconstruction du kernelcache + virement de l'argument de boot en NVRAM à boot-args kext-dev-mode=1) et après un nouveau re-démarrage, tout était remis en place comme avant.

Bonjour et merci pour cette réponse qui pour moi est un peu compliqué, mais si j'ai bien compris je ne désactive pas trim Enabler et je fais juste la mise à jour en 10.10.2 . (mon SSD est un toshiba Q série Pro 512Go)

 

[bompi]

Pour résumer l'explication : en installant 10.10.2, tout ce que Trim Enabler a fait est automatiquement et entièrement défait.
Tu redémarres donc normalement, sans le TRIM activé.
Il ne te reste plus qu'à relancer Trim Enabler et réactiver le TRIM.

 

[Ibiscus]

J'avais fait de même, par étourderie, en passant de 10.10.0 à 10.10.1 sans problème. De l'avis de Macomaniac, c'est valable pour toutes les mises à jour, ou rien n'est moins sûr et la sagesse voudrait qu'on désactive Trim Enabler par précaution. Merci !

 

[macdou84]

Pour résumé l'explication : en installant 10.10.2, tout ce que Trim Enabler a fait est automatiquement et entièrement défait.
Tu redémarres donc normalement, sans le TRIM activé.
Il ne te reste plus qu'à relancer Trim Enabler et réactiver le TRIM.

Ok merci pour la réponse je test ce soir, merci bonne journée

 

[subsole]

J'avais fait de même, par étourderie, en passant de 10.10.0 à 10.10.1 sans problème. De l'avis de Macomaniac, c'est valable pour toutes les mises à jour, ou rien n'est moins sûr et la sagesse voudrait qu'on désactive Trim Enabler par précaution. Merci !

Parfois ça passe, la preuve, mais depuis qu'Apple a introduit le kext signing (nouvelle mesure de sécurité) ça peut ne pas pardonner, et tu as droit à un joli panneau.

Dans le meilleur cas, tu devras mettre les mains dans le moteur et perdre du temps à récupérer ton Mac.

Je ne vois aucune utilité à prendre tant de risques pour une manipulation (désactiver le TRIM) qui prend 3 secondes.

 

[macdou84]

Parfois ça passe, la preuve, mais depuis qu'Apple a introduit le kext signing (nouvelle mesure de sécurité) ça peut ne pas pardonner, et tu as droit à un joli panneau.

Dans le meilleur cas, tu devras mettre les mains dans le moteur et perdre du temps à récupérer ton Mac.

Je ne vois aucune utilité à prendre tant de risques pour une manipulation (désactiver le TRIM) qui prend 3 secondes.

Bonjour, j'ai suivi vos conseils et après avoir désactiver TrimEnabler et installé 10.10.2 j'ai réactivé Trim et tout fonctionne parfaitement.
Je remercie tous les intervenants, bonne journée.

 

[corinned]

bah , on se demande si activé TRIM sert a quelque chose , personnellement je ne l'ai jamais activé , voila maintenant 4 ans que j'ai mon disque dur crucial et jamais eu de problèmes

 

[subsole]

bah , on se demande si activé TRIM sert a quelque chose , personnellement je ne l'ai jamais activé , voila maintenant 4 ans que j'ai mon disque dur crucial et jamais eu de problèmes

C'est intéressant d'avoir ton retour d'expérience, faut croire que le Garbage Collection fait bien son office.
Tu n'as pas de ralentissement par rapport au début, ou/et quelques blocages ?
Laisses-tu souvent ton Mac au repos sans l'éteindre ?

 

[corinned]

C'est intéressant d'avoir ton retour d'expérience, faut croire que le Garbage Collection fait bien son office.
Tu n'as pas de ralentissement par rapport au début, ou/et quelques blocages ?
Laisses-tu souvent ton Mac au repos sans l'éteindre ?

non mon MBP fonctionne a merveille depuis le changement de disque dur , je suis passé de mountain lion , mavericks et yosemite . Je le laisse allumé 24h sur 24h , et je le redémarre une fois par semaine

 

[subsole]

Oui, la meilleure solution pour que le Garbage Collection fonctionne est de laisser le MBP sous tension 24/24.

 

[Membre supprimé 1060554]

Il me semble avoir lu, dans les instructions de Crucial relatives au Garbage Collector, qu'il faut maintenir le Mac suspendu à l'écran de choix du disque de démarrage sans ouvrir de session graphique d'utilisateur - ce pendant environ 8H, afin que l'opération susdite fonctionne.

Un procédé des plus décourageant, car, je le demande : qui va de manière régulière s'astreindre à démarrer son Mac pour le laisser 8H suspendu à l'écran de choix du disque de démarrage sans ouvrir de session d'utilisateur - càd.sans pouvoir l'employer? Il faudrait, chaque soir, au lieu d'éteindre le Mac ou au lieu de le virer seulement à l'état de sommeil sans avoir quitté la session d'utilisateur ; le re-démarrer avec la touche 'alt' pressée pour obtenir l'écran de choix du disque de démarrage et laisser le Mac suspendu à cette option tout le restant de la nuit jusqu'au matin.

C'est peut-être une routine dont on peut prendre le pli - qui sait? Mais est-elle viable, en terme de plages horaires? Personnellement, je ne me sens pas de m'y plier, car, virer le Mac en pause sur l'écran de choix du disque de démarrage à 22H, signifierait devoir le laisser en stase jusqu'à 6H du matin : trop tard pour moi comme re-démarrage. Si 23H, alors --> 7H : hors sujet pour moi. Si 21H, alors 5H : envisageable comme démarrage matinal, mais contraignant comme heure de fermeture de session...

En bref : je s'aperçois que je ne suis jamais dans la pratique disposé à utiliser cette fonctionnalité sur un pied régulier. Donc j'ai activé le Trim.​

 

[subsole]

En clair comme en bref :

Sur un Mac, appuyez sur la touche Option pendant le démarrage afin d'accéder à l'écran du Gestionnaire de démarrage. Le fait de laisser le Mac sur cet écran permet d'alimenter le SSD tout en le maintenant inactif, de sorte que Garbage Collection puisse fonctionner, à l'instar de l'écran du BIOS sous Windows.

Pour éviter que le SSD dysfonctionne à nouveau, vous pouvez modifier vos paramètres d'alimentation et faire en sorte que le SSD reste alimenté lorsque l'ordinateur est en mode veille.

Personnellement, j'ai également préféré activer la TRIM

 

[melaure]

C'est intéressant d'avoir ton retour d'expérience, faut croire que le Garbage Collection fait bien son office.
Tu n'as pas de ralentissement par rapport au début, ou/et quelques blocages ?
Laisses-tu souvent ton Mac au repos sans l'éteindre ?

Comme je le disais sur un autre post, le garbage collector des Sandforce est assez efficace (pas autant que le TRIM mais suffisament). Et confirmation sur forum Arnandtech.

 

[adri83]

bonsoir à tous, je viens vers vous car avez l'air de vous y connaitre en SSD et TRIM, je possède un macbookPro mi 2012, ou dessu j'ai remplacé le HD du mac par un SSD CRUTIAL de 512 giga et mis 16g de RAM, bref je n'ai jamais eu aucun problème depuis que j'ai réalisé ces changements, depuis 4 mois. J'utilise TRIM ENABLER 3.3 et tout semble bien fonctionner. Voici mon problème, je fais parti du programme d'apple pour les mise à jour BETA, la dernière étant la 10.10.3 j'ai voulu la faire en ayant au préalable désactiver le TRIM ENABLER sauf que voila tout à buger c'est à dire que lors du redémarrage de fin de mise à jour, mon mac m'affiche à chaque démarrage un gros message d'erreur pendant la barre de chargement et la pomme au démarrage puis ensuite me dit votre ordinateur à redémarré en raison d'un problème... bref un espèce de KERNEL PANIC ( vu sur un forum ) la seule solution a été d'éffacer le disque et cloner dessu mon ancien disque dur et la tout est reparti sans problème mais j'ai réessayé plusieurs fois de faire cette mise à jour et je rencontre le même problème impossible de démarrer le mac par la suite. Par curiosité j'ai réalisé cette même mise à jour sur le disque dur d'origine du mac et la, la mise à jour à très bien fonctionné aucun problème et j'aimerai comprendre ce qui ne va pas avec mon SSD... je vous joint le message d'erreur lors du chargement de la barre de démarrage. j'espère avoir été plutôt clair désolé pour les fautes.Merci
http://imgur.com/xl4Ad8d

 

[Membre supprimé 1060554]

Salut adri.

Même si mon intérêt fut captivé par ton message dès sa publication - de ne voir aucune "solution" à la question que tu poses m'a écarté d'y répondre. Jusqu'à ce que le démon de l'aventure m'ait soufflé dans l'oreille ce matin : est-il requis de savoir répondre de quelque chose, pour pouvoir répondre à quelqu'un? Se faire l'écho d'une question ouvre déjà un espace de conversation...

Lorsque tu installes la MÀJ : «Yosemite 10.10.3 - bêta» sur le Système «Yosemite 10.10.2» de ton SSD Crucial, tu te heurtes effectivement au re-démarrage automatique à un kernelpanic. Le message déclare qu'intervient une erreur au niveau du Core_2 du Processeur, le Débogueur appelé à la rescousse signalant me semble-t-il un plantage au chargement d'une kext (extension du noyau) : la com.ManyCamLLC. S'agirait-il du pilote de tierce-partie d'une caméra vidéo connectée à ton Mac?

Alors, bien entendu, tu pourrais essayer de ré-installer la MÀJ "10.10.3-bêta" après avoir débranché au préalable ton device (si tel est bien le cas) et avoir déplacé hors du répertoire : /Bibliothèque/Extensions (localisation des extensions de tierce-partie - regarde aussi 'au-cas-où' à : /Système/Bibliothèque/Extensions) la kext incriminée (si tu la trouves bien) --> est-ce que le re-démarrage s'opère?

(Au cas où tu n'aurais rien changé au dispositif de ton Mac, je me demande, juste à l'annonce du re-démarrage suivant l'installation de la bêta, si tenir pressée la touche ⇧ (= "maj") du clavier ne permettrait pas un démarrage "sans extensions" (désactivant le chargement des kexts de tierce-partie notamment) --> dans ce cas de figure, le démarrage s'opère-t-il sans kernelpanic?)

Je note quand même une indication curieuse dans le rapport de kernelpanic : alors que tu dis avoir désactivé le Trim en préalable à l'installation de la MÀJ "10.10.3-bêta" (je suppose que tu utilises «Trim Enabler» et que tu demandes donc à ce logiciel cette désactivation), je lis qu'il est mentionné : Boot args : kext-dev-mode=1 --> il s'agit précisément de l'argument de boot que le programme «Trim Enabler» instruit dans la mémoire NVRAM de la carte-mère du Mac, afin de neutraliser l'argument par défaut du kext_signing introduit par l'OS «Yosemite» qui commande un examen d'intégrité des kexts "Apple_natives" au démarrage et le blocage de ce démarrage en cas d'extension trafiquée (ce qui est le cas pour la kext : IOAHCIFamily.kext en charge du Trim pour les SSD-Apple_natifs et dont le logiciel «Trim Enabler» modifie des octets afin de lui faire gérer des SSD de tierce-partie comme ton Crucial). Or, normalement, quand on demande à «Trim Enabler» de désactiver le Trim, non seulement il y a restauration de la kext incriminée à sa valeur par défaut, mais aussi restauration de l'argument de boot en NVRAM par défaut --> il ne devrait donc pas être mentionné que l'argument de boot actif est le Boot args : kext-dev-mode=1.

Test : après désactivation du Trim dans ton OS «Yosemite 10.10.2» régulier, puis ré-installation de la version «10.10.3-bêta» sur ton SSD en interne qui donc plante au re-démarrage - si tu éteins ton Mac et si tu le démarres en opérant directement le ☞reset_NVRAM☜ (d'après la page citée) afin d'être sûr que l'argument de boot en NVRAM n'est plus le Boot args : kext-dev-mode=1 --> est-ce que par hasard le démarrage s'accomplit jusqu'au bout?​

☞ mon imagination brasse ainsi en parallèle 2 variables hétérogènes [problème de chargement d'une kext de tierce-partie par le kernel / problème d'une désactivation incomplète du Trim laissant en place l'argument de boot de type : developer qui ferait paradoxalement mauvais ménage avec la bêta ] - sans parvenir à une conjecture cohérente --> comme indiqué en annonce, je te réponds ici plus que je ne réponds à la question.

Car voici encore qui fait question : pourquoi la 10.10.3-bêta démarre-t-elle en externe (le HDD) et pas en interne (le SSD)? N'est-ce pas la preuve que la kext : com.ManyCamLLC se laisse charger sans problème si le HDD démarre avec elle en place? Serait-ce alors un problème de disque? Mais la version régulière 10.10.2 démarre sans problème sur le SSD. Serait-ce alors un problème de position en interne du SSD lorsqu'll supporte la 10.10.3-bêta? Il faudrait alors essayer de démarrer la 10.10.3-bêta sur le SSD placé en externe dans un boîtier USB (ce qui implique la patience d'un démontage). Mais si la bêta démarrait sur le SSD en externe - d'où provient alors l'échec en interne?​