Salut
gibus [grand_gibus ou tit_gibus ? - voilà ce que je me demande
]
L'EFI est dans la ROM de démarrage. On a aussi une partition EFI sur chaque disque bootable. Et peut-etre aussi le trouve-t-on dans l'arborescence système ? Tous ces EFI sont-ils synchronisés et comment le vérifier (voir version d'un EFI disque par exemple) ?
Les changements de version peuvent mettre à jour l'EFI. Quid si je reviens en arrière ?
Dans mon cas par exemple (mini late 2012) j'ai pour EFI / SMC : MM61.0106.B0A / 2.8f0
L'EFI correspond d'après mes recherches à la 10.11.1 mais comme je suis revenu à Yosemite par copie clone et non réinstall j'ai un EFI conçu pour EL Capitan qui tourne avec Yosemite.
Est-ce genant (faut-il que je réinstalle) ?
L'
EFI (
Extensible Firmware Interface) est le
Firmware du Mac, encore appelé son
Programme Interne : micro-logiciel (ou programme) recelé dans une puce de la Carte-Mère et qui se trouve directement lancé (
launched) lorsqu'on presse le bouton d'alimentation du Mac. C'est donc le programme inaugural.
Ce programme exécute 2 tâches successives, la 2è n'étant exécutée qu'en cas de succès de la 1ère :
- 1° une tâche orientée
hardware : le
POST (
Power-On Self-Test). Elle consiste en un scan des composants matériels du Mac qui (d'après ce que j'en conçois) n'est pas "
discrète", mais "
holistique" : non pas vérifier, pour chaque composant physique isolément, s'il est opérationnel en soi (comment le faire, avant que le
kernel n'ait chargé les extensions du noyau qui les pilotent et donc en activent les fonctions ?) ; mais vérifier la cohérence réciproque de ces composants (leur "valeur de synergie" - si je puis dire). En cas de succès du test, l'
EFI fait retentir le "
Chime" ou carillon de démarrage et enclenche la tâche n°2.
- 2° une tâche orientée
software : le
PRE-BOOT. Elle consiste à enclencher le démarrage d'un Système Logique résidant sur la partition d'un disque attaché au Mac. Cet enclenchement implique 2 opérations :
- 2a) le chargement des arguments (flags) résidant dans la mémoire statique NVRAM de la Carte-Mère, toujours "visitée" par l'EFI après le POST. Ainsi, sous «El Capitan», à supposer le SIP (System Integrity Protection) activé, 6 kernel_flags se trouvent associés dans la NVRAM à la valeur 1 (= "TRUE") --> l'EFI va donc charger cet argument au passage. Idem, si se trouve mentionné un EFI_path qui est un chemin à un fichier booter résidant sur une partition-disque, chemin renseigné par l'UUID de la partition suivi de l'adresse logique au fichier en question --> l'EFI va charger cet argument comme adresse exécutive.
- 2b) l'exécution du booter. Le "booter" (abrégé pour "boot_loader" : amorceur de démarrage) est un fichier qui peut être considéré comme une "application primaire" de l'EFI. C'est régulièrement pour OS X le fichier : boot.efi localisé dans l'arborescence de l'OS at: /System/Library/CoreStorage (telle est l'adresse mentionnée en NVRAM en cas d'option de démarrage automatique activée) dont le rôle consiste à charger un cache de démarrage-Système composite combinant le code du kernel (micro-noyau) et le bloc des kexts (extensions du noyau ou pilotes des composants matériels du Mac) de telle façon que le kernel lancé, les kexts vont lui être "injectées en bloc" (passons sur les détails). Une fois que l'EFI a exécuté le booter : boot.efi, son programme coupe jusqu'au prochain re-démarrage (l'EFI n'est pas, comme le kernel, un programme qui opère en continu, mais uniquement séquentiel). Pareillement, une fois que le booter : boot.efi exécuté par l'EFI a chargé le cache de démarrage (classiquement : kernelcache jusqu'à «Yosemite 10.10 inclus ; récemment : prelinkedkernel avec l'OS «El Capitan»), ce programme coupe et n'est donc nullement un opérateur continu.
C'est lors de l'exécution du booter que l'EFI passe à ce programme les flags (arguments de boot) chargés lors de la visite de la NVRAM. Flags que le booter : boot.efi passe à son tour au kernel lors du chargement du cache de démarrage. C'est ainsi que le SIP se trouve pris en compte par le kernel : par la séquence EFI => flags en NVRAM => boot.efi => kernel.
Si donc on laisse de côté le
check-up du
hardware (
POST), on peut considérer que l'
EFI a un rôle logiciel de
PRE-BOOT (exécution du
booter avec passation de
flags de la
NVRAM), tandis que le
BOOT logique commence à proprement parler avec le
booter : boot.efi (dont l'activation est signalée à l'écran par le classique logo ).
--------------------
Les disques des Macs Intel supportent régulièrement une
Table de Partition GUID, telle que le secteur n°
1 de cette Table est toujours l'
ESP :
EFI System Partition (intitulée en abrégé :
EFI quand on fait un
diskutil list dans le «
Terminal»). Cette partition de 209 Mo ne doit pas être confondue avec l'
EFI vue précédemment : ce n'est pas l'
EFI, mais une "partition de l'
EFI", càd. un secteur logique de
boot pour le
Programme Interne du Mac. Bien que tous les disques tablés en
GUID comportent cette partition n°
1, elle ne joue aucun rôle dans les disques de
stockage de données, mais uniquement dans les disques
démarrables.
Cette partition
ESP n°
1 (si le disque est
disk0 =>
/dev/disk0s1) est toujours au format
MS-DOS (
FAT-32) et supporte par défaut des exécutables Apple : l'exécutable
BOOTLOG et, dans une arborescence collatérale :
EFI/APPLE/CACHES, EXTENSIONS, FIRMWARE d'autres exécutables. Avant l'exécution du
boot_loader : boot.efi résidant sur la partition en-dessous de l'
ESP (=
/dev/disk0s2), l'
EFI exécute automatiquement ces fichiers Apple en guise d'amorçage logique du disque. Si le format
MS-DOS de cette partition
ESP inaugurale d'une
Table de Partition GUID peut sembler déconcertant, c'est que l'
ESP est un secteur susceptible d'être utilisé par des applications de tierce partie qui y logeraient des exécutables. C'est le cas du
gestionnaire de boot : «
rEFInd», qui loge dans le dossier
EFI de l'
ESP 2 dossiers spécifiques :
refind &
tools, le dossier
refind recélant un
boot_loader alternatif : le
refind_x64.efi. En cas de mention en
NVRAM d'un
EFI_path (via l'
UUID de l'
ESP et son adresse) au
boot_loader alternatif
refind_x64.efi, c'est ce
booter que l'
EFI va exécuter au lieu du
boot.efi réglementaire et c'est ainsi que l'écran de
boot de «
rEFInd» se trouve intercalé. En cas d'exécution sur l'
ESP du
booter alternatif :
refind_x64.efi, l'
EFI coupe après son exécution, et c'est donc le
booter de «
rEFInd» qui exécute ensuite le
boot.efi réglementaire qu'on lui a désigné comme cible
(un point intéressant est le suivant : le booter de «rEFInd» est absolument "imperméable" aux flags de la NVRAM chargés par l'EFI, à la différence du booter : boot.efi => qui me comprend, en prenne acte...).
L'
ESP pourrait donc être considéré comme le
secteur d'amorçage logique, ou le
secteur gestionnaire de disque, pour l'
EFI : un intercalaire logique dans la séquence du
PRE-BOOT qui se décrirait alors plus complètement ainsi :
EFI =>
flags en
NVRAM =>
ESP =>
booter.
--------------------
Les versions successives d'
OS X embarquent très régulièrement des mises-à-jour du
Programme Interne du Mac (MÀJ de l'
EFI). Absolument irréversibles logiciellement par des moyens ordinaires (mais des "flashes de l'
EFI" sont exécutés par des bidouilleurs intrépides et les équipes techniques d'Apple possèdent les moyens de restaurer l'
EFI). Ce qui revient à dire qu'installer sur un Mac un OS très décalé temporellement de son OS d'usine impacte automatiquement l'
EFI (le
firmware de la Carte-Mère) comme tu l'as bien compris.
Cette évolution logique de l'
EFI de la Carte-Mère crée-t-elle une situation de non-retour en ce qui concerne la possibilité de
booter le Mac sur son OS d'usine, ou des OS intermédiaires entre ce dernier et le plus récent solidaire de la dernière MÀJ de l'
EFI ? La réponse foncière est : NON. Et la preuve en est donnée par la fonctionnalité inscrite dans l'
EFI des modèles de Macs non antérieurs à 2010, qui est le "démarrage par internet" permettant de télécharger et de ré-installer l'OS d'usine du Mac. Et forcément pour l'
EFI majorée d'exécuter son fichier démarreur
boot.efi. Cette fonctionnalité ne serait pas implémentée dans l'
EFI si elle correspondait à une perspective impossible : faire exécuter par une
EFI majorée un
booter : boot.efi rétrograde.
Cette réponse foncière est-elle susceptible d'exceptions sur les machines supportant l'OS le plus récent («
El Capitan») mais antérieures à la date critique (2010) permettant l'implémentation dans l'
EFI de la fonctionnalité capable de restaurer l'OS d'usine du Mac (forcément supporté) ? L'OS d'usine que permet de restaurer cette fonctionnalité ne pouvant être qu'un OS téléchargeable, le plus ancien ne peut alors être que «
Lion 10.7.0», auquel des Macs de 2010-2011 fournis à l'origine avec «
Snow Léopard» et DVD d'install se trouvent admissibles
expostfacto. Cela signifie-t-il que leur véritable OS d'usine : «
Snow Léopard» pourrait, en cas de trop grand écart entre une
EFI majorée depuis le dernier OS et le
booter de
10.6, devenir impossible à charger ? Je ne l'ai pas personnellement constaté, mais rien n'empêche de penser que cette impossibilité puisse se produire. Mon
MacBook Pro_ Early 2011, récemment mis-à-niveau à «
El Capitan», démarre toujours sur «
Snow Léopard 10.6.7/8». De même, un plus ancien :
MacBook Pro Mid_2010 démarre toujours tous les OS de «
Snow Léopard 10.6.3» à «
El Capitan» sans que l'
EFI majorée à la suite de l'installation d'«
El Capitan» rejette l'exécution du
boot_loader : boot.efi 10.6.3. Mais ils sont tous les 2 éligibles au "démarrage par internet".
En résumé : c'est uniquement un problème de compatibilité exécutive :
EFI x
boot.efi, avec implication éventuelle de l'
ESP intercalaire du disque support
[ai-je mentionné antérieurement qu'en cas d'installation de «rEFInd» comme gestionnaire de boot, c'est le booter refind_x64.efi de «rEFInd» qui prend le relai, pour exécuter le boot.efi de l'OS désigné ? booter refind_x64.efi dont le moins qu'on puisse dire est qu'il est est doté du même esprit d'« absence de discrimination » que son créateur Roderick Smith... Il est donc envisageable de faire exécuter par l'EFI le plus récent booter refind_x64.efi de «rEFInd» et de lui donner comme cible le boot.efi de l'OS d'usine.]
--------------------
)
