Si j'en crois ton pseudonyme,
vicarius, recourir à une '
fonction vicariante' n'a rien qui te dérange, en principe
(par quoi j'entends, en cas de déficience d'un logiciel, recourir à un autre capable de rendre le même type de service) 
Je te conseille de télécharger et d'installer les ressources binaires du logiciel de
Roderick Smith ☞
rEFInd☜ (clique sur le lien en bleu : normalement le téléchargement devrait s'enclencher aussitôt) --> un dossier intitulé :
refind-bin-0.8.2.4 atterrit dans ton dossier des
Téléchargements ou sur ton
Bureau selon la préférence de destination des objets téléchargés que tu as instruite dans ton navigateur internet.
Je te conseille de sauvegarder ce dossier des binaires de «
rEFInd» auquel tu pourras éventuellement être amené à avoir recours derechef (pour la raison suivante, d'après mon expérience : il arrive qu'on doive ré-installer «
rEFInd», soit après une désinstallation volontaire du logiciel, soit après une désactivation accidentelle - ce qui implique de pouvoir ré-exécuter le script
shell d'installation et donc de l'avoir sous la main commodément, ainsi que les ressources binaires qu'il requiert pour cette installation). Tu peux loger le dossier où tu veux, pourvu qu'il soit évident de le trouver quand tu en as besoin. Personnellement, je l'ai logé à la racine de l'OS (à côté des répertoires-systèmes :
Bibliothèque,
Système etc.) en m'authentifiant par mon mot-de-passe
admin à partir du seul argument de la
visibilité maximale d'un tel dossier de ressources de
boot : chaque fois que j'ouvre une fenêtre-
Finder, la présence du dossier
REFIND me saute aux yeux et me sert de '
reminder'
(comme disent les Américains qui, pour toutes les occurrences susceptibles de se produire dans l'expérience, ont un mot tout prêt qui l'emballe comme si l'événement se conformait toujours à une désignation verbale a priori disponible à l'avance. Ce qui fait qu'ils parlent toujours en mode déterministe, et jamais en mode ouvert comme le permet l'usage du Français, qui est une langue où la syntaxe prime le vocabulaire).
Une fois que tu as sauvegardé ton dossier, tu vas à :
Applications/Utilitaires et tu lances le «
Terminal». Dans sa fenêtre ouverte, tu commences par taper simplement :
et tu sautes
un espace avec la barre d'espacement du clavier. Cela fait, tu reviens au dossier de «
rEFInd» (où que tu l'aies sauvegardé), tu l'ouvres d'un double-clic, et tu avises le fichier :
install.sh parmi les ressources --> tu fais carrément un glisser-déposer au pointeur dans la fenêtre du «
Terminal», ce qui renseigne automatiquement le chemin au fichier et, en terminaison, le nom du fichier qui vaut pour la désignation de l'objet lui-même. Ce qui te donne au total quelque chose d'analogue à :
Bloc de code:
sudo /chemin_au_fichier/[COLOR="RoyalBlue"]install.sh[/COLOR]
et ↩︎ (presse la touche 'Entrée' du clavier pour activer la commande) --> une demande de
password s'affiche (commande
sudo = de niveau Super-Administrateur Système) --> tape ton mot-de-passe
admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> en réponse, tu as droit à l'affichage :
Bloc de code:
Installing rEFInd on OS X....
Installing rEFInd to the partition mounted at /Volumes/ESP
Copied rEFInd binary files
Copying sample configuration file as refind.conf; edit this file to configure
rEFInd.
WARNING: If you have an Advanced Format disk, *DO NOT* attempt to check the
bless status with 'bless --info', since this is known to cause disk corruption
on some systems!!
Installation has completed successfully.
Unmounting install dir
umount(/Volumes/ESP): Volume EFI on disk0s1 unmounted
Il te suffit de
re-démarrer pour que l'
intercepteur de boot : «
rEFInd» soit actif, et à chaque démarrage/re-démarrage, tu devrais automatiquement voir s'afficher un écran de choix de
boot graphique (permettant de sélectionner le disque de démarrage et l'option éventuelle de ce démarrage).
♤
Comme je suis relativement lancé ce matin dans des considérations oiseuses, autant laisser fuser une nouvelle gerbe
L'exécution de l'
install.sh de «
rEFInd» produit 2 actions connexes : une intervention sur la mémoire statique
NVRAM de la Carte-Mère où se trouve désormais instruit, en mode
hégémonique, un
argument de boot qui dirige automatiquement la trajectoire de l'
EFI (Programme Interne ou
Firmware du Mac) sur une cible unique, qui est l'
intercepteur de boot : «
rEFInd».
Cet
intercepteur de boot s'installe dans la partition dite
ESP (EFI System Partition), par défaut la 1ère des partitions logiques du
Tableau de Partition GUID du disque de l'OS (
/dev/disk0s1), dont le Volume, non monté par défaut, est intitulé
EFI au montage occasionnel.
En mode
standard, l'
ESP est vide en ressources
actuelles et ne sert que comme volume de transit
temporaire des
MÀJ de l'EFI_Firmware lorsque la mise-à-jour d'une version d'
OSX en est clandestinement porteuse, et c'est à partir de cette 'base de cantonnement temporaire' qu'elles sont écrites en programme interne au re-démarrage, avant suppression de leur présence dans l'
ESP. Le disque d'un OS peut très bien fonctionner intrinsèquement en cas de suppression de cette partition-
EFI, mais il est impossible en l'absence d'un volume
ESP qu'aucune
MÀJ du Firmware puisse s'exécuter. Ce serait donc une lourde erreur de supprimer cette partition
ESP sous prétexte que c'est un ornement inutile.
En mode
spécial, l'
ESP est chargée des ressources de
boot actuelles de «
rEFInd». «
rEFInd» ne fonctionne comme
intercepteur de boot que parce qu'un
argument de boot hégémonique en
NVRAM conduit l'
EFI à monter en volume au démarrage l'
ESP où se trouvent les ressources de
boot de «
rEFInd» et à exécuter le lancement de son programme en lieu et place du montage du volume de l'OS et de l'exécution de son fichier
Boot_Loader : boot.efi. Voici une capture de ces ressources sur l'
ESP du disque de mon
MacBook Pro supportant «
Yosemite» :
Il s'agit donc d'un véritable aiguillage de la trajectoire de l'
EFI, qui modifie le
Volume cible monté au démarrage, de même que le fichier démarreur exécuté sur ce volume. Sur les Macs où «
rEFInd» est installé, quand bien même il n'y aurait qu'
un OS démarrable à l'arrivée, c'est «
rEFInd» qui accapare absolument l'initiative et auquel l'
EFI passe la main. Et c'est «
rEFInd», selon le choix graphique de l'utilisateur, qui va exécuter après coup le fichier
Boot_Loader de l'OS choisi comme Système à démarrer. Quand il s'agit d'
OSX, le
Boot_Loader : boot.efi qui va charger le
kernel, lequel va charger les
kexts.
♧
Comme je suis en veine de d'argumentation rhétorique, je voudrais profiter de cette opportunité (le
kairos affectionné des
Grecs) pour souligner un point absolument crucial pour tous les utilisateurs qui sont dans le cas de figure : «
SSD de Tierce-Partie» x «
OS Yosemite» x «
Trim Enabler activé». J'aimerais la placer sous le patronage d'un qui a régulièrement l'amabilité de
souffrir la 'forme longue' de mes proses alors même que sa préférence personnelle va à la 'forme brève' : j'ai nommé
bompi qui, dans ce fil hanté par des anxieux de tout acabit
[TRIM] Yosemite et son bridage déclare (message
#166) :
C'est à se demander si le plus simple ne serait pas d'installer rEFInd, après tout. Je n'ai jamais eu le moindre problème, il peut très bien être là sans qu'on le remarque (sauf à démarrer avec Alt enfoncée) et il semble parer au problème.
Mon expérience corrobore entièrement cette appréciation : l'existence de «
rEFInd» installé en
intercepteur de boot de l'
EFI au démarrage
annule les risques de plantage liés à l'activation de Trim Enabler,
si et seulement si le démarrage est laissé à l'
intiative de «rEFInd».
Je pense, d'après mon petit exposé précédent, que la
raison de cet effet expérimental ressort : lorsque «
rEFInd» est installé, c'est l'
argument de boot instauré en
NVRAM par «
rEFInd» qui possède l'
hégémonie sur le
kext_signing de «
Yosemite» qui se trouve
overriden. De même, je le présume, sur l'
argument de boot :
boot-args-kext-dev-mode=1 instruit par «
Trim Enabler» en substitution du
kext_signing. Le résultat est que l'
EFI ne passe aucun
argument de boot en direct au
Boot_Loader : boot.efi qui donc ne peut pas le refiler au
kernel au chargement ; car l'
EFI ne prend en charge que l'instruction
hégémonique d'avoir à monter le Volume
ESP de la partition
/dev/disk0s1 et à exécuter comme fichier-chargeur exclusivement celui de «
rEFInd», sans qu'il soit jamais question de pouvoir lui refiler une instruction directrice
déterminante, puisque précisément «
rEFInd» est une instance de
démarrage optionnel.
Le fait que «
rEFInd» prenne la main en
intercepteur de boot équivaut donc à la résiliation du
kext_signing a priori qui se trouve par là
neutralisé. À partir du tableau de bord graphique de «
rEFInd», choisir même un
démarrage sans extensions n'expose plus au plantage, puisque ce processus s'exécute
à partir d'une instance de boot exempte du kext_signing (CQFD).
Par contre, comme souligné par
bompi, tout démarrage à partir de la touche 'alt' courcircuite «
rEFInd» et ré-expose à un
boot privé de son
égide ; de même, un démarrage direct avec la touche ⇧ pressée (démarrage sans extensions d'entrée) : là, le plantage est assuré en cas de configuration : «
SSD de Tierce-Partie» x «
OS Yosemite» x «
Trim Enabler activé», car le
kernelcache va être supprimé et le
kernel solitaire, dans sa fonction de charger individuellement les
kexts, va récupérer l'argument du
kext-signing. Il en irait de même, bien évidemment, pour une commande de
reset_NVRAM d'entrée (⌘⌥PR), car il y aurait suppression de l'
argument de boot hégémonique de «
rEFInd» (aussi bien d'ailleurs que de celui du
boot-args-kext-dev-mode=1 de «
Trim Enabler»), et prévaudrait alors le
kext_signing que l'
EFI passerait directement au
kernel via le
boot.efi.
Avant de prendre congé, je voudrais souligner que, par un effet particulièrement pervers, «
Yosemite» s'installe fréquemment en virant le partition d'accueil de l'OS :
/dev/disk0s2 au format :
Groupes de Volumes Logiques : CoreStorage, soit en mode non chiffré, soit en mode chiffré (si la proposition d'activer «
FileVault» est acceptée par l'utilisateur - qui aurait mieux fait d'aller se pendre
). Or l'existence du format :
Groupes de Volumes Logiques : CoreStorage sur la partition de l'OS :
/dev/disk0s2 interdit à «
rEFInd» de jouer le moindre rôle au démarrage.
C'est une alternative : si je veux que «
rEFInd» fonctionne, le format
Groupes de Volumes Logiques : CoreStorage ne doit pas exister sur la partition de l'OS ; s'il existe, «
rEFInd», même installé sur le volume
ESP (
/dev/disk0s1), se trouve neutralisé comme
intercepteur de boot et donc ne peut plus jouer son rôle d'
égide au démarrage.
Il semble bien que, si
Roderick Smith s'est aperçu de ce dernier problème, il ne se soit absolument pas avisé du rôle de neutralisation de l'instruction du
kext_signing joué par son logiciel (le seul Mac à sa disposition étant de son propre aveu une antiquité cantonnée à «
Snow Léopard»
).
<NB. Il semble que sur des disques d'une taille supérieure à 500 Go - ce qui est aujourd'hui fréquent - il y ait risque de flingage du disque, «rEFInd» installé sur l'ESP, si jamais l'utilisateur, dans le «Terminal», invoquait le binaire : bless avec l'option : --info --> pour une raison qui m'échappe, il semble que cette commande ait des effets dévastateurs et qu'elle doive donc être proscrite.>
♡
