Le message affiché par l'option
verbose désigne le maillon déficient dans l'enchaînement logique du démarrage.
En bref : quand tu appuies sur le bouton "
Power" du Mac > tu lances le micrologiciel de la carte-mère appelé
EFI qui est en charge du
pré-boot ou préliminaire de démarrage.
L'
EFI visite la mémoire statique de la Carte-Mère appelée
NVRAM pour y lire les instructions de démarrage qui y sont inscrites. Il peut y avoir des "
options" de démarrage, comme le
SIP (le protocole de verrouillage du Système de l'OS après chargement) ; mais il y a aussi l'
adresse de démarrage mentionnée à une rubrique intitulée :
efi-boot-device = appareil de démarrage automatique de l'
EFI.
L'
EFI lit ce chemin de démarrage automatique > va au disque désigné > emprunte le secteur de boot constitué par la table de partition
GPT > accède à la partition désignée en
NVRAM via la
GPT. Sur l'en-tête du volume monté sur la partition se trouve inscrit à son tour le chemin qui mène au
boot_loader (démarreur) de l'OS.
L'
EFI suit ce chemin
\System\Library\CoreStorages\boot.efi et exécute le
boot_loader :
boot.efi trouvé en bout d'adresse - lequel est en somme une application de l'
EFI. Avec cette exécution du
boot_loader :
boot.efi prend fin le
pré-boot de l'
EFI et ce logiciel quitte automatiquement sur ce lancement qui constitue le premier maillon logique du
boot > ou démarrage de l'OS proprement dit.
=> si je rapporte le message verbeux à ce descriptif > je conclus que le
pré-boot de ton Mac (toute la séquence du ressort de l'
EFI) s'effectue
sans erreurs : l'
EFI trouve bien le
device (appareil) de démarrage (le volume sur la partition désignée) > le chemin d'accès au
boot_loader > et exécute le
boot.efi.
----------
Le
boot_loader :
boot.efi reçoit de l'
EFI au lancement les
options de démarrage chargées en
NVRAM (les
flags du
SIP par exemple) > et procède à sa mission qui est double :
charger le
kernel (ou noyau opératoire du Système) > et procéder à l'
injection des
kexts (ou extensions) dans le
kernel.
Pour ce faire > le
boot_loader :
boot.efi prend régulièrement un
raccourci logiciel --> au lieu d'exécuter le code du fichier "paradigme" du
kernel, situé dans «
Mavericks» at :
\mach_kernel > puis d'aller au dossier des
Extensions situé at :
\System\Extensions pour injecter
terme à terme une extension après l'autre ; le
boot_loader :
boot.efi passe par un
cache de démarrage-Système qui combine un
clone du code du
mach_kernel et le
tableau global des adresses d'extensions à injecter en mode :
all_loaded (bloc complet).
Ce cache de démarrage-Système établissant un «
prelinked kernel » (un
kernel "pré-attaché" à un tableau d'adresses d'extensions) s'intitule encore dans «
Mavericks» :
kernelcache (cache du
kernel) et est localisé at :
\System\Library\Caches\com.apple.kext.caches\Startup\kernelcache.
C'est à ce point précis de l'enchaînement déterministe du démarrage qu'intervient le plantage logique. L'option
verbose déclare :
Bloc de code:
ERROR! ! ! Uncompress prelinked kernel
ERROR! ! ! Load prelinked kernel -----
Error loading kernel cache
Erreur à la
décompression du
kernel pré-attaché dans le cache > erreur au
chargement du
kernel pré-attaché dans le cache :
erreur de chargement du
kernelcache.
À strictement parler > il ne s'agit pas comme cela arrive d'un échec relatif au processus de l'«
injection des
kexts » (injection des extensions dans le noyau d'après le tableau du cache) > mais d'une erreur
préalable à l'injection des
kexts : une erreur pure et simple de
chargement du
kernel ou noyau du Système -->
erreur à la décompression du
kernelcache empêchant le
chargement du
kernel en lui-même.
----------
Je me doute que cet examen minutieux a quelque chose de barbant > mais je me suis accroché à sa description littérale parce qu'il me paraît révélateur de la racine du problème.
Le
cache-Système de démarrage (
kernelcache) ne peut
pas être
lu d'entrée pour exécution du code du
kernel - voici ce qui me semble.
À partir de là > il y a 2 interprétations :
- le cache kernelcache est corrompu > ce qui occasionne une erreur de lecture par le boot_loader : boot.efi => il t'est très facile de vérifier si c'est là le facteur de plantage --> tu n'as qu'à démarrer ton Mac la touche ⇧(maj ou shift) tenue pressée jusqu'à affichage de la . C'est le démarrage dit "Safe_Boot" qui efface notamment le kernelcache de démarrage-Système > et procède à une exécution "paradigmatique" du boot : chargement du kernel "paradigme" = mach_kernel > puis injection des kexts en mode "terme à terme" (et pas en tableau).
=> tu vas bien voir si ton Mac démarre selon ce mode "retour au paradigme du boot".
- le cache kernelcache est illisible > parce qu'il y aurait une I/O error (Input/Output error : erreur d'entrée/sortie). Dans ce cas > c'est l'accès même au fichier-cache qui est problématique.
La raison ? - quand tu dis qu'il a fallu 4 jour à l'«Assistant de Migration» pour récupérer les données d'une sauvegarde sur un disque Lacie FireWire 800 => Thunderbolt > alors même que le volume de destination réside sur le Volume Logique d'un CoreStorage Fusion Drive > avec un SSD moteur de 120 Go --> je ne peux que conjecturer un problème de disque. Il est totalement irrégulier que le débit en écriture ne soit que de 2 Mo/s (je me suis amusé récemment, avec ma trapanelle MacBook Pro 17" i7 2,5 GHz Late_2011, à faire une récupération de données via l'«Assistant de Migration» après clean install sur une partition de disque : le débit, toujours variable avec l'«Assistant», fluctuait entre 67 Mo/s et 209 Mo/s --> soit de 33 à 100 fois plus vite que chez toi).
Je t'avais alerté précédemment à propos de ton HDD de 3 To impliqué en second dans le Fusion Drive : je pronostique que soit le disque > soit sa nappe SATA > présentent une défaillance. Je pense que c'est la case SAV qui s'impose...
