... j'attends les retours des expérimentateurs 
A priori trimenlabler fait déjà cette manipulation ... donc donc ... a suivre
Relis bien à partir de #81 et prête attention à la #86.
La version 3.3 de Trim Enabler modifie bien un fichier système au risque de se retrouver avec un écran gris bloquant complètement le Mac. De plus, la fonction PRAM devient inopérante.
A priori non, puisque zapper la PRAM cause le problème de Trim avec Trim enabler.
Alors que la solution 3 posts au dessus n'expose plus au problème quand on zappe la PRAM
"Bien entendu le zap de PRAM n'a alors plus le moindre effet sur la machine."
La toute dernière suite du fil de MacBidouille, à l'air de monter que TE fait déjà la même chose que la modification préconisée en début de leur fil, et même en mieux, alors j'attends encore un peu avant de me lancer.
À part
Sly dont la 'confiance a priori' dans le
patch du fichier
com.apple.boot.plist montre qu'une âme emplie de vaillance vibre sous la modestie du modérateur
(mais qu'est-ce que je raconte? ) et bien entendu
marcucci acquis à la recette "apparemment" valide signalée par l'article de «
MacBidouille» - je note quatre réactions de prudence et d'expectative : celles de
Jacques, de
Jean-François, de
Locke et d'
Ibiscus.
Comme un goût immodéré de l'expérimentation a toujours animé
macomaniac (en quoi on reconnaîtra sans mal un effet de possession par le «
Démon de la Perversité» d'
Edgar Poe - d'autres parleraient plus crûment de "masochisme") - je me suis livré ce matin à un de mes exercices favoris : essayer de planter mon Mac
...
♤
Avant de procéder à l'édition du fichier
com.apple.boot.plist préconisée dans l'article cité, j'ai été inspecter ledit fichier que je connais bien, parce que depuis que j'ai mon
MacBook Pro_Early 2011 j'ai implémenté le
kernel_flag présentant normalement une chaîne vide par le syntagme
arch=x86_64 mbasd=1 qui permet l'utilisation du
Super-Drive Externe USB d'Apple, normalement non supporté par ce modèle de Mac, en faisant croire au Système qu'il tourne sur un
MacBook Air.
J'ai constaté que l'implémentation censée devoir être créée par la commande dans le «
Terminal» se trouvait déjà en place en supplément de la précédente, à savoir :
kext-dev-mode=1 sans que je l'y ai inscrite volontairement moi-même. Je conjecture que cette implémentation a dû provenir du logiciel «
Trim Enabler» lui-même (sans pouvoir en administrer la preuve cruciale) - ce qui (toujours conjecturalement parlant) m'amène à penser que le
patch préconisé isolément serait donc
redondant par rapport à celui produit par «
Trim Enabler».
Sachant que les précautions prises par «
Trim Enabler» (modification de l'
argument de boot dans la mémoire statique
NVRAM précisément à la valeur :
boot-args=kext-dev-mode=1 ; mise-à-jour du
kernelcache solidarisant le code du
kernel avec le bloc des extensions à charger 'sans examen' ; enfin apparemment le
patch du fichier
com.apple.boot.plist) n'empêchent pas
d'après mes expériences répétées antérieures le plantage du Mac devant le panneau d'interdiction de stationner en cas de ré-initialisation de la
NVRAM et/ou de démarrage en
Safe Boot --> mon imagination ne pouvait que conjecturer le caractère inéluctable du plantage à brève échéance si je récidivais ces 2 options de
boot.
♧
Je dois reconnaître qu'un facteur de résistance puissant au plantage est constitué par l'intercepteur de
boot : «
rEFInd». Le
Trim activé sous «
Yosemite», je n'ai jamais réussi à planter mon Mac aussi lontemps que «
rEFInd» jouait le rôle d'intercepteur de l'itinéraire de l'
EFI au démarrage. À croire (pure supputation personnelle) que l'
EFI ne parvient pas à passer au
kernel via le
Boot_Loader : boot.efi l'argument du
kext_signing (s'il s'est recréé en
NVRAM) dès lors que «
rEFInd» s'intercale en instance intermédiaire ('
go-between').
Il est d'ailleurs assez difficile de désactiver «
rEFInd» à cause d'un puissant effet d'inertie par mise en cache du code du logiciel au démarrage. J'ai donc dû insister pesamment afin d'éliminer cette véritable «
égide» de démarrage. Dès que j'y suis parvenu, le
patch du fichier
com.apple.boot.plist n'a pas permis (comme conjecturé) d'empêcher le plantage classique (désormais) après
reset_NVRAM (qui supprime l'argument de
boot :
kext-dev-mode=1) et/ou démarrage 'sans extensions' (lequel supprime le
kernelcache 'bienveillant').
♡
J'ai le plus grand mal à croire (personnellement) à l'argument de l'auteur du
patch (relayé sur simple
ouï-dire et sans aucun effort
expérimental par l'article de «
MacBidouille - ce qui me semble au-delà de 'léger' comme attitude publique) : à savoir que le
kernel, une fois chargé par le
Boot_Loader : boot.efi, commencerait par visiter un dossier de
Préférences de la
Bibliothèque Générale de l'OS pour savoir quels arguments il doit prendre en compte avant de charger les
kexts qui sont les extensions immédiatement contiguës du noyau.
J'ai tendance à me figurer au contraire que le
kernel charge directement les
kexts en prenant en compte les arguments
a priori à lui passées par l'
EFI après visite de la mémoire statique
NVRAM et que la
Bibliothèque de référence pour le
kernel au
boot est celle du
Système, pas la
Générale - laquelle relèverait bien plutôt du 1er processus
extra_kernel : à savoir le processus
launchd.
Je veux bien imaginer (s'il le fallait) qu'en cours d'extinction régulière du Mac, le
kernel puisse allouer récursivement à la
NVRAM la valeur du
kernel_flag du fichier des préférences de
boot. Mais alors, quid si la
NVRAM est zappée ensuite
on_launch? Quid même en cas d'extinction forcée du Mac (suite à des blocages dans une session ouverte) et re-démarrage 'sans 'extensions'?
♢
Tout cela, j'en ai conscience, ne sont que des supputations, car je n'ai pas conduit de protocoles expérimentaux suffisants pour apporter des preuves de ces conjectures 'errantes'. Mais comme le disait si bien
Descartes : il suffit que je puisse «
imaginer le moindre doute» (concernant ici l'effet correcteur récursif du
patch du fichier
com.apple.boot.plist sur le travail du
kernel au démarrage), pour que la prudence soit de mise.
Surtout quand, ledit
patch en place et bien en place, il s'avère que le Mac sur lequel le
Trim est activé et supportant «
Yosemite» est tout ce qu'il y a de plantable (comme j'en ai fait l'expérience ce matin).
♘
J'avoue que j'ai enduré les
pires difficultés à me tirer de cet embarras (que j'avais bien cherché
), parce que les procédés via le «
Terminal» de la «
Recovery HD» (que je connais bien maintenant) sont très loin d'être infaillibles... Ça peut aller profond dans le plantage, cette histoire - au point même d'invalider le
boot sur la «
Recovery HD» (reste la «
Recovery on-line» - plaideront les optimistes
).
Je ne saurais trop répéter le conseil que j'avais déjà donné : ayez un Système démarrable qui ne soit pas «
Yosemite» (que ce soit sur un DDE, ou préférablement même sur une petite partition du SSD), OS dans lequel vous veillez à copier l'installateur de «
Yosemite» absolument synchronisé avec la version du «
Yosemite» installé sur le SSD --> une méthode qui marche absolument à
100% est la ré-installation de l'OS par ré-écriture des fichiers-système (et absolument pas un rétro-clonage à partir d'un clone qui, miroir de l'OS en place, ne re-copiera qu'un Système voué à son tour au plantage). De plus, quelqu'un qui a un installateur sous la main ne passera gère plus de temps à une ré-installation de «
Yosemite» qu'à un rétro-clonage voué à l'échec...
♖
