☝︎
Je viens de lire ce fil que j'avais négligé - mon attention à la fois
diluée sous l'afflux panique des messages de plaignants qui viennent d'installer «
Yosemite» et
focalisée qu'elle était sur les abstruses considérations techniques de ce fil connexe :
redemarrage-impossible-yosemite-a-cause-de-trim-enabler (à quoi tout esprit spéculatif reconnaîtra immédiatement le symptôme pathologique d'un sujet se débattant dans les affres d'une
conscience paradoxale...
)
Ayant volontairement planté mon Mac (supportant à la fois un SSD 'Crucial' de Tierce-Partie, l'OS «
Yosemite» et l'activation du
Trim par «
Trim Enabler») en ré-initialisant la mémoire NVRAM à répétition pour expérimenter l'écran de stationnement interdit et la validité de commandes de récupération dans le «
Terminal» de la «
Recovery HD» - je dois dire, malgré le succès pratique de mes tests, que je partage la 'prudence inquiète' de
r e m y .
Parce que le fonctionnement de «
Trim Enabler» me paraît reposer sur un château de sable, susceptible à tout moment d'être balayé par un incident pour laisser l'utilisateur essuyer les plâtres du plantage de son Mac.
Car cette fameuse instruction du
kext_signing introduite par «
Yosemite», c'est-à-dire de la vérification d'intégrité inaugurale du dossier des
Extensions de l'OS, elle réside où? Eh bien! dans la mémoire statique NVRAM de la Carte-Mère dont l'
EFI 'visite' a priori les variables au démarrage avant de les passer au
kernel via le
Boot_Loader. Abstrus, non?
✻
Oui, mais voici à présent un joli petit problème digne de la «
Philosophie» : à supposer (via le «
Terminal» et le programme UNIX :
nvram ou par la médiation de «
Trim Enabler») que les variables de cette mémoire NVRAM soient modifiées, comment se fait-il qu'une ré-initialisation de la NVRAM (par la combinaison de touches ⌘⌥PR ou suite à un incident involontaire !) fasse retourner automatiquement la NVRAM à l'instruction du
kext_signing (et pas à un degré zéro d'instructions)?
J'avoue que cette question me taraude l'esprit et je me demande (simple conjecture de ma part - moi qui suis dénué de la moindre culture informatique malgré les apparences et uniquement doté de la capacité de raisonner et d'imaginer induite par l'apprentissage des «
Humanités Classiques») si l'installation de la version client finale de «
Yosemite» n'introduit pas, sur les Macs concernés, une 'mutation irréversible' de contenu de la NVRAM (un peu à l'image de ce qui se passe pour la puce de la Carte-Mère qui recèle le
Firmware de l'
EFI, où il y a une irréversibilité des écritures logicielles apportées par les
MÀJ successives)?
À savoir le
'boot-arg' du
kext_signing comme instruction par défaut inéliminable en dernière instance, car, autrement, d'où vient la récupération par la NVRAM de la variable du
kext_signing après
reset - je le demande?
[NB. je fais grâce ici de mes spéculations sur la 'source' de cette 'permanence' de l'argument].
S'il en était ainsi (fragile conjecture spéculative de ma part), en quoi consiste donc la 'neutralisation' de la part du logiciel «
Trim Enabler» de l'instruction du
kext_signing en NVRAM? Dans une '
préférence' - je me l'imagine - substituant comme valeur de la variable de boot l'argument :
nvram boot-args=kext-dev-mode=1 autorisé par Apple afin de permettre aux développeurs de tester expérimentalement des versions d'OSX (càd. 'mode développeur de kext' = TRUE). 'Préférence' toute provisoire, puisque cet argument définissant la variable de boot en NVRAM saute immanquablement à tout
reset qui réinstruit l'argument du
kext_signing comme instruction par défaut de la NVRAM.
Si le processus réel correspond tant soit peu à cette interprétation abstruse autant que spéculative, alors tout incident susceptible d'agir sur la NVRAM va rétablir l'argument du
kext_signing comme instruction de boot de la NVRAM visitée par l'
EFI au démarrage et passée au
kernel via le
Boot_Loader.
❈
En quoi consiste cet argument nouveau du
kext_signing? Je me le représente comme une injonction composite portant globalement sur le répertoire des
Extensions, comportant entre autres l'instruction spécifique au
kernel de suspendre le chargement en cas de rencontre d'aucune
kext : Apple_native dont l'intégrité de la
code_signature aurait été brisée par un bidouillage. Ce qui est le cas pour «
Trim Enabler qui 'patche' la
kext Apple_native : IOAHCIFamily.kext chargée de gérer le
Trim sur les SSD Apple.
«
Trim Enabler» marche (pour autant que je me le figure) après bidouillage de cette
kext : a) grâce à la définition de la variable de boot en NVRAM comme
nvram boot-args=kext-dev-mode=1 ; b) par une espèce d'effet de 'synchronisation' (par
touch) du dossier global des
Extensions ; et c) par la reconstruction du
prelinked-kernel : kernelcache (comportant le code du
kernel et les raccourcis aux
kexts) qui se trouve chargé au démarrage par le
Boot_Loader.
Je trouve cet échafaudage
fragile et susceptible d'
instabilité temporelle. Personnellement, dans mes expérimentations, j'ai réussi à faire sauter le contenu de la variable en NVRAM rien qu'en essayant de forcer sous Intel le chargement d'un programme PPC. S'en est suivi un plantage
sévère de mon
MacBook Pro et de petites manipulations dans le «
Terminal» de la «
Recovery HD» ne suffisent plus alors dans ce cas à surmonter l'interdiction de stationner qui signale un arrêt de chargement du
kernel.
Je pense que faire fonctionner «
Yosemite» avec activation du
Trim sur un SSD de Tierce-Partie, c'est comme banqueter chaque jour à la table du Bureau le front ceint de laurier et la mine rieuse avec une
Épée de Damoclès suspendue par un simple crin de cheval au-dessus de la tête... Je partage donc toutes les inquiétudes présentes
et à venir de
r e m y et la précaution avisée de
bompi : avoir de toutes nécessité un Système démarrable d'appoint, de préférence sur le disque interne même, comportant un OS absolument intouché au niveau des
Extensions Apple_natives. J'ajouterai même : embarquant comme ressource l'installateur de «
Yosemite» strictement contemporain de la
MÀJ de l'OS installée sur la partition correspondante du disque, de manière à pouvoir ré-installer à la volée sans perte de temps de téléchargement ni même courir le risque d'un non-démarrage sur la «
Recovery HD 10.10» (je le dis, car j'ai 'réussi' à planter même cette «
Recovery» - sans bidouiller ses extensions - dans mes efforts paroxistiques pour atteindre la limite de l'expérimentable
).
❀
