M
Membre supprimé 1060554
Invité
Un récent article de MacGénération a signalé la bonne nouvelle : ☞OS X El Capitan prend en charge le TRIM sur les SSD tiers☜.
Pour resituer le contexte : jusqu'à ce jour, une extension du noyau Apple : la IOAHCIFamily.kext prenait en charge le Trim uniquement sur les SSD monté d'usine par Apple, à l'exclusion des SSD tiers installés par l'utilisateur en remplacement d'un HDD sur des Macs déjà relativement anciens. Afin de pallier cette carence, un logiciel comme «Trim Enabler» réussissait à étendre la prise en charge du Trim par la kext Apple sur les SSD tiers après patch de quelques octets.
Mais la mise en place, sous «Yosemite 10.10», d'une mesure de sécurité au démarrage : le kext_signing (vérification de l'intégrité des extensions du noyau Apple) induisait un blocage du démarrage lors de la vérification de la IOAHCIFamily.kext patchée par le kernel avec affichage à l'écran du sigle d'interdiction de stationner. Afin d'esquiver cette menace, le développeur de «Trim Enabler» (Oskar Groth) introduisit dans son programme l'instruction de désactiver le kext_signing sous «Yosemite» : comme ledit kext_signing est une instruction stockée dans la mémoire statique de la Carte-Mère : NVRAM visitée par l'EFI au démarrage et dont les arguments sont passés via le boot_loader : boot.efi au kernel - la mesure consistait à substituer à l'argument de boot par défaut le boot-args=kext-dev-mode=1 autorisant des développeurs à tester sous «Yosemite» des extensions expérimentales sans courir le risque d'un plantage au boot.
Ce patch de la NVRAM garantissant la prise en charge par le kernel de la IOAHCIFamily.kext patchée réclamait de surcroît une mise-à-jour verrouillant le cache de démarrage du Système : le kernelcache, de manière à ce qu'il y ait chargement "en bloc" du paquet des extensions au lieu de prise en charge discrète une à une avec vérification de chacune. Par suite, la solution mise-en-place proscrivait 2 classiques du démarrage avec option : le reset_NVRAM (qui, en faisant sauter le privilège "developer", réactivait le kext_signing et donc vouait le Mac au plantage lors du test de la IOAHCIFamily.kext patchée) et le démarrage "Sans extensions", car ce dernier vidant les caches-Système, supprimait notamment le kernelcache et induisait un démarrage avec chargement discret des kexts une à une qui rendait réopérante la procédure du kext_signing et donc le plantage arrivé à la IOAHCIFamily.kext patchée.
Non seulement l'utilisateur se trouvait restreint dans ses possibilités de démarrage manuels avec option (parfois bien utiles), mais devait rester vigilant dans l'utilisation de logiciels de nettoyage proposant un vidage des caches-Système, quand il ne s'exposait pas à l'installation d'applications impliquant en catimini une manipulation de la NVRAM...
☞ dans ce contexte que je viens brièvement de rebrosser, où l'utilisateur de «Yosemite» qui avait activé le Trim sur un SSD tiers avait l'Épée de Damoclès du plantage suspendue en permanence au-dessus de la tête, l'annonce de la prise en charge du Trim sur les SSD tiers dans «El Capitan» apparaît donc bien comme la fin d'un cauchemar.
Quels sont, sous «El Capitan», les ressorts de la prise en charge du Trim sur les SSD tiers ? 2 outils introduits par Apple simultanément : 1° une nouvelle extension spécifiquement dédiée à la prise en charge du Trim sur SSD tiers : la AppleDataSetManagement.kext qui, pour être activée, doit être localisée dans le répertoire-Système : /System/Library/Filesystems (et pas dans le répertoire : /System/Library/Extensions) ; 2° un nouveau programme binaire UNIX dédié à la gestion de la AppleDataSetManagement.kext --> le trimforce, installé nativement at: /usr/bin/trimforce.
Le nouveau binaire trimforce peut être invoqué selon 2 commandes basiques inverses (réclamant le privilège sudo) : sudo trimforce enable (qui active la AppleDataSetManagement.kext en mode interactif en impliquant de répondre y=yes à 2 demandes d'autorisation successives dans le «Terminal») et sudo trimforce disable (qui désactive la même kext) selon le même type de mode interactif à 2 échelons. Dans les 2 cas de figure, le programme trimforce a pour adresse automatique de sa cible (la AppleDataSetManagement.kext) le répertoire-Système : /System/Library/Filesystems où il doit pouvoir la trouver.
D'après mes expérimentations, il est bien évident que la désactivation du kext-signing n'est plus requise a priori, puisqu'il s'agit d'une Apple_kext native et non d'une Apple_kext patchée. Mais (sous «El Capitan»), il est requis au préalable, en se logeant pour ce faire dans la «Recovery HD 10.11», d'activer le nouvel utilitaire : Security Configuration (Configuration de Sécurité) pour désactiver l'option activée par défaut : Enforce System Integrity Protection sans quoi la commande sudo trimforce enable à partir de l'OS, quand bien même l'utilisateur passe-t-il en privilège root, n'est pas honorée. L'option Enforce System Integrity Protection une fois désactivée, le binaire trimforce se laisse très bien invoquer dans le «Terminal» en droit root et, après re-démarrage, l'Apple_kext native : AppleDataSetManagement.kext se trouve bien effectivement activée et prend en charge le Trim (il n'y a plus qu'à réactiver après coup, depuis la «Recovery HD», l'option Enforce System Integrity Protection de l'utilitaire : Security Configuration --> le nouveau protocole de sécurité est restauré - empêchant notamment des applications de manipuler la NVRAM - sans que l'opération antérieure d'activation de la kext : AppleDataSetManagement.kext ne soit résiliée).
La nouvelle kext Apple_native : AppleDataSetManagement.kext et le nouveau programme binaire : trimforce, d'après mes expérimentations, se laissent copier sans aucun problème, à partir de leur source (l'OS bêta «El Capitan») dans les OS antérieurs : «Yosemite 10.10», «Mavericks 10.9» & «Mountain Lion 10.8» aux emplacements requis : respectivement --> /System/Library/Filesystems/AppleDataSetManagement.kext & /usr/bin/trimforce ; et, après restauration des propriétaires sur le paquet de la kext et le fichier du binaire (par une double commande dans le «Terminal» : sudo chown -R 0:0 /System/Library/Filesystems/AppleDataSetManagement.kext & sudo chown 0:0 /usr/bin/trimforce), il est possible, d'une session admin de chacun de ces OS démarré (10.8, 10.9, 10.10, 10.11) de passer dans le «Terminal» la commande : sudo trimforce enable qui produit dans tous les cas de figure l'activation native du Trim sur un SSD tiers que l'utilisateur aurait installé en interne (à la place d'un HDD et/ou d'un Super-Drive) ou attaché en externe (par exemple en connexion Thunderbolt).
Cette compatiblité rétro-active est, d'après mes expérimentions, honorée pour tous les OS jusqu'à «Mountain Lion 10.8» compris. Dans l'OS «Lion 10.7», par contre, la commande trimforce à destination de la kext : AppleDataSetManagement.kext demeure sans effets.
Une fois le dossier dé-zippé, le plus simple, dans une session admin, est de déplacer a la mano la kext : AppleDataSetManagement.kext à l'adresse suivante : /Système/Bibliothèque/Filesystems (authentification par mot-de-passe admin requise) ; et pour le fichier trimforce, de passer par la fonctionnalité du Finder "Aller au dossier.." en pressant la combinaison de touches : ⌘⇧G (cmd maj G) et, dans la fenêtre de saisie qui s'affiche, de renseigner l'adresse : /usr/bin et presser le bouton : Aller --> le répertoire /usr/bin s'ouvre dans une fenêtre où il n'y a plus qu'à faire glisser le binaire : trimforce (authentification par mot-de-passe admin requise encore).
Cela fait, aller à : Applications/Utilitaires et lancer le «Terminal». Copier-coller en premier la commande :
et ↩︎ (presser la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> taper le mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> les propriétaires du répertoire de la kext sont rétablis récursivement à user=root et group=wheel comme requis). Copier-coller ensuite la commande :
et ↩︎ (pas besoin de ré-authentification dans les 5' après une 1ère commande sudo) --> les propriétaires du fichier binaire sont rétablis récursivement à user=root et group=wheel comme requis.
Cela fait, au cas où le Trim serait activé via «Trim Enabler», relancer ce programme et choisir dans sa fenêtre de "Désactiver le Trim" --> le programme va requérir un re-démarrage avant lequel, en fermeture de session, il va restaurer à son intégrité l'Apple_kext patchée : IOAHCIFamily.kext, mettre à jour le cache-Système kernelcache et résilier en NVRAM l'argument de boot "developer". Ce re-démarrage (d'une pierre 2 coups) va permettre au kernel de charger (sous l'OS rétro-compatible concerné : 10.10, 10.9, 10.8) la kext Apple_native AppleDataSetManagement.kext fraîchement importée dans le répertoire /System/Libary/Filesystems.
Sur ces nouvelles bases, après le re-démarrage et la session ré-ouverte, relancer le «Terminal» et passer la commande :
et ↩︎ --> password à l'aveugle et ↩︎ --> un menu interactif s'affiche :
--> presser la touche y et ↩︎ afin d'agréer --> un nouveau menu ineractif s'affiche :
--> presser la touche y de nouveau et ↩︎ pour agréer --> le programme trimforce va activer la kext : AppleDataSetManagement.kext et le Mac va re-démarrer avec prise en charge par le kernel de l'extension active --> le Trim est désormais pris en charge par la néo-extension Apple (rétro-compatible) sans recours désormais à «Trim Enabler» qui est désactivé.
☞ Désormais, il n'y a plus (sous «Yosemite» du moins) d'Épée de Damoclès suspendue à un long et mince crin de cheval sur la tête de l'utilisateur
Afin d'étrenner ma confiance neuve, j'ai successivement démarré mon Mac (OS : «Yosemite 10.10.3») avec l'option : touche ⇧ pressée (démarrage "sans extensions" vidant notamment le cache-Système kernelcache) puis avec l'option ⌘⌥PR (démarrage réinitialisant la NVRAM avec remise au défaut des arguements de boot) --> dans les 2 cas, le chargement de l'OS s'est effectué sans problème aucun jusqu'à l'ouverture de session....
Pour resituer le contexte : jusqu'à ce jour, une extension du noyau Apple : la IOAHCIFamily.kext prenait en charge le Trim uniquement sur les SSD monté d'usine par Apple, à l'exclusion des SSD tiers installés par l'utilisateur en remplacement d'un HDD sur des Macs déjà relativement anciens. Afin de pallier cette carence, un logiciel comme «Trim Enabler» réussissait à étendre la prise en charge du Trim par la kext Apple sur les SSD tiers après patch de quelques octets.
Mais la mise en place, sous «Yosemite 10.10», d'une mesure de sécurité au démarrage : le kext_signing (vérification de l'intégrité des extensions du noyau Apple) induisait un blocage du démarrage lors de la vérification de la IOAHCIFamily.kext patchée par le kernel avec affichage à l'écran du sigle d'interdiction de stationner. Afin d'esquiver cette menace, le développeur de «Trim Enabler» (Oskar Groth) introduisit dans son programme l'instruction de désactiver le kext_signing sous «Yosemite» : comme ledit kext_signing est une instruction stockée dans la mémoire statique de la Carte-Mère : NVRAM visitée par l'EFI au démarrage et dont les arguments sont passés via le boot_loader : boot.efi au kernel - la mesure consistait à substituer à l'argument de boot par défaut le boot-args=kext-dev-mode=1 autorisant des développeurs à tester sous «Yosemite» des extensions expérimentales sans courir le risque d'un plantage au boot.
Ce patch de la NVRAM garantissant la prise en charge par le kernel de la IOAHCIFamily.kext patchée réclamait de surcroît une mise-à-jour verrouillant le cache de démarrage du Système : le kernelcache, de manière à ce qu'il y ait chargement "en bloc" du paquet des extensions au lieu de prise en charge discrète une à une avec vérification de chacune. Par suite, la solution mise-en-place proscrivait 2 classiques du démarrage avec option : le reset_NVRAM (qui, en faisant sauter le privilège "developer", réactivait le kext_signing et donc vouait le Mac au plantage lors du test de la IOAHCIFamily.kext patchée) et le démarrage "Sans extensions", car ce dernier vidant les caches-Système, supprimait notamment le kernelcache et induisait un démarrage avec chargement discret des kexts une à une qui rendait réopérante la procédure du kext_signing et donc le plantage arrivé à la IOAHCIFamily.kext patchée.
Non seulement l'utilisateur se trouvait restreint dans ses possibilités de démarrage manuels avec option (parfois bien utiles), mais devait rester vigilant dans l'utilisation de logiciels de nettoyage proposant un vidage des caches-Système, quand il ne s'exposait pas à l'installation d'applications impliquant en catimini une manipulation de la NVRAM...
☞ dans ce contexte que je viens brièvement de rebrosser, où l'utilisateur de «Yosemite» qui avait activé le Trim sur un SSD tiers avait l'Épée de Damoclès du plantage suspendue en permanence au-dessus de la tête, l'annonce de la prise en charge du Trim sur les SSD tiers dans «El Capitan» apparaît donc bien comme la fin d'un cauchemar.
--------------------
Mais, comme on pouvait s'y attendre, cette mesure de libéralisation prise par Apple ne fait pas les affaires des promoteurs d'un logiciel comme «Trim Enabler» qui se trouve de ce fait frappé d'obsolescence. Rien d'étonnant, par suite, si le désir naturel de "persévérer dans leur être" (comme dit Spinoza) ne les conduise à émettre beaucoup plus de fumée que de lumière sur le nouvel état de la question, dans le but de garder à ce programme une apparence d'utilité.
Quels sont, sous «El Capitan», les ressorts de la prise en charge du Trim sur les SSD tiers ? 2 outils introduits par Apple simultanément : 1° une nouvelle extension spécifiquement dédiée à la prise en charge du Trim sur SSD tiers : la AppleDataSetManagement.kext qui, pour être activée, doit être localisée dans le répertoire-Système : /System/Library/Filesystems (et pas dans le répertoire : /System/Library/Extensions) ; 2° un nouveau programme binaire UNIX dédié à la gestion de la AppleDataSetManagement.kext --> le trimforce, installé nativement at: /usr/bin/trimforce.
Le nouveau binaire trimforce peut être invoqué selon 2 commandes basiques inverses (réclamant le privilège sudo) : sudo trimforce enable (qui active la AppleDataSetManagement.kext en mode interactif en impliquant de répondre y=yes à 2 demandes d'autorisation successives dans le «Terminal») et sudo trimforce disable (qui désactive la même kext) selon le même type de mode interactif à 2 échelons. Dans les 2 cas de figure, le programme trimforce a pour adresse automatique de sa cible (la AppleDataSetManagement.kext) le répertoire-Système : /System/Library/Filesystems où il doit pouvoir la trouver.
D'après mes expérimentations, il est bien évident que la désactivation du kext-signing n'est plus requise a priori, puisqu'il s'agit d'une Apple_kext native et non d'une Apple_kext patchée. Mais (sous «El Capitan»), il est requis au préalable, en se logeant pour ce faire dans la «Recovery HD 10.11», d'activer le nouvel utilitaire : Security Configuration (Configuration de Sécurité) pour désactiver l'option activée par défaut : Enforce System Integrity Protection sans quoi la commande sudo trimforce enable à partir de l'OS, quand bien même l'utilisateur passe-t-il en privilège root, n'est pas honorée. L'option Enforce System Integrity Protection une fois désactivée, le binaire trimforce se laisse très bien invoquer dans le «Terminal» en droit root et, après re-démarrage, l'Apple_kext native : AppleDataSetManagement.kext se trouve bien effectivement activée et prend en charge le Trim (il n'y a plus qu'à réactiver après coup, depuis la «Recovery HD», l'option Enforce System Integrity Protection de l'utilitaire : Security Configuration --> le nouveau protocole de sécurité est restauré - empêchant notamment des applications de manipuler la NVRAM - sans que l'opération antérieure d'activation de la kext : AppleDataSetManagement.kext ne soit résiliée).
La nouvelle kext Apple_native : AppleDataSetManagement.kext et le nouveau programme binaire : trimforce, d'après mes expérimentations, se laissent copier sans aucun problème, à partir de leur source (l'OS bêta «El Capitan») dans les OS antérieurs : «Yosemite 10.10», «Mavericks 10.9» & «Mountain Lion 10.8» aux emplacements requis : respectivement --> /System/Library/Filesystems/AppleDataSetManagement.kext & /usr/bin/trimforce ; et, après restauration des propriétaires sur le paquet de la kext et le fichier du binaire (par une double commande dans le «Terminal» : sudo chown -R 0:0 /System/Library/Filesystems/AppleDataSetManagement.kext & sudo chown 0:0 /usr/bin/trimforce), il est possible, d'une session admin de chacun de ces OS démarré (10.8, 10.9, 10.10, 10.11) de passer dans le «Terminal» la commande : sudo trimforce enable qui produit dans tous les cas de figure l'activation native du Trim sur un SSD tiers que l'utilisateur aurait installé en interne (à la place d'un HDD et/ou d'un Super-Drive) ou attaché en externe (par exemple en connexion Thunderbolt).
Cette compatiblité rétro-active est, d'après mes expérimentions, honorée pour tous les OS jusqu'à «Mountain Lion 10.8» compris. Dans l'OS «Lion 10.7», par contre, la commande trimforce à destination de la kext : AppleDataSetManagement.kext demeure sans effets.
--------------------
Pour les amateurs d'expérimentation, je mets grâcieusement à disposition pour téléchargement depuis le dossier public de ma «DropBox» le dossier : ☞APPLE-TRIM.zip☜ recelant les 2 outils extraits de l'OS «El Capitan-bêta» : la kext Apple_native rétro-compatible --> AppleDataSetManagement.kext et le programme binaire UNIX rétro-compatible --> trimforce.
Une fois le dossier dé-zippé, le plus simple, dans une session admin, est de déplacer a la mano la kext : AppleDataSetManagement.kext à l'adresse suivante : /Système/Bibliothèque/Filesystems (authentification par mot-de-passe admin requise) ; et pour le fichier trimforce, de passer par la fonctionnalité du Finder "Aller au dossier.." en pressant la combinaison de touches : ⌘⇧G (cmd maj G) et, dans la fenêtre de saisie qui s'affiche, de renseigner l'adresse : /usr/bin et presser le bouton : Aller --> le répertoire /usr/bin s'ouvre dans une fenêtre où il n'y a plus qu'à faire glisser le binaire : trimforce (authentification par mot-de-passe admin requise encore).
Cela fait, aller à : Applications/Utilitaires et lancer le «Terminal». Copier-coller en premier la commande :
Bloc de code:
sudo chown -R 0:0 /System/Library/Filesystems/AppleDataSetManagement.kext
Bloc de code:
sudo chown 0:0 /usr/bin/trimforceCela fait, au cas où le Trim serait activé via «Trim Enabler», relancer ce programme et choisir dans sa fenêtre de "Désactiver le Trim" --> le programme va requérir un re-démarrage avant lequel, en fermeture de session, il va restaurer à son intégrité l'Apple_kext patchée : IOAHCIFamily.kext, mettre à jour le cache-Système kernelcache et résilier en NVRAM l'argument de boot "developer". Ce re-démarrage (d'une pierre 2 coups) va permettre au kernel de charger (sous l'OS rétro-compatible concerné : 10.10, 10.9, 10.8) la kext Apple_native AppleDataSetManagement.kext fraîchement importée dans le répertoire /System/Libary/Filesystems.
Sur ces nouvelles bases, après le re-démarrage et la session ré-ouverte, relancer le «Terminal» et passer la commande :
Bloc de code:
sudo trimforce enable
Bloc de code:
This tool force-enables TRIM for all relevant attached devices, even though
they have not been validated for data integrity while using that functionality.
By using this tool to enable TRIM, you agree that Apple is not liable for any
consequences that may result, including but not limited to data loss
or corruption.
Are you sure you wish to proceed (y/N)?--> presser la touche y et ↩︎ afin d'agréer --> un nouveau menu ineractif s'affiche :
Bloc de code:
Your system will immediately reboot when this is complete.
Is this OK (y/N)?--> presser la touche y de nouveau et ↩︎ pour agréer --> le programme trimforce va activer la kext : AppleDataSetManagement.kext et le Mac va re-démarrer avec prise en charge par le kernel de l'extension active --> le Trim est désormais pris en charge par la néo-extension Apple (rétro-compatible) sans recours désormais à «Trim Enabler» qui est désactivé.
☞ Désormais, il n'y a plus (sous «Yosemite» du moins) d'Épée de Damoclès suspendue à un long et mince crin de cheval sur la tête de l'utilisateur
Dernière édition par un modérateur:
