Salut
Dianeli.
Je vole à ton secours
dans un domaine où les décideurs d'Apple concernant l'OS en développement «
El Capitan 10.11» ont pratiqué une valse-hésitation digne de politiciens cherchant à garder l'adhésion du peuple tout en le roulant dans la farine...
⚫︎ Dans les premières
bêta d'«
El Capitan», en effet, une application graphique était disponible dans le menu :
Utilitaires de la partition de récupération «
Recovery HD», nommée : «
Configuration de Sécurité» et offrant une case, cochée par défaut, mais décochable optionnellement, intitulée : "
Enforce System Integrity Protection" (= Imposer la Protection d'Intégrité du Système). Décocher la case, ce qui forçait un re-démarrage, permettait de neutraliser le protocole du
SIP qui inscrit en
NVRAM un argument de
boot restrictif que le
Programme Interne du Mac (l'
EFI) charge au démarrage, pour le passer, via le
boot_loader : boot.efi au
kernel --> en conséquence, une fois l'argument chargé par le
kernel, l'
attribut étendu (
extended_attribute) "
rootless" se trouve associé par le processus de déploiement de l'OS (
launchd) à toute une arborescence critique de dossiers/fichiers système qui interdit leur modification une fois l'OS déployé, même en passant en droits
root (dans le
Finder ou en ligne de commande dans le «
Terminal»).
⚫︎ Dans les dernières
bêta d'«
El Capitan», par contre, cette application graphique avait été supprimée des menus de la «
Recovery HD» pour être transférée à l'intérieur du répertoire
CoreServices de la
Bibliothèque-Système (
/System/Library) de l'OS, sous l'intitulé de : «
SecurityConfiguration.app». Le même type de panneau s'affichait au lancement, proposant une case : "
Enforce System Integrity Protection" cochée par défaut mais décochable et impliquant un re-démarrage. Je me figure qu'un décideur "doué de raison", avisant que la 1ère méthode n'impliquait pas moins de 2 redémarrages (un => «
Recovery HD» ; une autre => «
Macintosh HD») pour neutraliser le
SIP (et 2 autres pour le rétablir
), avait dû proposer une "action directe" depuis la session ouverte de l'utilisateur, ce qui n'impliquait pour chaque action (neutraliser / rétablir) qu'un seul redémarrage...
⚫︎ Dans la GM toute fraîche d'«
El Capitan», toute espèce d'application graphique a disparu, aussi bien des
CoreServices de l'OS (2è état des choses), que du menu
Utilitaires de la «
Recovery HD» (1ère mouture). L'utilisateur est-il donc réduit à passer dans le «
Terminal» de sa session une commande :
Bloc de code:
sudo nvram boot-args="kext-dev-mode=1 rootless=0"
comme tu l'as fait (ce qui invoque en droits
root le programme
nvram capable de manipuler les arguments de
boot de la mémoire
NVRAM de la Carte-Mère avec la spécification
boot-args = arguments de boot et les 2 options :
kext-dev-mode=1 --> licence de démarrer en mode développeur pour pouvoir faire charger des extensions du noyau expérimentales et non signées Apple sans subir les foudres du protocole du
kext_signing datant de «
Yosemite» +
rootless=0 --> associer l'argument
rootless à une valeur
0 de nullité) ?
☞ Le 1er argument ne se défendait que tant que le
TRIM ne pouvait être activé sur des SSD de tierce-partie qu'après modification d'une extension native Apple et qu'il fallait donc désactiver le
kext_signing pour ne pas planter l'OS au démarrage. C'était la solution adoptée par «
Trim Enabler» (aux risques et périls de l'utilisateur qui faisait un
reset_NVRAM par exemple). Mais, depuis qu'Apple a créé une extension spéciale permettant d'activer le
TRIM sur les SSD de tierce-partie et activable via la commande :
sudo trimforce enable (extension activable sous «
El Capitan» comme à partir de «
Yosemite 10.10.4»), plus rien ne justifie le maintien en
NVRAM d'un argument de
boot :
kext-dev-mode=1 si l'on n'est pas un développeur d'extensions (à moins de vouloir continuer de courir le risque de plantage de l'OS
).
☞ Reste l'argument de
boot :
rootless=0 --> comme tu t'en es aperçu, alors même que cet argument est inscrit dans la
NVRAM de la Carte-Mère de ton Mac (par exemple si tu passes la commande informative :
sudo nvram boot-args), cela n'empêche pas le
SIP d'exercer son emprise verrouillant l'état des fichiers-Système une fois l'OS déployé. Sur ce point, je n'ai pour l'heure qu'une conjecture à t'offrir : l'argument de
boot rootless=0 n'a l'air de neutraliser le protocole du
SIP que sur un sous-ensemble restreint des fichiers-Système ciblés ou regardant une modalité d'emprise seulement de l'
attribut étendu rootless distribué par le processus
launchd à l'arborescence critique des fichiers-Système de l'OS.
⚫︎ Que faire alors ? Alors, il te faut impérativement démarrer sur ta partition de récupération «
Recovery HD 10.11» et aller au menu
Utilitaires de la barre supérieure des menus, pour lancer le «
Terminal» (où l'invite de commande
-bash-3.2# te signale que tu es en droits
root). Il te faut invoquer le programme
csrutil (qui manipule exclusivement le protocole intégral du
SIP mais n'est pas invocable depuis l'OS démarré - seulement depuis la partition de récupétion démarrée) et tu as le panel suivant de commandes possibles :
Bloc de code:
csrutil status
csrutil clean
csrutil disable
csrutil enable
-->
csrutil status te renvoie la notification de l'état actuel du
SIP (
enabled vs
disabled) sur le système de fichiers de l'OS sans re-démarrage. Toutes les autres commandes impliquent un re-démarrage automatique :
csrutil clean --> remet la NVRAM au défaut en réactivant le SIP.
csrutil disable --> neutralise intégralement le SIP en NVRAM et réautorise une manipulation root des fichiers-Système de l'OS (sans toucher les autres boot-args en place).
csrutil enable --> réactive le SIP en NVRAM et interdit la manipulation root des fichiers-Système de l'OS (sans toucher les autres boot-args en place).
