Prose dominicale (avec « culs de lampe »)
On va y arriver
Ta 2è capture montre qu'au démarrage s'affiche seulement l'écran gestionnaire de disque de «
rEFIt», non celui de «
rEFInd». Si, à partir de là je regarde quel chemin de
boot correspond au label
efi-boot-device en
NVRAM, voici ce est mentionné :
Bloc de code:
<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key>
<dict><key>UUID</key><string>F0A8554E-D6B9-4137-A2DB-D2ED1DF8FEB8</string>
</dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
[je me suis permis de casser la ligne continue d'adresse en 3 segments pour éviter le tapis roulant d'affichage horizontal] => l'
UUID de la partition de
boot :
F0A8554E-D6B9-4137-A2DB-D2ED1DF8FEB8 est forcément l'identifiant universel de celle de ton OS, puisque le nom de
device associé dans la chaîne qui suit est
disk0s2 : secteur
2 du disque
0, par défaut la partition où est installé
OS X. Nulle part n'est mentionnée une
UUID de l'
ESP (
EFI System Partition) correspondant au
device disk0s1 : secteur
1 du disque
0, ni un
PATH au
boot_loader de «
rEFInd» qui y réside, qui serait :
Bloc de code:
<key>Path</key><string>\EFI\refind\refind_x64.efi</string></dict></array>%00
=> on en conclut donc que l'
EFI n'active pas «
rEFInd», mais «
rEFIt».
♤
Le type de chemin de
boot que tu as en
NVRAM ressemble à s'y méprendre au chemin de
boot qui constitue le
default lorsque le volume
OS X est choisi comme disque de démarrage automatique : mention de l'
UUID de la partition
disk0s2 comme valeur pour l'
efi-boot-device.
Or, avec une telle adresse de
boot en
NVRAM, l'
EFI n'exécute pas néanmoins le
boot_loader régulier d'
OS X (at:
/System/Library/CoreServices/boot.efi), mais le
boot_loader de «
rEFIt» (at:
/efi/refit/refit.efi - restitué d'après les commandes d'installation de ton message
#3). Pourquoi ?
Parce que tu as passé une commande de "
blessing" (de type :
sudo bless --folder) qui "bénit" non pas le dossier des
CoreServices de la
Bibliothèque-Système qui recèle le
boot_loader : boot.efi d'
OS X ; mais "bénit" le dossier
refit du répertoire
efi situé à la racine de l'OS qui recèle le
boot_loader : refit.efi de «
rEFIt». Une commande de "
blessing" n'affecte nullement la
NVRAM, en effet, mais le "
header" (en-tête) du système de fichiers du volume désigné comme cible. C'est donc sur le "
header" du système de fichiers de la partition
/dev/disk0s2 de l'OS que se trouve fixé (par la commande
sudo bless folder) le
PATH au dossier recelant le
boot_loader exécutable par l'
EFI : le
/efi/refit/refit.efi.
Voici donc comment se reconstruit la séquence de
boot : l'
EFI lit en
NVRAM l'adresse de
boot mentionné au label :
efi-boot-device =
UUID de la partition
disk0s2 de l'OS => l'
EFI va donc au
device mentionné (la partition de l'OS) et tombe, sur le "
header" du système de fichiers contenu dans cette partition, sur le
PATH instauré par la commande de "
blessing" :
/efi/refit/refit.efi => l'
EFI suit donc ce chemin balisé et exécute le
boot_loader : refit.efi de «
rEFIt». Chemin logique déterministe, unilatéral, sans bifurcation ni ambiguïté, construit en 2 segments : le segment
NVRAM = adresse au
device par l'
UUID de la partition
disk0s2 => le segment
filesystem = adresse au
boot_loader par le
PATH fixé sur le "
header" :
/efi/refit/refit.efi.
♧
Passe-moi la longueur de ces analyses dominicales, mais les problèmes logiques me passionnent jusque dans le plus petit détail.
Je conçois mieux, dans le contexte déterministe de
boot que je viens de reconstruire, le problème graphique que tu rencontres : le démarrage se fait exclusivement sur «
rEFIt» (comme démontré ci-dessus), et pourtant l'écran "gestionnaire de disque" de «
rEFIt» se trouve perturbé par «
rEFInd» alors même que ce "gestionnaire de disque" alternatif n'est pas « activé » ! Comment cela se peut-il ?
C'est que «
rEFInd» n'est pas
activé (au sens où aucune adresse à son
boot_loader sur la partition
/dev/disk0s1 de l'
ESP ne figure en
NVRAM au label :
efi-boot-device), mais néanmoins «
rEFInd» est
installé (au sens où l'exécution antérieure du
script shell : install.sh a créé sur la partition
/dev/disk0s1 de l'
ESP ses 2 dossiers de
boot potentiels :
refind &
tools, le 1er dossier recelant le
boot_loader refind_x64.efi). Par ailleurs, pour peu que sur les conseils de
Roderick Smith, le développeur de «
rEFInd», tu aies créé à la racine de ton OS un répertoire (alternatif de celui de «
rEFIt») intitulé
EFI, avec un sous-dossier
refind recelant les ressources téléchargées de «
rEFInd», alors tu y a là le
boot_loader original :
refind_x64.efi également.
Il y a tout lieu de penser que, lorsque le
boot_loader refit.efi de «
rEFIt» se trouve exécuté par l'
EFI au démarrage, un processus de scan des volumes démarrables est lancé et que se trouvent identifiés par «
rEFIt» comme volumes démarrables (et par suite affichés) tous ceux qui supportent un
boot_loader, càd. un fichier terminé par l'extension
.efi => ce qui donnerait une reconnaissance de l'
ESP (
/dev/disk0s1) comme volume démarrable (car recelant le
refind_x64.efi at:
EFI/EFI/refind/refind_x64.efi) ; une reconnaissance de
Macintosh HD (
/dev/disk0s2) comme volume démarrable (car recelant encore le
refind_x64.efi at:
/EFI/refind/refind_x64.efi) ; et une reconnaissance redondante de
Macintosh HD (
/dev/disk0s2 itou) comme volume démarrable (car recelant le
boot.efi règlementaire at:
/System/Library/CoreServices/boot.efi).
=> je conçois mieux ton problème pratique :
abondance de biens nuit ! --> la présence de dossiers de ressources de «
rEFInd» (sur l'
ESP comme à la racine de l'OS) perturbe «
rEFIt» lors du scan des volumes démarrables
(pauvre petit ) et le conduit à afficher autant de volumes démarrables que de
boot_loaders .efi trouvés.
♡
Si donc tu ne veux garder que «
rEFIt» sans redondance causée par les dossiers de ressources de «
rEFInd» recelant chacun un
boot_loader refind_x64.efi, alors il faut que :
- a) tu supprimes
a la mano ces dossiers de ressources de «
rEFInd». Pour ce qui est de l'
ESP, tu n'as qu'à monter en volume cette partition par la commande :
Bloc de code:
diskutil mount /dev/disk0s1
qui va faire s'afficher sur ton Bureau de session l'icône d'un volume
EFI. Tu entres dans le répertoire de ce volume, tu entres dans le sous-répertoire éponyme
EFI qu'il contient (ne pas supprimer : dossier Apple natif), et là tu tombes sur 3 sous-dossiers :
APPLE (ne pas supprimer : dossier Apple natif) et
refind &
tools : ces 2 dossiers ont été créés par l'
install.sh de «
reFInd» => tu les mets à la corbeille et tu la vides en t'authentifiant (le dossier
refind recèle le
boot_loader activable
refind_x64.efi).
- b) que tu bennes le dossier de ressources de «
rEFInd» issu du téléchargement depuis le site «
SourceForge» et situé quelque part à la racine de ton OS --> cela fait, j'ose espérer qu'au redémarrage, l'écran "gestionnaire de disque" de «
reFIt» s'en trouvera apuré.
♢
Je trouve quand même dommage (et mon avis va dans le même sens que celui donné au tout début par
Jean 
) de préférer «
rEFIt» (qui n'est plus développé) à «
rEFInd» (toujours développé et plus raffiné). Le fait que «
rEFIt» n'installe pas de ressources de démarrage sur une partition indépendante (celle de l'
ESP :
/dev/disk0s1), mais sur le volume même de l'OS
/dev/disk0s2 (avec recours au
blessing) : ce me semble un procédé logique beaucoup plus susceptible d'interférences que celui de «
rEFInd».
Si tu voulais donc ne passer que par «
rEFInd», il faudrait que :
- a) tu bennes le dossier de ressources de «
rEFIt» (pour éviter que son
boot_loader refit.efi ne soit scanné par «
rEFInd» -
vérifier sur l'ESP /dev/disk0s1 s'il n'y aurait pas de dossiers de boot de «rEFIt» installés à l'exécution de son fichier shell : j'ai un doute résiduel sur ce point quand même...) ;
- b) que tu rectifies le
blessing du système de fichiers de l'OS en le restaurant au
default par la commande :
Bloc de code:
sudo bless --folder /Volumes/"nom_du_volume_d'osx"/System/Library/CoreServices
(en pratique : tu tapes
sudo bless --folder, tu sautes un espace et tu fais un glisser-déposer du dossier
CoreServices contenu dans :
Système/Bibliothèque) ;
- c) que tu ré-exécutes l'
install.sh de «
rEFInd» par une commande de type :
Bloc de code:
sudo /chemin_au_fichier/install.sh
(en pratique
sudo + un espace + glisser-déposer du fichier
install.sh dans la fenêtre du «
Terminal».
--> il n'y a pas de raison que ça ne marche pas (à part le
SIP si tu es sous «
El Capitan» => passer alors au préalable la commande
csrutil disable dans le «
Terminal» de la «
Recovery HD» afin de libérer la
NVRAM pour l'édition du
PATH au label :
efi-boot-device) : personnellement, j'utilise toujours «
rEFInd» sans problème d'une version d'
OS X à une autre (actuellement avec «
El Capitan»). De temps à autre, il faut seulement que je ré-exécute l'
install.sh si une manœuvre expérimentale de ma part a fait sauter le
PATH en
NVRAM à l'
efi-boot-device (pointant sur l'
ESP /dev/disk0s1 au
boot_loader refind_x64.efi de «
rEFInd»)...
❈
