Le délai d'affichage du logo (qui indique l'activation par le
Programme Interne de la Carte-Mère = l'
EFI du "démarreur" de l'OS : le
boot_loader boot.efi) signifiait sans doute - comme mes comparses
Jean 
&
Locke te l'ont indiqué - qu'une préférence de démarrage automatique sur ce fichier démarreur n'était pas instruite dans la mémoire
NVRAM de la Carte-Mère que l'
EFI consulte dans la phase de
pré-boot (juste après le retentissement du carillon qui marque la fin du
POST :
Power-On Self-Test = vérification du
hardware du Mac). Sélectionner graphiquement le volume de l'OS à démarrer de préférence dans le panneau
Disque de démarrage des
Préférences Système revient à faire écrire en
NVRAM un argument de
boot automatique sur ce volume à destination de l'
EFI.
Lorsqu'aucun argument de
boot de ce type ne pré-existe dans la mémoire
NVRAM, alors intervient un programme auxiliaire de l'
EFI : le
diskmanager (gestionnaire de disque) qui scanne les volumes montés du ou des disque(s) attaché(s) au Mac à l'instant
t à la recherche d'un volume
démarrable, càd. exhibant la présence d'un fichier démarreur
boot.efi --> en cas d'une pluralité de volumes
démarrables trouvés (et dans les OS flanqués d'une partition de récupération «
Recovery HD», il y en a toujours au moins
2) - il faut encore qu'un arbitrage intervienne pour sélectionner celui dont l'
EFI va exécuter le fichier démarreur.
Comme tu vois, même dans une dimension informatique où tous les processus s'exécutent très rapidement, il peut y avoir dans ces conditions un délai temporel avant qu'une "cible" soit fournie à l'
EFI.
♘
Le fait par contre qu'un
écran d'identification d'utilisateur (
LoginWindow) s'affiche au
commencement de la séquence de démarrage, et pas à la
fin (comme c'est le cas de manière classique) signale très probablement que le volume de démarrage est
chiffré suite à l'activation de «
FileVault-2» --> lorsque le volume de démarrage en question est ainsi
chiffré, tout se complique dans la séquence de démarrage.
En effet, étant
chiffré, le volume de l'OS est a priori
verrouillé et par suite impossible à
monter automatiquement au démarrage par le programme
diskarbitration, parce que le
montage du volume est conditionné par son
déverrouillage, lequel ne peut intervenir que si la
clé de déchiffrement se trouve activée --> pour cela, il faut qu'un utilisateur habilité à ce faire le fasse via le renseignement de son
mot-de-passe accrédité. D'où la nécessité qu'intervienne en
début de séquence de démarrage un
écran d'identification d'utilisateur et pas en
fin - sinon, jamais le volume de l'OS ne pourrait être
monté après son
déverrouillage.
--------------------
Tu es en train de te dire :
yep! tout est clair à présent...
N'était cet avertissement de
Hamlet : «
Il y a plus de choses sur la Terre et dans le Ciel que n'en peut rêver ta philosophie - Horatio !» qui s'applique ô combien ! au terrain de l'informatique. En effet, un esprit scrutateur va apercevoir un "petit" problème relatif à la séquence de démarrage d'un Mac lorsque le volume de l'OS est
chiffré --> étant donné que le fichier démarreur de l'OS (le
boot_loader : boot.efi) est recelé à l'intérieur de l'arborescence du Système de fichiers en question (à l'adresse exacte :
/Volumes/Macintosh\ HD/System/Library/CoreServices/boot.efi), comment l'
EFI peut-elle exécuter ce démarreur en préalable de la séquence de
boot puisque relevant d'un volume
verrouillé, et donc
non-monté, ce fichier lui est de ce fait même inaccessible? Réponse : c'est
impossible.
C'est
impossible, et malgré tout il faut que cela soit
possible, si l'on veut que le lancement d'un "
démarreur" permette le déclenchement d'un
affichage graphique proposant un
écran d'authentification d'utilisateur - suite au renseignement du mot-de-passe duquel le volume de l'OS sera
déverrouillé et donc
monté, et le
kernel (le noyau opérateur) pourra prendre en main le chargement de l'OS. Apparemment, il y a ici
cercle vicieux logique - ce que les ingénieurs de la ont très bien aperçu dès la création de la possibilité d'un volume intégral de l'OS
chiffré par «
FileVault-2», càd. depuis «
Lion 10.7».
La solution qu'il ont trouvé est digne de ces ruses de l'
enfance, où, pour
déverrouiller la porte du placard aux confitures dont la
Mère_Grand conserve la clé en sautoir de corsage, son polisson de petit_fils s'est avisé que la clé du placard à balais
tenait_lieu parfaitement de passe... Eh! oui... Faute d'un
boot.efi inaccessible a priori dans le volume
verrouillé au départ de l'OS, ils ont imaginé dans ce cas de figure de le remplacer par celui... du Système démarrable auxiliaire de la «
Recovery HD» (
sic !) - puisque c'est le seul fichier démarreur
boot.efi adressable à l'ouverture --> on tient là la
raison suffisante pour laquelle Apple proclame que le
chiffrement du volume de l'OS est
inexécutable si une partition auxiliaire de récupération «
Recovery HD» n'existe pas sur le disque concerné. Parce que, si une telle partition n'existait pas, dont le volume monterait automatiquement au démarrage en offrant à
ciel ouvert un fichier
boot_loader : boot.efi exécutable, alors le Mac serait
nécessairement planté dès le départ et par suite
indémarrable logiquement.
C'est à ce démarreur auxiliaire de la «
Recovery HD» qu'il faut donc que soient passés des arguments de
boot lui enjoignant, dans le contexte d'un volume
chiffré de l'OS,
de ne pas démarrer le kernel de la «
Recovery HD», mais au contraire d'afficher un
LoginWindow permettant le déverrouillage du volume de l'OS, à la suite de quoi le
kernel de l'OS peut être chargé et la séquence de démarrage reprendre son cours normal...
--------------------
☞ Et après ça il y en a qui s'étonnent, qu'après avoir activé «
FileVault-2» les choses traînent en longueur... Elles sont forcées de traîner en longueur dès le commencement du démarrage, à cause du processus de
boot indirect incontournable (et je ne parle pas du fonctionnement de l'OS déployé, car le fait que chaque bloc de données d'écriture soit affecté d'un index de cryptage ne joue pas en faveur d'une augmentation de la vitesse d'accès en lecture non plus qu'en écriture)...
Mais ce que je trouve le plus
croquignolet dans toute cette affaire, c'est la proclamation d'un
gain de sécurité via le
chiffrement du volume de l'OS. Argument peut-être valable
a posteriori, mais que dire que cette condition
a priori de la possibilité du
chiffrement, qui est le démarrage sur un
démarreur auxiliaire relevant d'un autre volume que le volume à démarrer ? C'est l'histoire du gars qui aurait
verrouillé par sécurité le système de démarrage de sa voiture, si bien qu'il ne pourrait lancer le démarrage qu'à partir d'un démarreur auxiliaire lui permettant d'afficher un écran de
login...
Pour donner le
frisson final : supposons un volume de l'OS
chiffré par «
FileVault-2» et imaginons que, de sa session démarrée, l'utilisateur ne trouve rien de mieux à faire que de supprimer sa «
Recovery HD» (à tout le moins son dossier de
boot :
com.apple.recovery.boot ou ne serait-ce que le fichier
boot.efi qu'il recèle) --> que va-t-il se passer au re-démarrage?
