☝︎ Pas mal raisonné
(quoique ça ne marcherait pas, car tu n'aurais pas recréé le kernelcache dans l'OS de ton SSD - étant donné que, lui aussi, tu l'as supprimé avec ton démarrage "sans extensions" - cf. ci-dessous), mais dans un contexte où, manifestement, tu parais t'ingénier à te créer des embûches à toi-même !
Tu es en train de dire que l'OS de ton SSD n'est pas la version client régulère de «
Yosemite 10.10.1, mais que tu aurais installé de manière aventuriste le
build de la
bêta pour développeurs : «
Yosemite 10.10.2»? Tu le fais exprès ou quoi? Car, s'il en est ainsi, le fichier de référence
SystemVersion.plist dans le dossier de
boot :
com.apple.recovery.boot doit mentionner :
Bloc de code:
<key>ProductVersion</key>
<string>10.10.[COLOR="Red"]2[/COLOR]</string>
ce qui fait que, si tu actives après démarrage sur ta partition de récupération l'option :
Ré-installer OS X, le programme va chercher un
package : 10.10.2 sur les serveurs Apple pour le télécharger et... il ne va rien trouver. Parce qu'aucun
package : 10.10.2 n'y a été déposé à fin de ré-installation - les seuls présents étant ceux qui correspondent à des versions
client officiellement publiées - et dont le plus récent est le
10.10.1. Par suite, il devrait y avoir un message d'erreur si tu entamais cette manœuvre.
Et pourtant c'était bien la méthode de sauvetage la plus simple et sûre à 100% : car, la
NVRAM ayant été ré-initialisée chez toi dans son argument de
boot natif, l'OS ré-installé aurait eu sa
kext bidouillée par «
Trim Enabler» restaurée à son intégrité et donc un
nil obstat aurait sanctionné le démarrage sur l'OS remis à niveau. Mais il a fallu absolument que tu te coupes à toi-même cette possibilité...
(incroyable, non? 
). Je comprends pourquoi tu résistes invinciblement à ma suggestion pédagogique à laquelle
Ibiscus apporte en vain son soutien (
vox clamans in deserto)...
♤
J'entends d'ici un membre de la «
Société Philanthropique des Cloneurs» s'exclamer : puisque
Mic-M4c possède un clone du volume de son OS, que ne démarre-t-il pas sur son clone pour re-télécharger la
bêta de «
Yosemite 10.10.2» afin de l'appliquer ensuite à l'OS de son SSD? Cela re-viendrait à la méthode de
Ré-installation d'OSX de la «
Recovery HD» avec le bon
build ce coup-ci et ça prendrait exactement le même temps...
Sauf... si le clone susdit était suppporté lui-même par un SSD (n'oublions pas, c'est un
Mac Pro multi-disque), car dans ce cas, étant une image-miroir du Système de son SSD, il inclut l'activation du
Trim et la
kext bidouillée qui va de pair, alors même que la mémoire statique
NVRAM de la Carte-Mère du Mac a été ré-intialisée à sa valeur par défaut porteuse du
kext_signing --> il s'ensuit logiquement que le démarrage sur le clone, si supporté par un SSD alternatif, devrait planter - non? Si c'était un HDD, alors démarrage sans problème --> on tient ici une issue : ré-installer la
bêta.
♧
Évidemment, la solution la plus concise et élégante consiste à utiliser un «
Terminal» pour repasser en
NVRAM l'argument de
boot :
nvram boot-args=kext-dev-mode=1 qui permet aux développeurs de démarrer sur de l'expérimental. Mais, comme le développeur de «
Trim Enabler» s'en est avisé, ça ne marche que si le chargeur de l'OS (le
Boot_Loader : boot.efi) auquel l'
EFI passe l'argument lu en
NVRAM trouve à charger un "produit de synthèse" bien ficelé, qui est un
kernelcache dans lequel le code du
kernel se trouve associé à l'enveloppe globale des adresses des
kexts, bien synchronisées, avec imposition de l'option
all_loaded. Sinon, malgré le reconditionnement de l'argument de
boot en
NVRAM, le
Boot_Loader ne va trouver à charger que le
kernel natif solitaire, et c'est le
kernel qui va charger les
kexts en les passant en revue une à une... Et il ne va pas aimer quand il va tomber sur la
IOAHCIFamily.kext trafiquée, malgré l'injonction du
kext-dev-mode=1 (du moins, c'est ainsi que je me figure les choses).
Or évidemment
Mic-M4c, non content d'avoir invalidé la capacité de
Ré-installer OS X de sa «
Recovery HD» avec son installation d'une
bêta sur le disque du Mac, et pas non plus rassasié d'avoir fait un
reset_NVRAM pour faire sauter l'argument de
boot :
nvram boot-args=kext-dev-mode=1, en a rajouté une couche avec un démarrage '
Sans extensions' dont un effet collatéral est de
supprimer le startup-cache : kernelcache...
(oui : il le fait exprès, il veut vivre sur le fil du rasoir ).
Dans ce cas, le
Trim étant toujours activé dans l'OS du SSD et la
kext : IOAHCIFamily.kext toujours bidouillée, il doit être possible de faire ce qui suit --> démarrer sur la «
Recovery HD» avec les touches
⌘R pressées jusqu'à la , puis aller à la barre de menus supérieure de l'écran, menu
Utilitaires et lancer le «
Terminal». Alors :
- Saisir d'abord la commande :
Bloc de code:
nvram boot-args=kext-dev-mode=1
et ↩︎ (presser la touche 'Entrée' du clavier pour l'activer) --> l'argument de boot en NVRAM se trouve édité derechef au mode "développeur" (donc le reset_NVRAM annulé) --> re-démarrer le Mac en re-bootant dans la foulée, toujours par ⌘R, sur la «Recovery HD».
- Vérifier dans l'«Utilitaire de Disque» que le volume de l'OS du SSD est bien monté (après tout, pourquoi ne pas supposer la "totale"? qu'il serait chiffré par «FileVault-2» et donc non monté automatiquement en cas de démarrage sur la «Recovery HD»? ) --> si la ligne du volume était grisée : la sélectionner --> bouton 'Déverrouiller' --> saisie du mot-de-passe admin dans le panneau ad-hoc --> montage.
- Relancer maintenant le «Terminal» et saisir en premier :
et ↩︎ --> afin de vérifier quel est le nom exact du volume de l'OS du SSD. Par défaut, c'est Macintosh HD, dont il convient de neutraliser l'espace vide de l'intitulé dans une commande en embrassant le titre complet par des "" --> quel que soit le nom du volume de l'OS, mettre par prudence son intitulé complet exact entre "", dans mon exemple --> "Macintosh HD".
- Saisir à présent en préalable :
Bloc de code:
touch /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/System/Library/Extensions
et ↩︎ (mutatis mutandis pour le nom du volume de l'OS s'il y a lieu) --> cette commande sur un dossier restaure un timestamp uniforme de ses éléments ("remise des pendules à l'heure").
- À présent, conclure (si on veut faire dans le chirurginal ) par un kilométrique (attention aux espaces critiques !) :
Bloc de code:
kextcache -prelinked-kernel /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache -K /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/System/Library/Kernels/kernel /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/System/Library/Extensions
et ↩︎ --> Le processus dure un nombre certain de minutes (ne rien toucher dans le «Terminal» tant que l'invite de commande -bash-3.2# ne s'est pas ré-affichée). Le programme kextcache est invoqué ici avec le verbe -prelinked-kernel pour recréer de neuf le kernelcache (c'est le sens de la désignation initiale spécifiant la destination : /Volumes/"Macintosh HD"/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache) à partir des sources actuelles (le kernel par -K /Volumes//"Macintosh HD"/System/Library/Kernels/kernel et le dossier synchronisé des Extensions par /Volumes/"Macintosh HD"/System/Library/Extensions).
Comme il y a remise en cache des kexts une après l'autre, le retour de commande est verbeux. Invoquer la 'Main Invisible de la Providence' n'est pas superflu ici , pour lénifier l'appréhension de lire une série éventuelle de : Warning ! Invalid code signature (là, c'est mal barré).
- À complétion, eh bien! il n'y a plus qu'à re-démarrer pour voir si ça marche (à la sortie de «Yosemite» et à la révélation des problème occasionnés par le kext_signing si SSD de tierce-partie + trim enabler + reset_NVRAM et/ou suppression du kernelcache --> j'ai volontairement planté mon Mac de diverses façons une dizaine de fois en tout et j'ai la plupart du temps pu m'en tirer via le «Terminal» de la «Recovery HD». Mais pas toujours. En quelques cas, malgré des tentatives rééditées dans le «Terminal» de la «Recovery HD», pas d'autre issue que de ré-installer. Je ne sais pas si les versions de «Yosemite» > 10.10.0 sont toujours conciliantes).
♡
Bon, vous savez ce qui serait le plus simple : puisque le SSD, placé en externe (USB)
boote (quoique lentement), démarrer dans ce mode, re-télécharger la
bêta :
10.10.2, puis l'appliquer au volume même de l'OS --> la
kext : IOAHCIFamily.kext sera restaurée à son intégrité et le
Trim désactivé, un
kernelcache flambant neuf créé en sortie et la
NVRAM elle-même réinitialisée ne trouverait plus rien à dire à un démarrage sur le SSD replacé en interne.
En profiter pour télécharger et installer ☞
DiskMaker X☜ (gratuit - cliquer sur le lien en bleu) de
Guillaume Gète et lui faire créer une clé (8 Go)
bootable supportant l'installateur de la version exactement
synchrone du Système du SSD. Clé à éditer à chaque variation de version actuelle de l'OS du Mac.
[Ça reste pour moi l'énigme : comment se fait-il qu'il y ait boot sur le SSD déporté en externe - alors que dans tous les cas de figure (interne vs externe) le plantage logiquement devrait s'ensuivre?]
♢
