Les 3
Boot Mac OS désignent donc les 3 volumes à fonction «
booter » de pré-démarrage du
Volume Logique CoreStorage --> les 2
Boot mac OS from BOOT OS X probabablement les volumes
Boot OS X montés sur les partitions
disk0s3 &
disk1s6 > et le
Boot mac OS le volume
Recovery HD monté sur la partition
disk1s3 sous un autre
label que celui du volume de secours. Les 3 doivent être choisissables pour pré-démarrer
Macintosh HD (càd. pour exporter le
Volume Logique qui lui tient lieu de disque virtuel).
Le
Boot Windows (Legacy) from BOOTCAMP désigne bien le volume
BOOTCAMP en tant qu'un
boot_loader Legacy (exécutable par un programme de boot de type
BIOS = le fichier
bootmgr) est présent dans l'espace-racine du volume. C'est la même détection du volume que faisait «
rEFInd» antérieurement --> sauf que cette fois-ci la restauration d'une
Hybrid_MBR sur le bloc
0 du HDD (par l'utilitaire
gdisk créé par le même
Roderick Smith qui a créé «
rEFInd» - voilà où se glisse la plaisanterie dans la logique) -
Hybrid_MBR décrivant en
MBR Part 2 la partition
BOOTCAMP comme bootable --> permet au
BIOS émulé par l'
EFI d'accéder au volume et d'exécuter le programme de démarrage
bootmgr.
Le
Boot Windows OS from FAT volume est une désignation bizarre (pourquoi "
FAT volume" étant donné que le format du système de fichiers de la partition
BOOTCAMP est
NTFS ?) --> cela correspond-il à la détection du volume
BOOTCAMP que ferait «
rEFInd» via la table
GPT des blocs
1-32 du HDD > suite à ma tentative farfelue de "bénir" l'en-tête du volume
BOOTCAMP par analogie au
blessing d'un volume
macOS ? - douteux > car le
blessing en question pointait droit à un
boot_loader UEFI =
bootmgr.efi --> dans ces conditions > «
rEFInd» devrait annoncer le volume comme un
EFI Boot = un appareil bootable par l'
EFI.
Car un gestionnaire de démarrage - que ce soit le
boot_manager natif (= programme auxilaire de l'
EFI) ou le
boot_manager de tierce partie «
rEFInd» - ne détecte un volume comme démarrable que s'il révèle au scan un
boot_loader (un programme de démarrage-Système d'un OS). Un
boot_loader n'est détectable dans un volume que : s'il existe dans l'
espace-racine du volume (c'est le cas pour le
bootmgr du volume
BOOTCAMP) càd. au premier degré d'un répertoire de volume > ou si un
chemin de démarrage est inscrit sur l'en-tête du volume > que le
boot_manager peut suivre pour aviser un
boot_loader enfoui au énième degré dans une arborescence de dossier (c'est le cas pour le
boot.efi de
macOS at:
\System\Library\ CoreServices\boot.efi d'un volume
Macintosh HD standard > ou dans un sous-dossier du «
booter » d'un volume
Boot OS X ou
Recovery HD).
Tous les volumes sans exclusion se trouve
montés sur toutes les partitions de disque dans le «
temps du boot » (très différent du « temps de la session » d'utilisateur). Ils sont montés par l'
EFI qui utilise donc les
tables de partition de l'en-tête des disques pour l'adressage des systèmes de fichiers (générateurs des volumes) inscrits sur les partitions. Or pour ton HDD >
2 tables d'adressage lisibles par l'
EFI existent : la
GPT des blocs
1-32 & la
HMBR du seul bloc
0. Le gestionnaire de démarrage de l'
EFI peut donc scanner le volume
BOOTCAMP via la
HMBR et l'afficher démarrable.
# Je n'ai jamais tiré au clair les limites exactes du gestionnaire «rEFInd» : est-il un simple intermédiaire ("go-between") de l'EFI dont il se borne à aiguiller la puissance exécutive sur tel ou tel volume démarrable ? - ou bien est-il un intercepteur de l'EFI par son boot_loader = refind_x64.efi > de telle sorte qu'il s'approprierait la puissance exécutive de l'EFI (dont le programme quitterait après son exécution) pour booter par sa propre puissance exécutive le volume choisi en démarrage ? - si c'est la cas --> alors nécessairement le boot_loader de «rEFInd» doit être capable d'« émuler un BIOS » à la place de l'émulation par l'EFI > pour booter en mode Legacy le boot_loader bootmgr de BOOTCAMP.
# Je me souviens qu'à l'époque de «Yosemite 10.10» > où a été inauguré le premier protocole de sécurisation kext_signing dont l'EFI chargeait les instructions en NVRAM --> «rEFInd» était capable d'intercepter l'EFI et de booter OS X sans instruction de kext_signing. C'est cet exploit logique qui m'a laissé conjecturer qu'il n'est pas un simple médiateur (un aiguilleur) de l'EFI - programme qui resterait en stand-by le temps que «rEFInd» affiche son écran de choix > avant d'exécuter le boot_loader du volume choisi comme si «rEFInd» n'avait jamais existé. Parce qu'un vrai boot_loader (comme le boot.efi de macOS par exemple) est une application exécutive de l'EFI dont le processus > une fois lancé dans la RAM > ne dépend absolument plus de l'EFI dont le programme initiataire quitte. Or le refind_x64.efi me paraît un véritable boot_loader et pas simplement un « booter » ou pré-démarreur. Si tel est bien le cas > le refind_x64.efi s'approprie la puissance exécutive de l'EFI dont le programme quitte. Ce qui implique que le refind_x64.efi de «rEFInd» est capable de neutraliser les flags de l'EFI (comme le SIP) sans les transmettre automatiquement au kernel chargé dans le volume-cible. Cette capacité du refind_x64.efi est-elle un default (comme ça m'avait paru l'être à l'époque de «Yosemite») ou bien est-ce une option activable en ligne de commande (car il est possible d'implémenter le boot_loader de «rEFInd» d'instructions) ?
# - mon absence totale de formation informatique (suppléée grosso modo par des "émulations spéculatives") me coince aux entournures dans la résolution de pareils points de détails où j'imagine qu'un informaticien "calé" (disons) aurait vite fait de discriminer ce qu'il en est.
=> tu n'as qu'à tester le boot par le biais du
Boot Windows OS from FAT volume - mais je subodore que c'est une impasse (enfin : sait-on jamais ?).
[J'en profite pour te signaler que si tu sélectionnes un des 3
booters de
macOS > puis presses la touche
F2 du clavier --> le gestionnaire «
rEFInd» te donne le choix de tous les modes possibles de boot du volume
Macintosh HD terminal :
verbose >
single user >
safe mode etc. Le "timer" de «
rEFInd» - le décompteur de délai avant boot automatique sur le volume que la mémoire de «
rEFInd» pré-sélectionne - est réglé par défaut sur un temps court --> il est possible de rallonger ce délai en éditant un fichier de
config présent dans le dossier
refind du volume
EFI de résidence du
refind_x64.efi.]
étant enfant devait être un fin limier lorsqu'il partait à la chasse au trésor!
