Comme d'innombrables utilisateurs ayant remplacé leur HDD par un SSD de tierce-partie :
- frustrés de devoir (sous «
Mavericks 10.9») passer par un «
Trim Enabler» qui patchait quelques octets de l'extension du noyau Apple dédiée aux SSD maison (la :
/System/Extension/IOAHCIFamily.kext) pour activer son opération sur des SSD tiers ;
- inquiets de devoir (sous «
Yosemite 10.10») :
- désactiver le kext_signing (protocole de vérification d'intégrité des extensions du noyau Apple) au démarrage du Système par l'inscription d'un argument "developer" (kext-dev-mode=1) en NVRAM pour que l'extension IOAHCIFamily.kext ne soit pas repérée par le kernel comme bidouillée par «Trim Enabler» avec plantage du kernel autrement ;
- argument ne marchant qu'à la condition supplémentaire que soit chargé au démarrage un kernelcache intégrant la liste des extensions en tant que bloc n'ayant pas à être vérifié dans ses éléments terme à terme ;
=> ce qui fait que tout effacement de la
NVRAM faisant sauter l'argument "
developer" plantait le
kernel et que tout démarrage sans extensions impliquant un effacement des caches-Système plantait le
kernel à la vérification terme à terme de chaque extension lorsqu'il arrivait à la
kext bidouillée ;
--> j'ai accueilli la création, à partir de la màj «
Yosemite 10.10.4», d'une extension du noyau ©Apple dédiée aux SSD de tierce-partie comme une libération des affres précédentes (je « suais » à chaque démarrage de «
Yosemite»). Dans mon esprit, la déclaration de « non responsabilité juridique en cas de problème » de la part d'Apple a pesé nettement moins lourd que les hasardeux bricolages induits par «
Trim Enabler».
La néo-extension Apple n'est pas active par principe (ce qui impliquerait la responsablité d'Apple) ; mais tenue en réserve en tant que paradigme at: /
System/Library/Filesystems/AppleDataSetManagement.kext. L'utilitaire
trimforce créé ad-hoc (at:
/usr/bin/trimforce) et appelable par la commande :
sudo trimforce enable dans le «
Terminal» > se borne sur le fond à
recopier le paradigme de l'extension dans le dossier
/System/Library/Extensions > et cela fait à
recréer le cache de démarrage
prelinkedkernel (dans «
El Capitan») intégrant cette nouvelle venue dans la liste des extensions à injecter d'office en bloc dans le noyau lors du boot.
Il paraît que le développeur de «
Trim Enabler» a fini par créer sa propre extension du noyau afin de gérer le
TRIM sur des SSD de tierce-partie. Je pense qu'il a "raté le coche" de l'histoire (comme on dit) - ayant été devancé en cela par l'initiative d'Apple. Je présume que dans «
El Capitan» son extension de tierce-partie n'a pas droit de cité dans le dossier des
Extensions de la
/System/Library et doit se contenter de celui de la
/Library (à moins qu'il n'ait négocié une dérogation spéciale avec Apple).
Pourquoi son extension "maison" serait-elle plus sûre que la nouvelle extension ©Apple ? Rien ne permet de le présumer. Et comme le dit
melaure :
si tu as fait un backup, pas de soucis
=>
en résumé (qui n'engage que moi, dont l'argumentaire n'était qu'une espèce de « confession d'affres <psycho>logiques ») > j'ai passé la commande :
et je n'ai jamais constaté d'anomalies de fichiers...
