flotow &
Locke
C'est du genre : "Casse-tête chinois".
Choisir un volume dans le panneau du
Startup-disk Manager (
Disque de démarrage) --> revient à inscrire en
NVRAM, à la variable
efi-boot-device, un chemin de démarrage automatique pour l'
EFI sur le volume-cible. Après > c'est le chemin de boot inscrit sur l'en-tête du volume-cible > qui fait que l'
EFI va pouvoir accéder à un
boot_loader pour l'exécuter.
La complication surgit, avec
Windows-7, du fait que cet OS se démarre en mode "
Legacy" (à l'ancienne) > et pas en mode "
UEFI" (à la moderne). Ce qui signifie : le
boot_loader de
W-7 est un fichier
bootmgr qui n'est pas exécutable par un programme interne de type "
EFI" (comme celui, natif, du Mac) > mais par un programme interne de type "
BIOS" (comme celui des anciens PC). Un
BIOS a besoin d'accéder au disque supportant le volume-cible par une table de partition de type
MBR > lui décrivant la partition de boot par un descripteur "ancien mode
Windows". Il faut de surcroît dans la table
MBR que le "
bootable_flag" (le fanion : "je suis démarrable !") > soit apposé en regard de la partition-cible.
Les ingénieurs de la avaient donc implémenté des fonctionnalités complexes : tout disque Mac est toujours porteur de
2 tables de partitions sur l'
en-tête (secteur d'amorçage : blocs
0 à
32) et pas d'une seule : la
GPT principale et une
MBR alternative. La
MBR alternative, inscrite sur le seul bloc
0, est par défaut une
PMBR (
Protective_MBR) ne décrivant aucune partition spécifique sur le disque > mais emballant l'ensemble de l'espace du disque dans une "super-partition" dotée du
hex code :
0xEE --> càd. partition de type
EFI GPT. Autant dire inutilisable. Mais, dès qu'une partition se trouve créée dans un format
Windows (comme le
FAT-32 ou le
NTFS) --> alors la
PMBR du bloc
0 se trouve
automatiquement convertie (
*) à une
HMBR (
Hybrid_MBR : table
MBR fonctionnelle > empruntant la description de
3 partitions
au plus à la table
GPT principale --> donc une
MBR "hybridée" de la définition
GPT des partitions).
- (*) ce mécanisme de conversion automatique de la PMBR du bloc 0 à une HMBR dès la création de toute partition dans un format Windows sur le disque --> a été abandonné à partir de l'OS Sierra 10.12. Parce que le nouveau W-10 bootant en mode "UEFI" (EFI --> GPT --> boot_loader bootmgr.efi) a rendu obsolète cette problématique d'un boot "Legacy" de Windows.
À la détection d'une
HMBR sur un en-tête de disque > le programme interne
EFI a été implémentée d'une capacité à «
émuler un
BIOS » --> on obtient alors le mécanisme logique :
EFI -->
BIOS_émulé -->
HMBR -->
boot_loader bootmgr.
Quand on démarre la touche "
alt" pressée > on déclenche le programme interne
EFI avec une "option de suspension" : un sous-programme appelé le
Boot_Manager va scanner tous les volumes montés dans le temps du boot > afin de détecter et d'afficher ceux qui ont un caractère
démarrable par l'
EFI. Ce qui fait que l'
EFI > au lieu de lire l'entrée de la variable
efi-boot-device (appareil de démarrage automatique de l'
EFI) en
NVRAM > se retrouve en "stand-by" > tandis que son
Boot_Manager affiche à l'écran le sous-ensemble des volumes démarrables. Le choix fait par l'utilisateur de tel volume affiché > inscrit en
NVRAM à une variable
efi-next-only (appareil de démarrage "seulement pour cette fois") l'adresse au volume-cible > avec valeur de surclassement de la variable
efi-boot-device (appareil de démarrage "régulier" de l'
EFI).
Bref : le choix du volume
Windows à l'écran du
Boot_Manager écrit une adresse à une variable
efi-next-only en
NVRAM > là où le choix de ce même volume à l'écran du
StartupDisk Manager écrit une adresse à la variable
efi-boot-device en
NVRAM.
A priori --> on attendrait que les 2 adresses soit équivalentes > ce qui fait que l'
EFI > « s'apercevant » que le volume-cible lui est désigné via un descripteur
MBR de l'en-tête du disque --> hop ! émule un
BIOS à la volée pour adresser ledit volume et pouvoir exécuter le
boot_loader "
Legacy" :
bootmgr. La question est donc : à quel moment une
variation s'introduit-elle dans le schéma directeur qui fait que -->
- si un choix via le StartupDisk Manager a inscrit à la variable efi-boot-device de la NVRAM l'adresse au volume Windows --> alors le boot se fait en mode "Legacy" (EFI --> BIOS_émulé --> descripteur HMBR > boot_loader bootmgr)
- si un choix via le Boot_Manager a inscrit à la variable efi-next-only de la NVRAM l'adresse au volume Windows --> alors le boot en mode "Legacy" avorte. Le "no bootable device" évoquant un programme interne EFI adressant en tant qu'EFI et pas BIOS_émulé le disque de résidence du volume Windows.
Il faut donc mener une enquête pour -->
- vérfier s'il y a bien une HMBR sur le bloc 0 du disque > signe que le boot de W-7 s'opère bien en mode Legacy (par un BIOS_émulé)
- examiner l'inscription valide à la variable efi-boot-device après un choix de Windows dans le panneau du StartupDisk Manager - le problème étant que l'entrée efi-next-only en cas de choix à l'écran du Boot_Manager reste inscrutable > puisque cette variable est effacée de la NVRAM après usage
Si le
SIP d'
El Capitan ne proscrivait pas encore la lecture du secteur d'amorçage du disque de démarrage -->
après avoir fait le choix du volume de boot Windows dans le panneau du
StartupDisk Manager --> passer les 2 commandes :
Bloc de code:
sudo gpt show /dev/disk0
nvram -p
- la 1ère affiche la distribution des blocs du disque > dont l'identification du type de MBR du bloc 0
- la 2è affiche le tableau des variables de la NVRAM
Tu n'as qu'à,
flotow, poster les 2 retours dans une fenêtre de code > dont je te rappelle le procédé -->
- dans la page de ce fil de MacGé > presse le bouton ⌹ (carré avec un + inscrit - juste au milieu de la largeur de la fenêtre totale) dans la barre de menus au-dessus du champ de saisie d'un message > menu : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)
[Note: c'est le genre de problème où je pars battu d'avance > parce qu'à la simple lecture de sa description > je n'ai aucune "anticipation intuitive" d'une issue possible. Bref : je ne "vois" rien.]
