Arthur
Je te propose l'éclairage suivant -->
Lorsque > dans le panneau
Disque de démarrage des
Préférences Système > on sélectionne (supposons) le volume affiché
Macintosh HD > cette action graphique déclenche une opération logique en coulisses qui est la suivante : une entrée de la mémoire
NVRAM de la Carte-Mère se trouve éditée - entrée intitulée :
efi-boot-device = appareil de démarrage automatique de l'
EFI.
L'
EFI est le
Firmware du Mac : micro-logiciel recelé dans une puce de la Carte-Mère et activé par une pression sur le bouton
Power. Ce logiciel
EFI visite toujours la
NVRAM au démarrage > pour y lire les instructions qui y sont inscrites (par exemple les
flags du
SIP) > les charger > et opérer en conséquence. Lorsque l'entrée :
efi-boot-device se trouve définie > dans mon exemple par une adresse au volume
Macintosh HD => alors l'
EFI va automatiquement à ce volume du disque > pour exécuter le démarreur (
boot_loader) de l'OS en question. La particularité de l'entrée
efi-boot-device est qu'elle est
permanente > et donc subsiste à autant de re-démarrages qu'on voudra > aussi longtemps qu'une nouvelle sélection de volume de démarrage n'a pas été opérée dans le panneau
Disque de démarrage.
Supposons à présent qu'un utilisateur ait une partition
BOOTCAMP dans laquelle
Windows est installé en parallèle de la partition de l'OS
Macintosh HD. Le souhait de cet utilisateur est de pouvoir s'éviter de re-démarrer avec la touche "
alt" pour avoir le choix du volume
BOOTCAMP de
Windows > mais de pouvoir re-démarrer
directement sur
Windows à partir de sa session ouverte dans
macOS > sans pour autant que l'entrée
efi-boot-device de la
NVRAM n'ait été modifiée > mais continue d'instruire un démarrage automatique sur le volume
Macintosh HD. Ce souhait consiste donc à pouvoir opérer un "
bypass" purement ponctuel de l'instruction de la
NVRAM qui ne modifie pas la préférence régulière de boot sur
Macintosh HD. Ainsi > en re-démarrant normalement à partir de la session de
Windows > ce sera
macOS qui sera automatiquement démarré.
Pour satisfaire ce souhait > les ingénieurs de la ont défini ce que j'appellerais une "
préférence de boot volatile" > qui consiste en la possibilité d'inscrire en
NVRAM > en parallèle de l'entrée
efi-boot-device intouchée > une entrée intitulée :
efi-next-only (
démarrage de l'EFI exclusivement pour cette fois-ci). Cette entrée possède une double particularité -->
- elle possède une "prééminence" (over-riding) sur l'entrée efi-boot-device > de telle sorte que l'EFI > s'il existe une entrée efi-next-only en parallèle de l'entrée efi-boot-device > va uniquement suivre le chemin de l'efi-next-only en échappant le chemin de l'efi-boot-device ;
- elle possède une existence "volatile" > en ce sens qu'après avoir chargé l'instruction du chemin mentionné à l'efi-next-only > l'EFI va effacer cette entrée de la NVRAM > de telle sorte que seule demeurera l'instruction de boot automatique permanente = efi-boot-device qui pointe sur le volume Macintosh HD de macOS.
En résumé : pouvoir rebooter directement sur
Windows sans que cela n'affecte le principe de démarrage automatique sur
macOS > revient littéralement à pouvoir instruire en
NVRAM une entrée
efi-next-only pointant sur le volume
Windows > instruction qui sera effacée après chargement par l'
EFI > de manière à ce que subsiste seulement l'instruction régulière
efi-boot-device pointant sur
Macintosh HD => ainsi le re-démarrage automatique à partir de
Windows se fera uniquement sur
macOS.
Comme tu peux le voir si tu ne laisses pas la multitude des « arbres » (l'abondance de mes mots) te cacher la « Forêt » (l'idée directrice) --> le procédé est enfantin (et il en va ainsi de toute l'informatique de A à Z qui ne s'écarte jamais sur le fond des trucs dignes des cours de récréation de l'école primaire).
--------------------
Oui mais (demandes-tu) comment fait-on pour activer une telle instruction
efi-next-only en
NVRAM ? - c'est là que les ingénieurs de la se sont montrés déloyaux > en ce sens que cette instruction ne peut pas être opérée en mode
graphique (par exemple par une sous-option du panneau
Disque de démarrage des
Préférences Système) > mais uniquement par une commande spécialisée dans le «
Terminal» convoquant l'utilitaire
bless ("bénir") avec des options particulières. Je pense que le logiciel «
BOOTCHAMP» s'est voulu un correctif de cette lacune graphique dans
macOS > en permettant à l'utilisateur d'inscrire en
NVRAM une instruction de type
efi-next-only sur
Windows sans avoir à passer par le «
Terminal».
Oui mais (objectes-tu encore) - le problème c'est que «
BOOTCHAMP» ne marche plus dans «
Sierra»... Eh oui ! Car ? - car même la commande classique appelant l'utilitaire
bless avec les options permettant l'inscription d'une entrée
efi-next-only en
NVRAM ne fonctionne plus dans «
Sierra» (le logiciel «
BOOTCHAMP» se bornant à déclencher en coulisses cette commande du «
Terminal»).
Pourquoi ? - eh ! c'est à cause du
SIP (
System Integrity Protection) mis en place au démarrage à partir d'«
El Capitan». Dans la présentation du
SIP > ce qui a été mis en lumière > c'est le fait que ce protocole de sécurisation verrouille l'essentiel du
Système de l'OS une fois le démarrage effectué. Mais ce qui n'a pas été mis en relief suffisamment > c'est que ce protocole a un effet vicieux sur la
NVRAM --> en ce sens que des entrées déterminées de la
NVRAM se trouvent elles aussi
verrouillées contre toute action de la part de l'utilisateur (même en droits
root). Les entrées concernées ici sont aussi bien l'
efi-boot-device que l'
efi-next-only. Il est impossible, le
SIP activé, d'écrire ces entrées à partir du «
Terminal» de l'OS (et donc aussi bien il est impossible au logiciel «
BOOTCHAMP» d'écrire en
NVRAM une entrée
efi-next-only).
Oui mais pourquoi est-il possible d'éditer l'entrée
efi-boot-device depuis le panneau
Disque de démarrage des
Préférences Système ? - hé ! c'est là le point retors du
SIP --> il existe des
processus qui gardent le pouvoir d'«
outrepasser » (
override) le
SIP > dans la mesure où il correspondent à des
exécutables dotés de "
privilèges" (des attributs fixés qui confèrent à leurs processus exécutifs un "
passe-droit" à l'égard du
SIP. Il en va ainsi pour l'exécutable récent
trimforce qui permet d'activer le
TRIM sur des SSD de tierce-partie en copiant dans le répertoire des
Extensions de la
Bibliothèque du Système une extension tenue en réserve > alors même que cette
Bibliothèque est en principe
verrouillée par le
SIP contre toute modification. Il en va ainsi de logiciels de tierce-partie dont les développeurs ont obtenu d'Apple un tel passe-droit si disputé. Il en va ainsi du logiciel des
Préférences Système dans son action sur la
NVRAM.
--------------------
Si tu m'as suivi dans ce qui n'a que l'apparence d'une complexité verbale > je pense que tu as déjà mentalement tiré la conséquence qui s'impose => si tu veux pouvoir bénéficier comme dans «
Le Bon Vieux Temps » des bénéfices de l'instruction
efi-next-only en
NVRAM > tu dois
désactiver le
SIP en permanence sur ton Mac. Le fait que le
SIP fasse obstruction à la liberté traditionnelle de l'utilisateur d'instruire personnellement les 2 entrées de la
NVRAM :
efi-boot-device &
efi-next-only => cela me semble un argument suffisant pour discréditer entièrement ce protocole.
Je t'engage donc à
désactiver le
SIP par le seul procédé existant --> tu re-démarres les 2 touches
⌘R tenues pressées ensemble du Gong ! jusqu'à la (ce qui est le démarrage sur le
Recovery OS). Une fois affiché le Bureau
Recovery > avec la fenêtre des 4
Utilitaires macOS > va à la barre de menus supérieure de l'écran > menu
Utilitaires > sous-menu «
Terminal». Dans la fenêtre ouverte > saisis la commande :
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande)
- cette commande appelle l'utilitaire csrutil (configuration_security_rootless_utility : utilitaire "sans privilèges root" de sécurisation de la configuration du Système) > avec le verbe disable (désactiver)
- en conséquence > les 6 flags du SIP en NVRAM vont se trouver neutralisés par des valeurs 0
- par suite > les entrées efi-boot-device & efi-next-only se trouvent libérées en écriture
=> tu n'as plus qu'à
re-démarrer et à essayer d'utiliser «
BOOTCAMP» à partir de ta session dans
macOS. Si le logiciel ne marche pas > j'ai personnellement réussi à créer une petite application qui active la commande
bless ad hoc permettant l'instruction en
NVRAM d'une entrée
efi-next-only qui détermine le re-démarrage direct sur
Windows > avec une valeur volatile (effacement par l'
EFI après chargement) > ce qui fait que le Mac re-démarre ensuite automatiquement sur
macOS. Testé avec succès à partir d'une session de «
Sierra» > avec re-démarrage sur «
Windows-7» installé sur une autre partition (j'ai un Mac ancien de 2011).
