Salut
Grdouv.
Ne désespère pas! Je viens ce matin, sur mon
MacBook Pro qui supporte actuellement «
Yosemite», de me livrer à l'expérience de ré-initialiser la NVRAM alors que «
Trim Enabler» était actif. J'ai réussi (avec beaucoup de difficultés - pour une raison que j'exposerai en apostille de ce billet
) à planter mon Mac au re-démarrage, et j'ai à la fin des fins accompli ma volonté de l'empêcher de
booter en obtenant le panneau d'interdiction de stationner si désiré
.
Odyssée personnelle assortie de commentaires
J'ai donc re-démarré sur la
Recovery HD et en réponse à la commande informative :
j'ai bien obtenu la réponse :
signalant que je m'étais bien enfoncé dans le trou. À partir de là, j'ai suivi la 1ère procédure décrite par
Oskar Groth, le développeur de «
Trim Enabler», sur sa page de
Cindori.org : ☞
Trim Enabler and Yosemite☜ qui devrait permettre de supprimer dans la mémoire NVRAM l'instruction de vérification du
kext_signing avant de lancer la procédure de reconstruction du
prelinked_kernel : kernelcache (qui est le cache comportant le code du
kernel + les abrégés aux
kexts se trouvant chargé au démarrage) --> cette procédure, censée restaurer le démarrage tout en laissant «
Trim Enabler» activé, n'a pas marché pour moi et je me suis retrouvé derechef bloqué au démarrage à l'écran d'interdiction de stationner (ce qui m'a ravi
).
J'ai donc appliqué la 2è procédure, qui consiste pour l'essentiel à supprimer la
kext : IOAHCIFamily.kext modifiée par «
Trim Enabler» par la commande :
Bloc de code:
rm -rf System/Library/Extensions/IOAHCIFamily.kext
qui détruit le bundle dans le répertoire des
Extensions de la Bibliothèque-Système de l'OS à la racine duquel l'opérateur s'est logé initialement par la commande
cd ad-hoc. Puis par la commande 'impossible' autant que 'bégayante' en apparence pour le lecteur inattentif :
Bloc de code:
cp -r [COLOR="Red"]/[/COLOR]System/Library/Extensions/IOAHCIFamily.kext System/Library/Extensions/IOAHCIFamily.kext
il est opéré une copie à partir du dossier des extensions de l'OS abrégé qui est le Système de la
Recovery HD (tout est dans la barre
/ du
/System/Library/Extensions/IOAHCIFamily.kext indiquant la source, car, lorsque on est démarré dans la
Recovery, le point de montage / indique non pas celui de l'OS - accessible seulement par l'intermédiaire du répertoire des
Volumes, mais le point de montage du Système de la
Recovery, lequel est un OS abrégé embarquant une Bibliothèque-Système comportant un dossier des
Extensions dans lequel réside l'original intouché de la
kext Apple_native : IOAHCIFamily.kext inactive par défaut avec les SSD de Tierce_Partie et chargée de gérer le
Trim des SSD Apple_natifs).
Donc la commande ci-dessus ordonne bien sans faute une re-copie de la
kext Apple_native : IOAHCIFamily.kext du dossier des
Extensions du Système de la
Recovery au dossier des
Extensions du Système de l'OS à la racine duquel l'opérateur s'est logé. CQFD.
À mon avis, la commande suivante de
Oskar Groth :
Bloc de code:
chown -R root:wheel System/Library/Extensions
est dispensable parce que futile, l'opérateur de la re-copie identifié dans le «
Terminal» de la
Recovery sous l'intitulé cryptique :
-bash-3.2# étant
root lui-même sous son nom de
shell comme le sigle terminal # réservé au
Super-User le signale. Donc aucune modification des accédants propriétaires au dossier des
Extensions de l'OS n'est effective à partir du
-bash-3.2#.
Quant à la commande suivante :
Bloc de code:
sudo chmod -R 755 System/Library/Extensions
elle est risible et indigne d'un développeur, car
root n'a pas à s'invoquer
sudoer pour accéder aux droits du Super-User qu'il ne serait pas en tant que simple
admin - puisqu'en tant que
root il est celui qu'il est (dédié au divertissement de
bompi ) et tout autant vouée à l'échec dans le «
Terminal» de la
Recovery qui ne gère qu'un
shell : le
-bash-3.2 dont le seul et unique opérateur est
root et qui, par voie de conséquence, rejette le préfixe de commande
sudo qui impliquerait l'existence d'un opérateur autre que
root. CQFD.
La commande :
Bloc de code:
touch System/Library/Extensions
est à la rigueur défendable pour réinitialiser la
temporalité d'accès au dossier des
Extensions qui vient d'être doublement modifié. Quand à la longue commande à rallonges de reconstruction du cache :
prelinked-kernel : kernelcache, elle me paraît dispensable et je m'en suis dispensé parce que pénible à saisir.
♤
Résumé pratique à l'usage du jeune Padawan Grdouv
En résumé pratique de ces salades, ô
Grdouv, contente-toi de re-démarrer dans la
Recovery par ⌘R et dans le «
Terminal» saisis d'abord :
et ↩︎ qui supprime l'écriture des variables en NVRAM. Puis enchaîne par le tout-en-un
Bloc de code:
cp -R /System/Library/Extensions/IOAHCIFamily.kext /Volumes/"CRUCIAL M4 128 Go"/System/Library/Extensions/IOAHCIFamily.kext
et ↩︎ par laquelle tu recopies la
kext Apple_native du dossier des
Extensions du Système intouché de la
Recovery dans le dossier correspondant de l'OS où elle se substitue en l'écrasant à la
kext modifiée par «
Trim Enabler». Par simple acquis de conscience, tu peux toujours conclure par :
Bloc de code:
touch /Volumes/"CRUCIAL M4 128 Go"/System/Library/Extensions
et ↩︎ (fais un copier-coller de la destination d'après la commande précédente).
C'est ce que je me suis contenté de faire avec mon Mac, et j'ai re-démarré sans aucun problème pour la raison fondamentale que la
kext bidouillée avait été restaurée à son intégrité native. Une fois relogé dans ta session, tu peux relancer «
Trim Enabler» et le ré-activer da capo sans problème de
rebootage.
♧
Apostille à vocation d'apaisement des anxieux
Il existe comme je viens de m'en apercevoir ce matin une parade impeccable au risque de plantage sous
Yosemite provenant de la combinaison :
Trim Enabler activé x
Reset_NVRAM x
kext_signing : elle consiste dans l'installation de l'
Intercepteur d'EFI_Boot : «
rEFInd» que l'amateur trouvera sur le site de son développeur
Roderick Smith ☞
rEFInd☜.
Un MacUser sous
Yosemite qui installe «
rEFInd» en intercepteur de
boot de l'
EFI et qui démarre donc son Mac par l'intermédaire du panneau de
boot de «
rEFInd» (procédé qui permet par ailleurs d'activer l'option de
boot qu'on veut en mode graphique sans presser de touches au démarrage) - ledit MacUser, donc, peut ré-initialiser la NVRAM tant qu'il veut, la
kext_signing qui se ré-implémente dans la NVRAM en instruction passée à l'
EFI ne ... passe pas l'écran de
boot de «
rEFInd» dont l'interception neutralise cette instruction [ce - du moins d'après mon expérience sur mon
MacBook Pro]. Le
boot de l'OS avec «
Trim Enabler» activé s'opère donc même à NVRAM réintialisée
.
[NB. Il m'a fallu faire sauter «rEFInd» et aussi son cache pour pouvoir planter mon Mac ce matin par ré-initialisation de la NVRAM et «Trim Enabler» activé.]
♡
<sinon,
Grdouv, en désespoir de cause, inutile de te transformer en mécanicien pour démonter ton disque : dans la
Recovery, tu actives la fonction :
Ré-installer OSX qui va télécharger un installateur de
Yosemite tout neuf (long car +5Go comprimés) puis ré-écrire à partir de lui les fichiers-système de ton OS dans la préservation des données utilisateurs. Et hop!
boot. Ce me semble bien lourd comme procédé, néanmoins, puisque le seul changement qui va être apporté au système va consister à écraser la
kext bidouillée par «
Trim Enabler» :
IOAHCIFamily.kext par la
kext Apple_native non bidouillée, chose que tu peux faire rapido presto avec la commande dans le «
Terminal» qui puise dans les ressources de l'OSX abrégé de la
Recovery - lequel peut être vu comme une espèce de garde-meubles bien ustensile à l'occasion
>
♢
