Salut
Liyad.
En rapport avec ta question :
est-ce que toute la partie avant la pomme qui s'affiche fait partie de Mac OSX ou est-ce que c'est l'EFI ou autre chose ?
je te propose un peu de « théorie » - sans grandes conséquences « pratiques » malheureusement...
♤
L'affichage du logo signale le lancement du
boot_loader : boot.efi de l'OS : le fichier démarreur du Système logique du disque, localisé sur la partition
/dev/disk0s2 at:
/System/Library/CoreServices/boot.efi. Par rapport à cet affichage de la , il y a donc l'«
avant » et l'«
après ».
L'«
après » => c'est le «
boot » à proprement parler (le processus logique sur le disque ou démarrage d'
OS X) : le
boot_loader : boot.efi charge le cache de démarrage-Système
prelinkedkernel («
El Capitan») ou
kernelcache (OS antérieurs), ce qui revient à démarrer le
kernel (micro-noyau) dont le code fait partie du cache et à lui injecter le bloc des
kexts (extensions du noyau = pilotes du
hardware). Cela fait, le
kernel lance le processus
launchd qui met en route le Système logique de l'OS, jusqu'à affichage du
LoginWindow (écran d'ouverture de session) qui permet d'ouvrir une session graphique. Le démarrage du
kernel se signale par la barre de chargement sous le logo .
L'«
avant » => c'est le «
pré-boot » spécifiquement : il est entièrement du ressort de l'
EFI (micrologiciel recelé dans une puce de la Carte-Mère, qui constitue le
Firmware du Mac ou
Programme Interne). Ce
pré-boot peut se décrire ainsi :
- a) exécution préalable du POST (Power-On Self-Test) = vérification de la compatibilité réciproque des éléments du hardware, impliquant un test de présence du Super-Drive s'il y a lieu, mais sans qu'il s'agisse d'un scan de la fonctionnalité terme à terme de chacun de ces composants intrinsèquement (Carte-Graphique, RAM etc). Le POST, en cas de validation, se conclut par le retentissement du Chime (carillon ou gong) - il est donc possible que le POST retentisse avec une Carte-Graphique HS par exemple, car ce qui a été validé est sa compatibilité, non son ustensilité.
- b) chargement des paramètres de la NVRAM : l'EFI visite cette mémoire statique de la Carte-Mère, charge les flags qui y sont inscrits (genre : SIP sous «El Capitan») et lit l'identité d'une partition de disque démarrable ou efi_boot_device (si elle est inscrite, sous forme d'UUID) ;
- c) activation des ressources foncières du hardware : l'EFI déclenche l'activation du CPU (processeur), de la Carte-Graphique, de la RAM...
- d) exécution du boot.efi : l'EFI va au système de fichiers recelé dans l'efi_boot_device (ou partition de disque) et, si ce système de fichiers est "béni" (blessed), alors le header (en-tête) de ce système de fichiers porte le chemin à suivre dans l'arborescence de l'OS pour atteindre le boot_loader : boot_efi à exécuter. Une fois exécuté le boot_loader boot.efi, l'EFI quitte en lui passant la main. Si le header du système de fichiers recelé dans l'efi_boot_device n'est pas "béni" (rare, mais accidentellement possible), le programme auxiliaire DiskManager est lancé afin de scanner le système de fichiers en vue de déceler la présence d'un boot_loader boot.efi. Si aucun efi_boot_device n'était mentionné en NVRAM, là encore le DiskManager est lancé pour scanner directement les headers (en-têtes) des systèmes de fichiers résidant sur les partitions des disques attachés au Mac, afin de vérifier s'il y a trace d'un « blessing » (inscription du chemin au boot_loader boot.efi enfoui dans l'arborescence logique de l'OS) ; en cas d'absence de blessing, le DiskManager ne scanne que l'espace-racine des volumes, sans descendre plus bas dans leur arborescence. Le premier boot.efi repéré est exécuté.
♧
C'est la pression sur le bouton "
Power" qui lance l'
EFI. L'écran du Mac reste noir aussi longtemps que la séquence est celle du
pré-boot (opération de l'
EFI). Pourquoi chez toi environ 3' - ce qui est beaucoup plus long que la normale ? Retour aux phases de la séquence-
EFI :
- a) L'exécution du
POST est très rapide (une poignée de secondes) : tu peux mesurer sur ton Mac combien de temps s'écoule approximativement entre ta pression sur le bouton "
Power" et le retentissement du
Chime (qui sanctionne immédiatement la fin du
POST) : s'il ne s'agit que de quelques secondes, alors ton problème de délai au démarrage ne relève pas du
POST (ce qui ne veut pas dire, comme mentionné plus haut, que chaque composant de la Carte-Mère est fonctionnel, mais qu'il n'y a pas incompatibilité réciproque des compostants).
- b) Le chargement des paramètres de la
NVRAM est lui aussi très rapide en ce qui concerne les
flags inscrits (que l'
EFI passera au
boot_loader boot.efi, lequel les injectera dans le
kernel à son tour) : il n'y a pas de probabilités que ce soit le processus de chargement logique à cette étape qui cause un délai.
Reste alors les deux moments c) et d).
- c) S'il y a un problème d'« ustensilité » de composants du hardware activés directement par l'
EFI dans le
pré-boot, sans qu'il s'agisse d'une panne radicale, il n'est pas impossible a priori que ça puisse « ramer ». Je me souvient d'un fil déjà ancien dans lequel
r e m y , après avoir doublé la RAM de son Mac, signalait un allongement du temps du
pré-boot dépendant de l'
EFI. Ce qui avait donné lieu à l'énoncé humoristique d'un «
Paradoxe de r e m y » : «
Plus il y a de RAM, plus ça rame au démarrage... ». Comme si l'activation de la RAM impliquait un... temps proportionnel à sa taille. Alors (et de manière purement conjecturale, de ma part) : pourquoi ne pas imaginer que l'activation du CPU, de la Carte-Graphique et autre RAM puisse, en cas de problèmes intrinsèques sans panne radicale, voir s'augmenter le délai requis ? Avec évidemment écran noir aussi longtemps que se poursuit le processus de l'
EFI...
- d) S'il y a un problème d'identification d'un
efi_boot_device (= secteur-disque de démarrage pour l'
EFI), ou s'il y a un problème de
blessing de l'en-tête du système de fichiers recelé dans cette partition : alors cette fois ce n'est plus un problème matériel qui est responsable du délai de mise en route ; mais un problème logique de lacune d'information. La présence d'un dispositif
CoreStorage sur la partition
/dev/disk0s2 de l'OS au lieu d'un système de fichiers au format
HFS+ standard, surtout s'il s'agit d'un
CoreStorage Chiffré (suite à l'activation de «
FileVault»), peut augmenter le délai d'exécution d'un
boot_loader : boot.efi par l'
EFI.
♡
Afin d'essayer de tirer de ces considérations « spéculatives » quelques effets « pratiques », une fois que tu as réussi à ouvrir ta session d'utilisateur, tu pourrais aller à :
Applications/Utilitaires et lancer le «
Terminal».
- 1° Passe d'abord la commande (purement informative et sans impact-Système) :
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> en retour, tu vas voir s'afficher le tableau de paramétrage actuel de ta
NVRAM, sous une forme qui paraît assez inscrutable a priori --> est-ce que tu peux sélectionner l'ensemble des lignes de ce tableau, par
⌘C les copier dans le presse-papier et par
⌘V les coller ici dans ton fil ? - Ce, afin qu'il soit possible de vérifier si un
efi_boot_device est bien mentionné en bonne et due forme, entre autres (et lequel) ?
- 2° Tu peux ensuite passer la commande (informative encore) :
et ↩︎ --> le secteur-disque de
boot va s'afficher (s'il y a lieu) : peux-tu le copier-coller ici ? Et tu peux encore passer la commande (toujours informative) :
et ↩︎ --> les désignations du dossier et du fichier de
boot sur l'
efi_boot_device vont être retournées en cas de
blessing régulier --> idem : copier-coller ici => tout cela, pour vérifier si tout est conforme au standard dans ces paramètres ou s'il y aurait des anomalies logiques...
- 3° Tu pourrais finalement passer la commande classique (informative) :
et ↩︎ et copier-coller le tableau retourné de partitionnement de ton SSD interne (
/dev/disk0) : histoire de voir ce qu'il en est. Et pour finir :
et ↩︎ --> si tu as un
CoreStorage sur la partition
/dev/disk0s2 de ton SSD, tu vas voir s'afficher le tableau complexe d'un
Logical Volume Group --> si c'est le cas, idem : copier-coller de l'ensemble du Tableau afin de voir ce qu'il en est. Sinon, tu toucheras un :
No Logical Volume Groups found...
- 4° Je serais (marginalement) curieux de vérifier les conséquences d'une commande (informative) :
et ↩︎ --> histoire de vérifier le statut de l'hibernatemode sur ton Mac...
♢