n'effectue qu'une seule action : elle recopie la nouvelle extension du noyau Apple dédiée à la gestion du
où cette localisation lui permettra, au re-démarrage, d'être prise en charge par le
- a) la commande
sudo trimforce enable étant disponible depuis la MÀJ «
Yosemite 10.10.4» (où le dossier
/System/Library/Filesystem contient l'original inactif et où le
kernel mis-à-jour supporte son injection), «
El Capitan» a pu être installé en mode "mise-à-niveau" d'un OS «
Yosemite 10.10.5» dans lequel le
TRIM avait été préactivé par la commande
sudo trimforce enable. Ce qui concrètement signifie que l'extension du noyau Apple :
AppleDataSetManagement.kext pré-existait dans le dossier-Système :
/System/Library/Extensions.
L'installateur d'«
El Capitan» a pour propriété de "faire le ménage", lors d'une mise-à-niveau, dans les dossiers-Système concernés par la nouvelle
System Integrity Protection (
SIP) pour virer tout ce qui n'est pas "orthodoxe" et le déplacer à la localisation :
/Library/SystemMigration/History/Migration-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/QuarantineRoot où ces éléments sont désactivés. La nouvelle extension
AppleDataSetManagement.kext étant signée Apple, elle est alors parfaitement respectée par la mise-à-nivau à «
El Capitan» et le
TRIM continue d'être actif sous «
10.11.0».
--------------------
- b) la commande
sudo trimforce enable n'avait pas été passée sous «
Yosemite» et le
TRIM sur SSD tiers continuait d'être géré par «
Trim Enabler». Ce logiciel modifiant l'extension du noyau Apple dédiée à la gestion du
TRIM sur SSD_Apple
/System/Extensions/IOAHCIFamily.kext pour lui faire prendre en charge le
TRIM sur SSD_tiers, il est clair que l'instruction "faire le ménage" de l'installateur d'«
El Capitan» conduit à son remplacement intégral par une
IOAHCIFamily.kext 100% Apple, sans préservation de la bidouille d'
Oskar Groth --> le
TRIM version «
Trim Enabler» est donc par là-même automatiquement désactivé à l'install. Et tous les "pare-feu" inventés par
Oskar Groth (comme la greffe du
boot_args :
"kext-dev-mode=1" en
NVRAM pour neutraliser le
kext_signing + la reconstruction d'un bloc du
kernelcache (cache-Système de démarrage) à faire charger sans vérification de détail) sont balayés par la ré-initialisation suivie de l'instruction automatique des
kernel_flags du
SIP en
NVRAM + le remplacement du
kernelcache ancien_régime par un
prelinkedkernel new_age comme cache-Système de démarrage --> nul besoin de "désactiver" «
Trim Enabler», les effets de ce logiciel sont automatiquement balayés à l'install d'«
El Capitan» de A jusqu'à Z.
Comme après install d'«
El Capitan», le
SIP (
System Integrity Protection) verrouille récursivement les dossiers critiques du Système (dont
/System) par l'
attribut-étendu :
com.apple.rootless, il est impossible de passer directement la commande
sudo trimforce enable qui a pour effet d'écrire au dossier
Extensions inclus dans le répertoire
/System/Library verrouillé. Il faut donc faire un crochet par le «
Terminal» de la «
Recovery HD», passer la commande
csrutil disable qui neutralise les
kernel_flags du
SIP en
NVRAM et redémarrer sur «
El Capitan» où le dossier
/System/Library/Extensions est désormais scriptible ("
writable") en passant en droits
root. Ce qui permet de passer la commande :
sudo trimforce enable et donc d'introduire par là dans le dossier des
Extensions une copie de la
AppleDataSetManagement.kext des
Filesystems. À charge pour ceux qui veulent ensuite restaurer le
SIP de re-démarrer sur la «
Recovery HD» pour passer la commande inverse :
csrutil enable, afin de restaurer les
kernel_flags du
SIP en
NVRAM, avant de re-démarrer da capo sur «
El Capitan» - ce qui donne l'
Apple_revival du «
Mythe de Sisyphe », car nul doute que vous n'aurez tôt ou tard à écrire derechef à un dossier protégé du Système...
--------------------
a clairement résumé.
