10.12 Sierra Mises à jour Maj/Min et SSD

[MakMak]

Bonjour à tou(te)s,

Après plusieurs recherches sur le net, et ce depuis une clean install sur un Mac Mini (merci encore @litobar71 & @Fullcrum ), me revoilà désormais sur mon MacBook Pro Early 2011 équipé d'un SSD (sous macOS Sierra). J'ai actuellement l'App Store qui me propose :

- Mise à jour de sécurité 2019-003 10.12.6.
- Mise à jour iTunes pour la prise en charge d'appareils.

J'avoue avoir hésité un instant à installer ces MAJ car une question me taraudait après être tombé sur l'explication de @macomaniac sur ce fil

Trim enable SSD Tiers et format APFS

Je sais (du moins à minima j'ose espérer) que la fonction TRIM est nécessaire pour les SSD tiers et que cette fonction TRIM doit être désactivé lors d'une MAJ Majeure (ou intervention SMC/NVRAM). Mais je me demandais si les MAJ Mineures nécessitaient aussi une désactivation du TRIM ? Une MAJ Mineure s'applique aussi bien sur l'hardware que le Software si je ne m'abuse ? o_O
Et d'ailleurs jusqu'à quels niveaux (hardware/software) les MAJ Majeures/Mineures vont-elles ?

Encore désolé si la question peut paraître bête initiale et qu'elle vient accompagnée d'autres..

Merci à vous !

 

[Fullcrum]

Salut,

Ne te prend le bulbe avec ça, cpie/colle cette commande dans le Terminal et valide par Entrer, active le c'est tout :

sudo trimforce enable

Pour faire simple ... le TRIM gère les blocs utilisés dans un disque SSD, tu n'as pas à t'en préoccuper, vraiment !

 

[litobar71]

pour faire compliqué, tu l'enable de janvier à fin juin puis tu le disable de juillet à fin décembre.

ton retour début 2020 serait sympa !

en fait si tu ne crées/effaces pas la moitié des gigas de ton SSD quotidiennement.. ..

enable tu écris plus rapidement mais tu effaces moins vite...etc..

 

[MakMak]

Bonjour Messieurs,

@Fullcrum Le TRIM est bien actif je vous rassure ! C’est juste que me prendre la tête des fois ça m’aide :banghead:

@litobar71 En 2020 j’espère au moins que j’aurais beaucoup plus d’acquis

En fait je me demandais simplement pourquoi on ne le désactivait pas pour une mise à jour mineure ? La MAJ Mineure ne va pas aussi « profondément » que la Majeure même s’il intervient au point de vue sécurité ?

 

[MakMak]

Du coup, si je comprends bien, pas besoin de désactiver le TRIM hormis pour les MAJ Majeures type OS/SMC/NVRAM ?

 

[nicomarcos]

Je viens d'apprendre quelque chose, je n'ai jamais désactivé le TRIM en aucun cas.
Bien ou pas bien ? (désactiver pour les MAJ majeures ?).

 

[litobar71]

je ne le l'ai jamais désactivé je crois, hormis en désactivant l'utilitaire payant Trim Enabler utilisé avant El Capitan.

mets ton Clone et ou ta Time Machine à jour avant une mise à jour, je pense que c'est le plus important.

par contre si ton Volume Macintosh HD (High Sierra/Mojave) est APFS quelques secondes supplémentaires sont nécessaires lors des démarrages si le Trim sur SSD tiers interne est activé (en tout cas sur mon mini).

Fais comme Fullcrum a dit, tu sauras à qui t'en prendre lors d'une catastrophe :hilarious:

 

[Membre supprimé 1060554]

Pourquoi désactiver le TRIM avant une mise-à-jour (interne à l'OS) ou une mise-à-niveau (à un OS supérieur) ?

- le TRIM dépend d'une extension du noyau > injectée dans le kernel en début de démarrage de macOS. Il est donc solidaire de macOS exclusivement.​

- une mise-à-jour ou mise-à-niveau crée un dossier macOS Install Data dans le volume de démarrage > dossier dans lequel coexistent : les ressources d'installation + un OS d'installation démarrable (qui est une version épurée de macOS identique à un OS de secours). Le Mac se trouve ensuite redémarré sur l'OS d'installation > afin que l'installation s'effectue à destination des fichiers de macOS non démarré.​

- l'OS d'installation (comme l'OS de secours auquel il est identique) --> n'inclut aucune extension du noyau activant le TRIM. Le TRIM se trouve donc automatiquement désactivé lors d'une mise-à-jour ou mise-à-niveau > par redémarrage automatique du Mac sur l'OS d'installation dépourvu d'extension gérant le TRIM.​

 

[nicomarcos]

Merci pour ces éclaircissements, je ne l'ai jamais désactivé et tout a toujours bien fonctionné (MAJ, etc..).

 

[litobar71]

je vérifie l'activité on/off du 'fameux' Trim (qui a fait coulé beaucoup d'ancres ) après mise à niveau, mise à jour, rétro clonage, réinstallation, test, reset NVRAM etc..

 

[Membre supprimé 1060554]

Précision technique -->

- je parlais précédemment exclusivement du TRIM activé volontairement par la commande : sudo trimforce enable => à destination de SSD de tierce partie (mis en remplacement d'un HDD d'usine).​

- cette commande effectue pour l'essentiel une copie > d'une extension intitulée : AppleDataSetManagement.kext et tenue en réserve at: /System/Library/Filesystems/AppleDataSetManagement.kext => dans le dossier des extensions du noyau : /System/Library /Extensions. Après redémarrage du Mac > la nouvelle extension fait donc partie du lot injecté dans le kernel au démarrage.​

- si l'on scrute la composition d'un OS d'installation (identique à un OS de secours) --> aucune extension AppleDataSetManagement.kext n'existe dans le dossier Filesystems de cet OS. Non plus bien sûr que dans le dossier Extensions. Le TRIM est donc bien inactif à destination de SSD de tierce partie lors des démarrages sur ces OS auxiliaires. À supposer l'extension en réserve présente --> aucune commande = trimforce enable ne pourrait la copier dans le dossier des Extensions de l'OS d'installation > car cet OS est monté en lecture seule.​

Note 1 : comment un utilisateur peut-il > le SIP activé verrouillant de manière immuable le dossier des Extension de macOS --> effectuer en mode sudo la copie d'une extension en réserve => à destination du dossier des Extensions verrouillé ? - par un passe-droit spécifique attaché à l'utilitaire trimforce appelé par la commande : cet utilitaire a le privilège d'outrepasser les flags du SIP sur le répertoire des Extensions de maCOS.

Note 2 : le SIP automatiquement actif sur des SSD Apple d'usine --> dépend d'une autre extension du noyau (intitulée : IOAHCIFamily.kext) nativement présente dans les Extensions de macOS. Et faut-il ajouter dans le dossier des Extensions d'un OS d'installation ou de secours. Il s'agit là d'une fonction automatique au démarrage > que l'utilisateur ne peut pas affecter volontairement sur un OS auxiliaire.

 

[MakMak]

Merci de vos retours @macomaniac & @litobar71 !

Edit : désolé @macomaniac je répondais en même temps avant ton dernier message...

je ne le l'ai jamais désactivé je crois, hormis en désactivant l'utilitaire payant Trim Enabler utilisé avant El Capitan.

mets ton Clone et ou ta Time Machine à jour avant une mise à jour, je pense que c'est le plus important.

par contre si ton Volume Macintosh HD (High Sierra/Mojave) est APFS quelques secondes supplémentaires sont nécessaires lors des démarrages si le Trim sur SSD tiers interne est activé.

Fais comme Fullcrum a dit, tu sauras à qui t'en prendre lors d'une catastrophe :hilarious:

Pour le moment je suis en HFS+, je me laisse un peu de temps pour l'APFS !
Mais mon TRIM est déjà actif depuis plusieurs semaines en tout cas.
Je me demande si je n'ai pas déjà fais une MAJ interne sans le désactiver d'ailleurs il y a quelques temps... car je me souviens avoir eu peur que ça ne mette la pagaille (pas de soucis particulier sauf une frayeur). Je suis passé sur SSD, sans le savoir, au moment où TRIM Enabler était remplacé par la ligne de commande.

Pourquoi désactiver le TRIM avant une mise-à-jour (interne à l'OS) ou une mise-à-niveau (à un OS supérieur) ?

- le TRIM dépend d'une extension du noyau > injectée dans le kernel en début de démarrage de macOS. Il est donc solidaire de macOS exclusivement.​

- une mise-à-jour ou mise-à-niveau crée un dossier macOS Install Data dans le volume de démarrage > dossier dans lequel coexistent : les ressources d'installation + un OS d'installation démarrable (qui est une version épurée de macOS identique à un OS de secours). Le Mac se trouve ensuite redémarré sur l'OS d'installation > afin que l'installation s'effectue à destination des fichiers de macOS non démarré.​

- l'OS d'installation (comme l'OS de secours auquel il est identique) --> n'inclut aucune extension du noyau activant le TRIM. Le TRIM se trouve donc automatiquement désactivé lors d'une mise-à-jour ou mise-à-niveau > par redémarrage automatique du Mac sur l'OS d'installation dépourvu d'extension gérant le TRIM.​

Si j'essaie de bien te comprendre (désolé, je cherche la mécanique avant tout), cela voudrait donc dire que :
- lors de l'installation d'une Mise-à-jour/Mise-à-niveau, le TRIM est automatiquement désactivé par l'OS d'installation, mais s'il n'a pas été désactivé "manuellement" en amont par l'utilisateur, c'est là qu'il y aura un problème (le fameux soucis de l'ordinateur qui ne démarre plus).
- il faut donc le désactiver avant l'installation, qu'importe le type de Mise-à-jour/niveau.

Du coup, c'est là où je m'y perds vu que certaines personnes font les mises-à-jour (interne à l'OS) sans le désactiver et n'ont pas de soucis. A moins que je vive encore dans un temps où Yosemite nous faisait jongler, ce qui n'est pas impossible non plus...

 

[MakMak]

Note 1 : comment un utilisateur peut-il > le SIP activé verrouillant de manière immuable le dossier des Extension de macOS --> effectuer en mode sudo la copie d'une extension en réserve => à destination du dossier des Extensions verrouillé ? - par un passe-droit spécifique attaché à l'utilitaire trimforce appelé par la commande : cet utilitaire a le privilège d'outrepasser les flags du SIP sur le répertoire des Extensions de maCOS.

Note 2 : le SIP automatiquement actif sur des SSD Apple d'usine --> dépend d'une autre extension du noyau (intitulée : IOAHCIFamily.kext) nativement présente dans les Extensions de macOS. Et faut-il ajouter dans le dossier des Extensions d'un OS d'installation ou de secours. Il s'agit là d'une fonction automatique au démarrage > que l'utilisateur ne peut pas affecter volontairement sur un OS auxiliaire.

Oui j'avais compris la même chose ici (si je ne me trompe pas) : en gros, le "forcing" de la ligne de commande induit par le sudo permet d'outrepasser le SIP (même en étant Administrateur). Le SIP, étant inactif sur les SSD Tierces, n'est donc lié à aucune extension de noyau donc il faut le désactiver avant installation de Mise-à-jour/niveau. Voilà comment je le comprends..

 

[Membre supprimé 1060554]

Pendant toute une période allant jusqu'à la version de l'OS Yosemite 10.10.4 --> aucune extension Apple supplémentaire ne prenait en charge le TRIM sur les SSD de tierce partie. Un bidouillage de l'extension native Apple (via le logiciel Trim Enabler) --> permettait l'extension de fonctionnalité aux SSD de tierce partie.

Avec l'OS Yosemite > a été introduit un protocole dit le kext_signing --> déterminant une vérification automatique de l'intégrité des extensions Apple avant leur injection dans le kernel. L'extension bidouillée pour gérer les SDD de tierce partie se trouvait donc rejetée.

À moins d'une bidouille supplémentaire > consignant dans la NVRAM une option de démarrage de type "développeur" autorisant la présence d'extensions modifiées et désarmant le kext_signing sur l'extension modifiée. À la condition supplémentaire de mettre-à-jour le cache de démarrage prelinkedkernel incluant le tableau des extensions à injecter "en bloc" dans le kernel.

La moindre foirade dans ces prérequis --> induisait un plantage sans appel du démarrage du Mac (avec le sigle d'interdiction de stationner). Je pense que c'est par référence à ce contexte historique assez "tremblant" (il faut bien le dire) --> que le conseil de désactiver le TRIM avait un sens : dans le contexte donc d'un OS Yosemite de la version 10.10.0 à la version 10.10.4.

À partir de la version 10.10.4 > la commande Apple : sudo trimforce enable est devenue disponible. Copiant une extension en réserve légitime (signée Apple) dans les Extensions --> il n'y avait plus aucun problème avec le kext_signing. Ce sont les utilisateurs qui demeuraient accrochés au logiciel Trim Enabler qui avaient des soucis résiduels à se faire. Le développeur du logiciel a fini par créer une extension de tierce partie pour gérer le TRIM > extension se logeant dans les Extensions de la /Library et pas de la /System/Library. Quand ça n'avait plus d'intérêt - en somme...

En résumé : si ton OS est au moins Yosemite 10.10.4 > et si tu as activé le TRIM par la commande : sudo trimforce enable (et pas via Trim Enabler) --> tu ne risques rien.

 

[Invité]

Tiens d'ailleurs, c'est quoi la commande du Terminal pour vérifier qu'il est activé ?

 

[MakMak]

Pendant toute une période allant jusqu'à la version de l'OS Yosemite 10.10.4 --> aucune extension Apple supplémentaire ne prenait en charge le TRIM sur les SSD de tierce partie. Un bidouillage de l'extension native Apple (via le logiciel Trim Enabler) --> permettait l'extension de fonctionnalité aux SSD de tierce partie.

Avec l'OS Yosemite > a été introduit un protocole dit le kext_signing --> déterminant une vérification automatique de l'intégrité des extensions Apple avant leur injection dans le kernel. L'extension bidouillée pour gérer les SDD de tierce partie se trouvait donc rejetée.

À moins d'une bidouille supplémentaire > consignant dans la NVRAM une option de démarrage de type "développeur" autorisant la présence d'extensions modifiées et désarmant le kext_signing sur l'extension modifiée. À la condition supplémentaire de mettre-à-jour le cache de démarrage prelinkedkernel incluant le tableau des extensions à injecter "en bloc" dans le kernel.

La moindre foirade dans ces prérequis --> induisait un plantage sans appel du démarrage du Mac (avec le sigle d'interdiction de stationner). Je pense que c'est par référence à ce contexte historique assez "tremblant" (il faut bien le dire) --> que le conseil de désactiver le TRIM avait un sens : dans le contexte donc d'un OS Yosemite de la version 10.10.0 à la version 10.10.4.

À partir de la version 10.10.4 > la commande Apple : sudo trimforce enable est devenue disponible. Copiant une extension en réserve légitime (signée Apple) dans les Extensions --> il n'y avait plus aucun problème avec le kext_signing. Ce sont les utilisateurs qui demeuraient accrochés au logiciel Trim Enabler qui avaient des soucis résiduels à se faire. Le développeur du logiciel a fini par créer une extension de tierce partie pour gérer le TRIM > extension se logeant dans les Extensions de la /Library et pas de la /System/Library. Quand ça n'avait plus d'intérêt - en somme...

En résumé : si ton OS est au moins Yosemite 10.10.4 > et si tu as activé le TRIM par la commande : sudo trimforce enable (et pas via Trim Enabler) --> tu ne risques rien.

C'est bien çà @macomaniac comme tu le dis je pense que je suis resté bloqué aux informations disponibles de l'époque de Yosemite 10.10.4.
Si je te suis bien, cette fonction du "sudo trimforce enable" est désormais "validée" par Apple et donc prise en charge dans les Extensions, de quoi ne plus se poser la question de cette foirade.
Etant sous 10.12.6, avec la commande "sudo trimforce enable" active, je ne devrais donc pas rencontrer de soucis particulier à l'installation de Mise à jour de sécurité 2019-003 10.12.6 et la Mise à jour iTunes pour la prise en charge d'appareils qui nécessite le redémarrage.
C'est ce terme "redémarrage" qui m'a fait me poser la question et venir ici et me rendre compte qu'en effet, JE n'était pas à jour sur toutes ces informations concernant le TRIM et sa nouvelle gestion depuis la fin de Yosemite.
Merci encore @macomaniac en tout cas de tous ces éclaircissements !

 

[MakMak]

Tiens d'ailleurs, c'est quoi la commande du Terminal pour vérifier qu'il est activé ?

Je ne sais pas s'il existe une ligne de commande pour le voir vu que je ne suis pas expert, mais tu peux déjà checker (si je ne dis pas de bêtises) via :
Pomme > A propos de ce mac > Rapport Système > SATA/SATA EXPRESS puis regarder la ligne Prise en charge du TRIM

 

[nicomarcos]

Voilà c’ est plus simple !

 

[Invité]

Je ne sais pas s'il existe une ligne de commande pour le voir vu que je ne suis pas expert, mais tu peux déjà checker (si je ne dis pas de bêtises) via :
Pomme > A propos de ce mac > Rapport Système > SATA/SATA EXPRESS puis regarder la ligne Prise en charge du TRIM

Oui, mais j'ai un doute. Je ne me souviens pas de l'avoir fait :banghead: alors que d'après cette fenêtre il est activé…

 

[nicomarcos]

Sinon ÊtreCheck te le dit aussi.