Salut
hupeha.
suite à la mise à jour de 10.10.2 vers 10.10.3, je suis maintenant dans l'impossibilité de désactiver à nouveau le trim, ce qui s'avère gênant pour faire de futurs mises à jours
- non : il n'est absolument pas requis de désactiver le Trim avant une MÀJ de l'OS, parce que toute MÀJ de l'OS désactive le Trim automatiquement. En effet, une MÀJ étant un paquet d'installation qui recèle le dossier intégral des Extensions Apple, ce dernier vient "écraser" celui en place en re-créant toutes les extensions, dont une IOAHCIFamily.kext intègre (voir mon topo ci-dessous pour les détails concernant cette extension) --> il s'ensuit par là que le Trim n'est plus actif par défaut. Et comme l'installateur recrée le cache de démarrage de l'OS (le kernelcache) et restaure les arguments de boot de la mémoire NVRAM à leur valeur par défaut, aucun plantage lié à une activation du Trim antérieure n'est donc à redouter. Le problème que tu te poses n'a donc pas d'existence pratiquement parlant.
- par voie de conséquence de ce constat, la manière "automatique" de désactiver le Trim (sans passer par «Trim Enabler») consiste à... ré-appliquer à ton OS la MÀJ 10.10.3 --> pour ce faire, il te suffit de télécharger la ☞OS X Yosemite 10.10.3 Combo Update☜ (+2 Go comprimé), de monter le .dmg et de lancer l'installation. Moi qui ai un MacBook Pro Early_2011 avec la config suivante : SSD Crucial 1To x Yosemite x Trim Enabler actif, j'ai fait la MÀJ depuis l'AppStore sans désactivation du Trim au préalable et, après re-démarrage et ré-ouverture de session sans problème, «Trim Enabler» a affiché un panneau mentionnant que le Trim était désactivé et me proposant de le ré-activer, ce que j'ai fait. Pour faire le test que je viens de te préconiser, en deuxième instance j'ai téléchargé le .dmg de la Combo-Update 10.10.3 (j'ai pu vérifier grâce à «Pacifist» que le paquet d'installation contient bien le dossier intégral des extensions, dont la IOAHCIFamily.kext), et j'ai lancé son installation --> même scénario : après re-démarrage, le Trim est désactivé et «Trim Enabler» propose de le réactiver.
♤
Si
Désactiver le Trim au préalable ne me paraît donc pas un problème réel
pratiquement parlant, par contre je suis hautement intrigué par ce constat que tu fais :
quand je clique sur désactiver la commande trim dans trim enabler
j'ai le message suivant : "sauvegarde du driver introuvable- visitez cindori.org pour savoir comment le récupérer manuellement"
parce qu'il y a là un problème tout à fait intéressant
théoriquement parlant. Comme c'est dimanche, permets-moi de me livrer à un petit exercice herméneutique qui a toutes les chances d'errer dans la géographie fumeuse de l'imaginaire dominical...
Le logiciel «
Trim Enabler» modifie quelques octets d'une
Extension du Noyau native d'Apple : la
IOAHCIFamily.kext - laquelle gère automatiquement le Trim sur les SSD installés d'origine par Apple, mais est inopérante s'il s'agit d'un SSD tiers substitué par l'utilisateur à un HDD originel - de manière à permettre son activation dans ce dernier cas de figure. C'est dans cette modification de l'extension : IOAHCIFamily.kext que consiste donc l'«Activation du Trim». Le reste des interventions logiques de «Trim Enabler» consiste à établir des garde-fous pour éviter que le protocole du kext_signing (contrôle d'intégrité des extensions du noyau Apple au démarrage) instauré par l'OS «Yosemite» n'amène le plantage du Mac lors de l'inspection de la IOAHCIFamily.kext altérée par le logiciel. Il s'agit donc corrélativement ici de la "neutralisation" du kext_signing.
Je suis intéressé par ton message, parce que je m'étais toujours demandé (en ayant la flemme d'engager une recherche expériementale en ce sens) comment s'y prenait «Trim Enabler» pour «Désactiver le Trim» quand on le lui demandait. D'après mon § précédent, il est clair que cette "désactivation" doit consister en la Restauration de l'extension du noyau Apple : IOAHCIFamily.kext à son intégrité primitive (qui fait qu'elle ne gèrera plus le Trim pour le SSD de tierce-partie). Ce qui déplace la question ainsi : comment s'y prend «Trim Enabler» pour restaurer à son intégrité primitive l'extension du noyau : IOAHCIFamily.kext?
C'est là que ma flemme intervenait, en laissant le sujet dans le flou de cette «nuit où toutes les vaches sont noires» (suivant l'expression consacrée de Hegel). Le message que tu as obtenu : "sauvegarde du driver introuvable" exclut clairement une possibilité --> que «Trim Enabler» serait capable de renverser logiquement, par une opération à rebours, ses modifications de la IOAHCIFamily.kext (car, si tel était le cas, le logiciel n'aurait nullement besoin d'une "sauvegarde" de l'extension du noyau dans son intégrité primitive). Surgit alors la conjecture alternative : «Trim Enabler» opèrerait peut-être une copie en local de la IOAHCIFamily.kext, de manière à pouvoir opérer une re-copie à la demande restaurant l'extension modifiée à sa valeur native (par analogie avec le logiciel «Carbon Copy Cloner» qui crée un archive ad hoc de la «Recovery HD» en local dans l'OS, afin de pouvoir la re-créer à la demande. Dans ce cas de figure, cette archive de la IOAHCIFamily.kext aurait été accidentellement supprimée dans l'OS, invalidant la capacité de re-copie de «Trim Enabler». Pourtant, une recherche effectuée dans l'OS de mon Mac (SSD Crucial x Yosemite 10.10.3 x Trim Enabler activé) m'a montré qu'il n'existe acutellement aucune archive de la IOAHCIFamily.kext qu'aurait créée «Trim Enabler». Et pourtant, si je demande la désactivation du Trim, «Trim Enabler» obtempère.
L'indication : "visitez cindori.org pour savoir comment le récupérer manuellement" me conduit alors à une nouvelle piste. Lorsque le Mac est planté devant le panneau d'interdiction de stationner ⊘ (parce que le kext_signing a été accidentellement redéclenché alors que le Trim est activé), le développeur propose comme échappatoire de démarrer sur la «Recovery HD» et d'utiliser son «Terminal» pour... recopier la IOAHCIFamily.kext existante dans l'OS de la «Recovery» (at: /System/Library/Extensions/IOAHCIFamily.kext tout bonnement lorsque, démarré sur ce Système auxiliaire, le point de montage / désigne celui de l'OS de la récupération 10.10.3) à la place de celle modifiée de l'OS principal (at: /Volumes/Macintosh\ HD/System/Library/Extensions/IOAHCIFamily.kext) --> ainsi, la "sauvegarde du driver", c'est l'existence du clone de la IOAHCIFamily.kext recelé, dans sa version Apple intègre, dans le dossier des Extensions de l'OS auxiliaire de la «Recovery HD». Je conjecture que, quand on demande au logiciel «Trim Enabler» de "désactiver le Trim", ce dernier monte en volume la partition non montée par défaut de la «Recovery HD», et monte le disque virtuel BaseSystem.dmg qu'il recèle en un volume-disque : OS X Base System dans lequel les dossiers-Système de l'OS de la «Recovery HD» sont recelés, ce qui rend le répertoire de la Bibliothèque-Système accessible, et par là son sous-dossier Extensions, afin d'opérer une recopie de la IOAHCIFamily.kext.
Conformément à ce cas de figure, pourquoi diable «Trim Enabler» achoppe-t-il sur ton Mac à exécuter cette astucieuse manœuvre? J'entrevois 2 conjectures :
- a) Pour une raison quelconque (par exemple : ré-intialisation du disque de ton Mac à partir d'un démarrage sur un Système externe comme un clone, et rétro-clonage du Système sans recréation d'une «Recovery HD»), tu aurais supprimé la partition de récupération «Recovery HD» --> «Trim Enabler» serait donc incapable de monter le volume d'une partition inexistante et donc d'y trouver l'extension-archétype lui permettant une recopie --> dans ce cas de figure, te renvoyer à l'opération manuelle décrite sur le site «Cindori» serait vain, puisqu'elle implique de démarrer sur la «Recovery HD» et d'utiliser les ressources de son OS à fin de recopie de la IOAHCIFamily.kext originale - chose impossible si tu as supprimé cette partition...
- b) Tu dis que tu as désormais 2 disques dans ton Mac : "je possède un macbook pro 2011, modifié avec un SSD et un HDD" --> est-ce que par hasard, tu ne les aurais pas solidarisés par le procédé logiciel dit du «FusionDrive»? Si c'était le cas, il faut savoir que ce procédé mobilisant l'artefact logique du format CoreStorage associe les 2 partitions majeures des 2 disques (la /dev/disk0s2 du SSD + la /dev/disk1s2 du HDD) dans un seul et unique Groupe de Volumes Logiques qui rejette un seul Volume Logique : Macintosh HD dans lequel est installé «Yosemite». Oui, mais alors : où donc se trouve installée la partition de récupération «Recovery HD»? Toujours exclusivement sur le HDD - sur une partition consécutive extrinsèque au Groupe de Volumes Logiques : Corestorage --> la /dev/disk1s3 (ce afin de réserver la quasi totalité du SSD - en-dehors de la petite partition d'amorçage EFI - pour le Volume Logique et par là d'exploiter le plus extensivement sa "vitesse"). Je me demande alors si le logiciel «Trim Enabler», installé sur le Volume Logique : Macintosh HD, ne serait pas incapable dans ces conditions de trouver l'adresse de la partition de la «Recovery HD» afin de la monter en volume, parce que, supposant l'OS installé sur un disque unique, son instruction mentionnerait de monter la partition consécutive de ce disque unique = la /dev/disk0s3 ; alors que dans le cas de figure d'un FusionDrive, la partition de la «Recovery HD» est rejetée sur un 2è disque = la /dev/disk1s3 --> il s'ensuivrait qu'aucun volume de la «Recovery HD» ne serait trouvé en bout du chemin par défaut et donc que la procédure de re-copie planterait, faute d'une ressource trouvée à l'endroit attendu... [Il s'ensuivrait encore que «Trim Enabler» ne saurait pas gérer le format d'un FusionDrive en mode "Désactiver le Trim" (et il y aurait là un énième "dommage collatéral" à mentionner au passif du format CoreStorage).]
♧
☞ j'ai réagi à ton message par une élucubration dominicale un tantinet longuette, et carrément tirée par les cheveux - parce qu'il m'a paru proposer, à défaut d'enjeu "pratique" réel, un très joli problème "théorique" pour ainsi dire
. Ta déclaration :
suite à la mise à jour de 10.10.2 vers 10.10.3, je suis maintenant dans l'impossibilité de désactiver à nouveau le trim
me porte à penser, nonobstant, que tu étais capable de désactiver le Trim sous «Yosemite 10.10.2» et que ton blocage actuel est purement conjoncturel (problème de «Trim Enabler» sous la 10.10.3) et non structurel (dispositif de tes disques). Si tel était le cas : problème de fichiers de «Trim Enabler» et pas inaccessibilité de la "sauvegarde du driver" - ce qui ruinerait toutes mes conjectures - pourquoi ne pas désinstaller le logiciel, alors, pour le ré-installer tout simplement?
♡
