Je reviens avec une confirmation empirique supplémentaire :
Eh oui! Un simple démarrage en mode 'sans extension' (= 'sans échec' =
Safe Boot) avec la touche ⇧ pressée suffit également à planter le Mac devant l'écran d'interdiction de stationner - ce en cas de
Trim activé par «
Trim Enabler», SSD de Tierce-Partie et OS «
Yosemite» (comme je l'ai volontairement expérimenté ce matin avec 'succès'
).
Allez! Un petit effort spéculatif de plus,
macomaniac... Donc la question est : pourquoi?
J'ai l'impertinence
de penser que la question du
cache est bien concernée. Car le démarrage sans extensions, outre la désactivation des
kexts de Tierce-Partie et d'une grappe d'
Apple_kexts dispensables, a la propriété de vider les caches-système, justement.
Facteur confirmé par une expérimentation croisée (si! si! j'ai recommencé à chercher et ... à trouver le plantage
) : j'ai vidé les caches-sytème en utilisant le logiciel «
Tinker Tool» de
Bresink (et rien qu'eux) --> résultat : au re-démarrage, écran de stationnement interdit.
J'en tire bien la conséquence que «
Trim Enabler» :
- bidouille l'Apple_kext : IOAHCIFamily.kext ;
- modifie la variable de boot-args en NVRAM à : kext-dev-mode=1 par la commande :
Bloc de code:
nvram boot-args=kext-dev-mode=1
- remet les pendules à l'heure sur le répertoire global des Extensions par la commande :
Bloc de code:
touch /System/Library/Extensions
- re-crée le prelinked-kernel : kernelcache (at:/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache) - ce en lui allouant le code du kernel (dont la localisation et la dénomination ont changé sous «Yosemite» --> il s'agit désormais de : /System/Library/Kernels/kernel) assorti de l'adressage aux kexts (at: /System/Library/Extensions) intégrées au cache en mode 'chargement licite' ('allowed to load') . Càd passe une commande du type :
Bloc de code:
kextcache -prelinked-kernel /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache -K /System/Library/Kernels/kernel /System/Library/Extensions
La simple suppression de ce
kernelcache chargé par le
Boot_Loader : boot.efi au démarrage en lieu et place du
kernel brut suffit à planter le Mac devant l'écran d'interdiction de stationner.
Càd. même si la variable de boot en NVRAM est bien sur l'exception :
kext-dev-mode=1 préservée, le
kernel à qui l'
EFI a passé l'argument via le
boot.efi n'est capable de valider au chargement la collection des
kexts (dont la
kext bidouillée) que s'il s'agit d'un
cache global pré-emballé selon le mode '
allowed to load' ; si un tel cache fait défaut (comme après un démarrage sans extensions donc) et que le
kernel, nanti de l'instruction
kext-dev-mode=1 a priori, soit obligé de charger sériellement les
kexts une à une - alors la sanction tombe : parvenu laborieusement (le temps de chargement est nettement plus lent que via le cache) à la
kext bidouillée :
IOAHCIFamily.kext, ça bloque sans appel. Malgré l'argument d'exception
kext-dev-mode=1 passé par l'
EFI. Qui manifestement ne suffit pas à faire 'avaler' sous «
Yosemite» le chargement de la
kext au code modifié dès lors qu'elle n'est pas offerte au
kernel par l'intermédaire d'un 'cache vertueux'
[cachez ce sein que je ne saurais voir ].
☞ Je suspends là ces élucubrations dignes de la «
Scolastique» revisitée par
Achille Talon pour constater qu'avoir le
Trim activé sous «
Yosemite» sur un SSD de Tierce-Partie par «
Trim Enabler» forclot strictement
2 options de boot sous peine de plantage :
- Le reset_NVRAM qui fait sauter la variable de boot : kext-dev-mode=1 et restaure l'instruction du kext_signing ;
- Le Safe_Boot qui efface le prelinked-kernel : kernelcache en forçant le kernel à charger individuellement les kexts 'telles quelles', avec le blocage au chargement de la IOAHCIFamily.kext malgré l'argument du kext-dev-mode=1.
En résumé : ça craint
.
