» que j'utilise au quotidien, tu apprécieras peut-être le partage de quelques informations (tant pis si certaines recoupent ce que tu sais déjà) :
- a) pour installer «
rEFInd», il suffit de télécharger le dernier dossier de ses binaires ici : ☞
refind-bin-0.12.2.zip☜ ; puis de saisir
sudo dans une fenêtre du «
Terminal», sauter un espace et glisser-déposer de l'exécutable
refind-install présent dans le dossier
refind-bin-0.10.2, puis validation avec frappe du mot-de-passe
admin à l'aveugle.
- b) en quoi consiste exactement cette installation ? En 2 choses :
- b1) une installation des binaires de «
rEFInd» sur l'
ESP (
EFI System Partition) qui est l'en-tête d'une
GPT (
GUID Partition Table) régulière =
/dev/disk0s1. Voici une capture figurant ces binaires de «
rEFInd» sur l'
ESP de mon SSD :
- b2) une inscription en
NVRAM, à la rubrique
efi-boot-device qui renseigne pour l'
EFI l'adresse du
boot_loader à exécuter automatiquement :
efi-boot-device <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>
B51A6E00-4320-4AFB-86FB-E71F18E6F7FB</string></dict></dict><key>IOEFIShortForm</key><true/><key>BLLastBSDName</key><string>disk0s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\refind\refind_x64.efi</string></dict></array>%00
=> en conséquence, l'
EFI en visitant la
NVRAM va enregistrer l'instruction de
boot automatique, aller à la partition
disk0s1 (=
ESP) ciblée par son
UUID universel, et suivre dans son volume «
EFI» le chemin de boot :
/EFI/refind/refind_x64.efi pour exécuter ce dernier
boot_loader.
- c) naguère, «
rEFInd» était incompatible avec un format
CoreStorage (non-chiffré ou chiffré) sur la partition de l'OS (
/dev/disk0s2) => dès qu'un
CoreStorage était en place, le gestionnaire de
boot de «
rEFInd» n'était plus utilisable. Mais
Roderick Smith remet toujours en chantier son logiciel. J'ai donc pu constater que, désormais, «
rEFInd» gère sans aucune difficulté l'existence d'un
CoreStorage non-chiffré (comme l'installateur d'«
El Capitan» se complaît à le greffer à l'installation sur la partition de l'OS), comme d'un
CoreStorage chiffré (issue de l'activation de «
FileVault»). Chapeau, Mr
Smith !
- d) l'inscription d'un chemin privilégié au
boot_loader refind_x64.efi de l'
ESP en
NVRAM conditionnant l'exécution automatique de ce démarreur par l'
EFI et donc l'affichage automatique de l'écran du gestionnaire «
rEFInd», il est évident que toute altération d'adresse en
NVRAM équivaut
ipso facto à une
désactivation de «
rEFInd» (non à sa
désintallation, puisque les binaires restent en place, intouchés, sur l'
ESP - mais désormais inadressables). Cette altération d'adresse intervient dès qu'on choisit un
disque de démarrage dans le panneau éponyme des
Préférences Système de l'OS (ou dans la tableau de bord de la «
Recovery HD». Mais aussi dès qu'on procède à une
installation-Système (mise-à-niveau, restauration), parce que l'installateur, afin de pouvoir re-démarrer sur le volume-Système, instruit en
NVRAM une adresse de boot automatique pour l'
EFI qui efface celle de «
rEFInd». Enfin, si on
efface la
NVRAM, ce qui efface l'adresse au
boot_loader de «
rEFInd» à la rubrique
efi-boot-device.
Il s'ensuit 2 conséquences : 1° ne pas hésiter à faire un
nvram -p dans le «
Terminal» pour scruter l'adresse mentionnée à l'
efi-boot-device => si l'on ne lit pas un
<key>Path</key><string>\EFI\refind\refind_x64.efi</string></dict></array>%00 à la fin, c'est que «
rEFInd» est désactivé et doit être réactivé ; 2° toujours garder le dossier des binaires
refind-bin-0.10.2 dans un endroit accessible de l'OS, de manière à pouvoir à volonté ré-exécuter son installateur
refind-install (en cas de binaires pré-installés, l'installateur sait les échapper pour se cantonner à restaurer l'adresse de
boot en
NVRAM).
