10.11 El Capitan Disable SIP osx 10.11.14
- Créateur du sujet bibinoel
- Date de début
D
Deleted member 1099514
Invité
En effet pas de partition Recovery. Est-ce normal sur une config Raid?Non
Édit : après avoir fait ton combo sa ne fonctionne toujours pas
Sent from my iPhone using Forums iGeneration mobile app
Sinon tu dois démarrer en mode Recovery internet sur une version ne supportant pas la commande csrutil.
La seule solution que je vois, est d'installer El Capitan sur une clé ou un DDE, de démarrer dessus en mode Recovery et là les commandes csrutil passeront.
M
Membre supprimé 1060554
Invité
Comme j'avais 2 HDD de 500 Go chacun qui prenaient la poussière dans un tiroir, je les ai solidarisés dans un dispositif AppleRAID de type miroir, ce qui a exporté un volume unique intitulé HDD-RAID. Voici la structure logique de départ révélée par un diskutil list :
=> comme on l'aperçoit nettement, chaque disque se trouve tri-partitionné de manière égalitaire : une partition n°1 = ESP (EFI System Partition de 209 Mo), une partition n°2 recélant la bande-RAID Apple_RAID et enfin une partition n°3 recélant le booter associé Apple_Boot Boot OS X permettant le montage d'un volume à partir de la bande RAID. Un volume unique Apple_HFS HDD-RAID de la taille exacte de chaque bande RAID isolée se trouve donc exporté.
J'ai ensuite déclenché l'installation d'«El Capitan 10.10.4» à destination du volume-RAID : HDD-RAID. Après ouverture de session dans ce dernier OS, voici la structure logique d'arrivée révélée encore par un diskutil list :
=> il ne faut pas être grand clerc pour apercevoir que rien n'a changé dans le dispositif antérieur, càd. qu'aucune partition de récupération «Recovery HD» n'a été générée, ni sur un disque, ni sur l'autre.
J'ai tenté de forcer la création d'une «Recovery HD» en utilisant le binaire spécialisé dmtest (utilisé comme moteur par l'application «Recovery Creator») : la réponse de l'utilitaire est sans aucun ambage => "Error (async): The given disk has a storage system (such as AppleRAID) which is not supported for this operation (-69718)" (Erreur : le disque désigné a un type de stockage (tel qu'AppleRAID) qui n'est pas supporté pour cette opération).
Il y a donc incompatibilité formelle entre le dispostif AppleRAID et l'existence d'une partition de récupération «Recovery HD» logiquement inassociable à l'OS installé sur le volume unique exporté par ce dispositif. Ce qui induit une kyrielle de conséquences dont : le Chiffrement «FileVault» n'est pas supporté par le volume Apple-RAID (pour 2 raisons : ce volume ne peut être converti au format CoreStorage requis par le chiffrement ; et la partition «Recovery HD» nécessaire au démarrage du Mac en cas de Volume Chiffré ne peut être créée) ; le SIP ne peut être « normalement » désactivé pour l'OS «El Capitan» du volume AppleRAID, puisqu'il ne peut l'être que depuis une «Recovery HD» logiquement associée lors de l'installation à l'OS d'un volume - ce qui est forclos par l'impossibilité de créer une «Recovery HD» associée à l'OS d'un volume AppleRAID.
Je pense que la solution serait celle de Jean
=> installer «El Capitan» sur un DDE USB - ce qui créera une «Recovery HD» collatérale sur le DDE. Re-démarrer sur la «Recovery HD» du DDE et désactiver le SIP, ce qui, théoriquement, ne fait qu'adresser une instruction à la NVRAM virant les 6 flags "rootless" à la valeur csr-active-config w%00%00%00 (vérifiable par un nvram -p). Un re-démarrage sur l'OS du volume AppleRAID révèlera vraisemblablement que, suite à cette modification des flags de la NVRAM, l'EFI n'a pas chargé de flags "rootless", ne les a donc pas passés au boot_loader boot.efi qui ne les a pas injectés dans le kernel, en suite de quoi le SIP n'a pas été réappliqué au Système de l'OS «El Capitan» (vérifier par un csrutil status).
Personnellement, je me contenterai de créer une «Recovery HD» solitaire sur une clé USB grâce au binaire dmtest et à 2 ressources de l'installateur d'«El Capitan», ce qui ne prendrait que 5' - mais ce procédé étant "ésotérique", je renvoie à la solution pré-citée...
[tacle de dernière minute : je ne vois pas l'intérêt d'associer 2 SSD internes à un Mac de 250 Go chacun dans une structure AppleRAID miroir qui devrait servir simplement pour du stockage de données ("auto-préservées" par ce dispositif redondant) ; non pour accueillir un Système OS X démarrable...]
Bloc de code:
/dev/disk1 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_RAID 499.8 GB disk1s2
3: Apple_Boot Boot OS X 134.2 MB disk1s3
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_RAID 499.8 GB disk2s2
3: Apple_Boot Boot OS X 134.2 MB disk2s3
/dev/disk3 (external, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS HDD-RAID +499.8 GB disk3=> comme on l'aperçoit nettement, chaque disque se trouve tri-partitionné de manière égalitaire : une partition n°1 = ESP (EFI System Partition de 209 Mo), une partition n°2 recélant la bande-RAID Apple_RAID et enfin une partition n°3 recélant le booter associé Apple_Boot Boot OS X permettant le montage d'un volume à partir de la bande RAID. Un volume unique Apple_HFS HDD-RAID de la taille exacte de chaque bande RAID isolée se trouve donc exporté.
J'ai ensuite déclenché l'installation d'«El Capitan 10.10.4» à destination du volume-RAID : HDD-RAID. Après ouverture de session dans ce dernier OS, voici la structure logique d'arrivée révélée encore par un diskutil list :
Bloc de code:
/dev/disk1 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_RAID 499.8 GB disk1s2
3: Apple_Boot Boot OS X 134.2 MB disk1s3
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_RAID 499.8 GB disk2s2
3: Apple_Boot Boot OS X 134.2 MB disk2s3
/dev/disk3 (external, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS HDD-RAID +499.8 GB disk3=> il ne faut pas être grand clerc pour apercevoir que rien n'a changé dans le dispositif antérieur, càd. qu'aucune partition de récupération «Recovery HD» n'a été générée, ni sur un disque, ni sur l'autre.
J'ai tenté de forcer la création d'une «Recovery HD» en utilisant le binaire spécialisé dmtest (utilisé comme moteur par l'application «Recovery Creator») : la réponse de l'utilitaire est sans aucun ambage => "Error (async): The given disk has a storage system (such as AppleRAID) which is not supported for this operation (-69718)" (Erreur : le disque désigné a un type de stockage (tel qu'AppleRAID) qui n'est pas supporté pour cette opération).
Il y a donc incompatibilité formelle entre le dispostif AppleRAID et l'existence d'une partition de récupération «Recovery HD» logiquement inassociable à l'OS installé sur le volume unique exporté par ce dispositif. Ce qui induit une kyrielle de conséquences dont : le Chiffrement «FileVault» n'est pas supporté par le volume Apple-RAID (pour 2 raisons : ce volume ne peut être converti au format CoreStorage requis par le chiffrement ; et la partition «Recovery HD» nécessaire au démarrage du Mac en cas de Volume Chiffré ne peut être créée) ; le SIP ne peut être « normalement » désactivé pour l'OS «El Capitan» du volume AppleRAID, puisqu'il ne peut l'être que depuis une «Recovery HD» logiquement associée lors de l'installation à l'OS d'un volume - ce qui est forclos par l'impossibilité de créer une «Recovery HD» associée à l'OS d'un volume AppleRAID.
--------------------
Je pense que la solution serait celle de Jean
=> installer «El Capitan» sur un DDE USB - ce qui créera une «Recovery HD» collatérale sur le DDE. Re-démarrer sur la «Recovery HD» du DDE et désactiver le SIP, ce qui, théoriquement, ne fait qu'adresser une instruction à la NVRAM virant les 6 flags "rootless" à la valeur csr-active-config w%00%00%00 (vérifiable par un nvram -p). Un re-démarrage sur l'OS du volume AppleRAID révèlera vraisemblablement que, suite à cette modification des flags de la NVRAM, l'EFI n'a pas chargé de flags "rootless", ne les a donc pas passés au boot_loader boot.efi qui ne les a pas injectés dans le kernel, en suite de quoi le SIP n'a pas été réappliqué au Système de l'OS «El Capitan» (vérifier par un csrutil status).Personnellement, je me contenterai de créer une «Recovery HD» solitaire sur une clé USB grâce au binaire dmtest et à 2 ressources de l'installateur d'«El Capitan», ce qui ne prendrait que 5' - mais ce procédé étant "ésotérique", je renvoie à la solution pré-citée...
[tacle de dernière minute : je ne vois pas l'intérêt d'associer 2 SSD internes à un Mac de 250 Go chacun dans une structure AppleRAID miroir qui devrait servir simplement pour du stockage de données ("auto-préservées" par ce dispositif redondant) ; non pour accueillir un Système OS X démarrable...]
Dernière édition par un modérateur:
@bibinoel
@macomaniac
OK. Donc en RAID pas de partition de Recovery.
Cependant je suis curieux de savoir si SIP a été quand même activé lors de l'install d'OSX. Pouvez-vous faire csrutil status siouplaît ?
@macomaniac
OK. Donc en RAID pas de partition de Recovery.
Cependant je suis curieux de savoir si SIP a été quand même activé lors de l'install d'OSX. Pouvez-vous faire csrutil status siouplaît ?
D
Deleted member 1099514
Invité
SIP est activé par défaut. Je ne vois pas en quoi le type d'install RAID changerai quelque chose.
SIP est activé par défaut. Je ne vois pas en quoi le type d'install RAID changerai quelque chose.
Excuse ma curiosité. Merci, mais j'aimerais bien avoir la réponse des personnes à qui j'ai posé ma question.
Autre chose, les efforts pour désactiver SIP dans cette situation singulière seront mis à mal par un reset de NVRAM qui réactivera SIP aussi sec. Reset de NVRAM qui est recommandé à tire-larigot dans le coin ici et là.
Donc une solution pérenne et secure serait de faire une ré-install sur un setup supporté par le développeur de l'OS.
D
Deleted member 1099514
Invité
La seule méthode, à ma connaissance, de désactiver le SLIP du Capitaine est de le faire en mode Recovery.
Donc il suffit d'avoir une Recovery "El Capitan" sur un DDE ou une clé pour faire cela.
C'est donc ce que je préconise de faire post #24
D
Deleted member 1099514
Invité
Ce qui serait pas mal de tenter serait :
Démarrer en mode Internet Recovery et tenter :
/Volumes/ssdraid/usr/bin/csrutil disable
Démarrer en mode Internet Recovery et tenter :
/Volumes/ssdraid/usr/bin/csrutil disable
D
Deleted member 1099514
Invité
Donc le plus simple serait dans un premier temps, depuis un boot sur cette clé, d'ouvrir un terminal et de passer la commande :
csrutil disable
M
Membre supprimé 1060554
Invité
Je reviens avec quelques informations issues d'expérimentations (adornées d'implications dont on me laissera la seule responsablité) :
- a) j'ai créé sur une clé USB une «Recovery HD 10.11» (en utilisant dmtest) => la commande csrutil enable (ou disable aussi bien) est parfaitement honorée une fois démarré sur cette récupération. Idem, si l'on démarre sur la «Recovery HD 10.11» d'un DDE (créée sur ce disque par «CCC»).
=> je pense qu'on peut en tirer la règle suivante : peu importe la localisation de la partition de récupération (disque du Mac, DDE, clé USB, voire disque virtuel d'une «Recovery Internet» téléchargé en RAM si l'OS d'usine du Mac, forcément très récent, est «El Capitan») --> dès lors qu'il s'agit bien d'une version 10.11 (peu importe la MÀJ), l'utilitaire csrutil est fonctionnel pour désactiver / activer le SIP.
- b) j'ai démarré sur la «Recovery Internet» de mon MacBook Pro 17" Late_2011 dont l'OS d'usine est «Lion 10.7.2» (donc une «Recovery 10.7»). Appeler dans le «Terminal» l'utilitaire csrutil résidant at: /usr/bin dans le volume de mon OS «El Capitan 10.11.4» du disque avec quelque option que ce soit : status, disable, enable se solde par le même retour : operation not supported.
=> il est clair que cet exécutable requiert un environnement logiciel ad hoc (je pense à des frameworks) pour être opératoire.
- c) le SIP étant désactivé par défaut sur mon Mac, je l'ai activé à partir d'une «Recovery HD» idoine et j'ai re-démarré sur le clone du volume «El Capitan 10.11.4» de mon disque, clone résidant sur un SSD thunderbolt : la commande csrutil status révèle que le SIP est activé pour l'OS du clone.
=> il est clair que les commandes d'activation / désactivation du SIP s'adressent seulement à la NVRAM pour y inscrire les flags correspondants (csr-active-config w%10%00%00 vs w%00%00%00). Dès lors qu'ensuite on démarre sur un OS (interne ou externe) dont le kernel est susceptible de charger ces flags, càd. une version d'«El Capitan» --> alors le kernel les refile à launchd dans la phase d'activation du Système et l'affaire est dite. Par contre, bien évidemment, démarrer sur des OS rétrogrades (de 10.6 à 10.10) ne produit aucun effet, le kernel de ces Systèmes étant insusceptible de charger ces flags (ils doivent donc être "échappés" quand l'EFI tente de les passer au boot_loader boot.efi en position de relayeur).
- d) bien évidemment, des commandes autres que csrutil status (càd. disable vs enable) dans l'environnement de l'OS «El Capitan» ne sont pas prises en compte, alors que manifestement l'environnement logiciel le permettrait (l'OS de la «Recovery HD 10.11» en étant un analogue allégé). Dans une bêta intermédiaire des pré-versions d'«El Capitan», je me souviens qu'il a existé une application «Security Configuration.app» qui s'est trouvée localisée at: /System/Library/CoreStorage/Applications et qui désactivait très bien le SIP depuis l'environnement de l'OS démarré. En appelant sans aucun doute l'utilitaire csrutil at: /usr/bin. Dans la bêta suivante, cette application a été déloggée de l'OS, pour être provisoirement loggée dans les Utilitaires de la «Recovery HD 10.11» où elle devait pareillement appeler csrutil à la localisation correspondante du Système de la récupération (elle a été finalement supprimée au bénéfice de la seule commande).
=> j'en conjecture que csrutil doit être intrinsèquement viable dans l'environnement de l'OS «El Capitan», mais qu'une instruction de vérification de l'environnement a dû être implémentée in fine dans son code, qui bloque ses actions quand l'environnement d'une «Recovery HD 10.11» n'est pas validé.
=> je pense qu'on peut en tirer la règle suivante : peu importe la localisation de la partition de récupération (disque du Mac, DDE, clé USB, voire disque virtuel d'une «Recovery Internet» téléchargé en RAM si l'OS d'usine du Mac, forcément très récent, est «El Capitan») --> dès lors qu'il s'agit bien d'une version 10.11 (peu importe la MÀJ), l'utilitaire csrutil est fonctionnel pour désactiver / activer le SIP.
--------------------
- b) j'ai démarré sur la «Recovery Internet» de mon MacBook Pro 17" Late_2011 dont l'OS d'usine est «Lion 10.7.2» (donc une «Recovery 10.7»). Appeler dans le «Terminal» l'utilitaire csrutil résidant at: /usr/bin dans le volume de mon OS «El Capitan 10.11.4» du disque avec quelque option que ce soit : status, disable, enable se solde par le même retour : operation not supported.
=> il est clair que cet exécutable requiert un environnement logiciel ad hoc (je pense à des frameworks) pour être opératoire.
--------------------
- c) le SIP étant désactivé par défaut sur mon Mac, je l'ai activé à partir d'une «Recovery HD» idoine et j'ai re-démarré sur le clone du volume «El Capitan 10.11.4» de mon disque, clone résidant sur un SSD thunderbolt : la commande csrutil status révèle que le SIP est activé pour l'OS du clone.
=> il est clair que les commandes d'activation / désactivation du SIP s'adressent seulement à la NVRAM pour y inscrire les flags correspondants (csr-active-config w%10%00%00 vs w%00%00%00). Dès lors qu'ensuite on démarre sur un OS (interne ou externe) dont le kernel est susceptible de charger ces flags, càd. une version d'«El Capitan» --> alors le kernel les refile à launchd dans la phase d'activation du Système et l'affaire est dite. Par contre, bien évidemment, démarrer sur des OS rétrogrades (de 10.6 à 10.10) ne produit aucun effet, le kernel de ces Systèmes étant insusceptible de charger ces flags (ils doivent donc être "échappés" quand l'EFI tente de les passer au boot_loader boot.efi en position de relayeur).
--------------------
- d) bien évidemment, des commandes autres que csrutil status (càd. disable vs enable) dans l'environnement de l'OS «El Capitan» ne sont pas prises en compte, alors que manifestement l'environnement logiciel le permettrait (l'OS de la «Recovery HD 10.11» en étant un analogue allégé). Dans une bêta intermédiaire des pré-versions d'«El Capitan», je me souviens qu'il a existé une application «Security Configuration.app» qui s'est trouvée localisée at: /System/Library/CoreStorage/Applications et qui désactivait très bien le SIP depuis l'environnement de l'OS démarré. En appelant sans aucun doute l'utilitaire csrutil at: /usr/bin. Dans la bêta suivante, cette application a été déloggée de l'OS, pour être provisoirement loggée dans les Utilitaires de la «Recovery HD 10.11» où elle devait pareillement appeler csrutil à la localisation correspondante du Système de la récupération (elle a été finalement supprimée au bénéfice de la seule commande).
=> j'en conjecture que csrutil doit être intrinsèquement viable dans l'environnement de l'OS «El Capitan», mais qu'une instruction de vérification de l'environnement a dû être implémentée in fine dans son code, qui bloque ses actions quand l'environnement d'une «Recovery HD 10.11» n'est pas validé.
--------------------
Dernière édition par un modérateur:
M
Membre supprimé 1060554
Invité
Je me suis livré à un petit bricolage facétieux dont voici le tableau d'après une commande diskutil list :
On a bien affaire à une matrice-RAID miroir exportant un volume unique HDD-RAID de 499 Go, mais chacun des 2 disques associés de 500 Go chacun se trouve ce coup-ci quadri-partitionné : ESP de 209 Mo > Bande-RAID de 499 Go > Booter de 134 Mo > Recovery HD de 650 Mo.
Tant qu'à avoir une matrice-RAID à 2 disques dans un MacBook Pro dont le volume exporté contienne l'OS «El Capitan» + les données ; mieux vaut quand même disposer d'une «Recovery HD 10.11» - que dis-je ? de 2 «Recovery HD 10.11» en miroir par souci architectural de symétrie classique (un esprit préférant le goût baroque pour l'asymétrie aurait très bien pu n'établir qu'une «Recovery HD 10.11» en disk1s4 et s'abstenir d'en générer une redondante en disk2s4 - une matrice-RAID miroir supportant un 2è disque associé d'une taille supérieure au paradigme du premier, cela aurait donné une bande-RAID de 499,7 Go en disk2s2).
Ne pas s'imaginer qu'une dérogation aux règles de l'Apple-RAID soit intervenue, qui eût permis à l'installation d'«El Capitan» dans le volume exporté HDD-RAID un retaillage de la matrice-RAID avec création de 2 partitions de 650 Mo pour l'installation de «Recovery HD». Une matrice-RAID, une fois constituée, est absolument rigide en taille : aucun verbe n'est disponible pour l'utilitaire diskutil qui permettrait de la re-dimensionner dynamiquement, comme il est possible de le faire pour l'architecture d'un CoreStorage incluant 2 disques (dispositif Fusion Drive).
Non : le tableau que j'ai posté ci-dessus ne fait qu'enregistrer le résultat des artifices malicieux du signataire, en amont de la mise en place de la matrice-RAID. J'ai tout bonnement créé 2 volumes utilisables sur chaque disque, au format jhfs+ dans un premier temps : le principal (disk1s2 & disk2s2) de 499,1 Go et le secondaire (disk1s3 et disk2s3) de 650 Mo. Puis j'ai converti par l'utilitaire gpt les 2 partitions mineures de 650 Mo au format Apple_Boot avec l'UUID universel des «Recovery HD», ce qui m'a créé 2 volumes invisibles identifiés comme Apple_Boot Recovery HD, vides de tout dossier de boot chacun (je voulais tester une hypothèse ténue encore).
J'ai donc créé ensuite ma matrice-RAID miroir en associant les 2 partitions (et pas disques) disk1s2 & disk2s2, ce qui a bien créé les 2 bandes-RAID du tableau + créé par un petit repartionnement les 2 partitions de 134 Mo des booters disk1s3 & disk2s3, en rejetant les Recovery HD un cran après (en disk1s4 & disk2s4). J'ai installé «El Capitan» dans le volume exporté HDD-RAID et j'ai pu vérifier que, bien que des partitions d'accueil droites dans leurs bottes (Apple_Boot Recovery HD 650 Mo) ait été disponibles juste en-dessous de chaque bande-RAID ; aucune installation de dossier de boot com.apple.recovery.boot n'a été effectuée dans aucun de ces volumes.
Cela fait, j'ai injecté manuellement les dossiers com.apple.recovery.boot contenant les Boot_Files et le disque de démarrage BaseSystem.dmg d'une partition de récupération > un coup de goupillon "bless" et hop ! 2 «Recovery HD» fonctionnelles. J'ai pu tester que leur existence collatérale des bandes-RAID ne nuit absolument pas au démarrage sur l'OS du volume exporté HDD-RAID ; qu'il est possible par ailleurs de démarrer sur chacune exactement comme sur une «Recovery HD» installée par défaut et que le SIP est parfaitement manipulable dans leur «Terminal» via l'utilitaire csrutil. Enfin, que l'OS «El Capitan» du volume HDD-RAID exporté par la matrice-RAID miroir est parfaitement "réceptif" aux variations de flags induites par ces commandes dans la NVRAM : le kernel les réceptionne bien et passe bien les instructions à launchd, de sorte que le SIP est soit désactivé, soit réactivé dans l'OS HDD-RAID.
☞ Ces bricolages récréatifs m'ont confirmé dans mon sentiment primitif : utiliser une matrice-RAID miroir dans un Mac pour avoir un OS installé dans le volume exporté est un non-sens qui n'amène que des ennuis. Une matrice-RAID miroir devrait être strictement réservée pour un stockage de données sans système installé.
Bloc de code:
/dev/disk1 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_RAID 499.0 GB disk1s2
3: Apple_Boot Boot OS X 134.2 MB disk1s3
4: Apple_Boot Recovery HD 650.0 MB disk1s4
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_RAID 499.0 GB disk2s2
3: Apple_Boot Boot OS X 134.2 MB disk2s3
4: Apple_Boot Recovery HD 650.0 MB disk2s4
/dev/disk3 (external, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS HDD-RAID +499.0 GB disk3On a bien affaire à une matrice-RAID miroir exportant un volume unique HDD-RAID de 499 Go, mais chacun des 2 disques associés de 500 Go chacun se trouve ce coup-ci quadri-partitionné : ESP de 209 Mo > Bande-RAID de 499 Go > Booter de 134 Mo > Recovery HD de 650 Mo.
Tant qu'à avoir une matrice-RAID à 2 disques dans un MacBook Pro dont le volume exporté contienne l'OS «El Capitan» + les données ; mieux vaut quand même disposer d'une «Recovery HD 10.11» - que dis-je ? de 2 «Recovery HD 10.11» en miroir par souci architectural de symétrie classique (un esprit préférant le goût baroque pour l'asymétrie aurait très bien pu n'établir qu'une «Recovery HD 10.11» en disk1s4 et s'abstenir d'en générer une redondante en disk2s4 - une matrice-RAID miroir supportant un 2è disque associé d'une taille supérieure au paradigme du premier, cela aurait donné une bande-RAID de 499,7 Go en disk2s2).
Ne pas s'imaginer qu'une dérogation aux règles de l'Apple-RAID soit intervenue, qui eût permis à l'installation d'«El Capitan» dans le volume exporté HDD-RAID un retaillage de la matrice-RAID avec création de 2 partitions de 650 Mo pour l'installation de «Recovery HD». Une matrice-RAID, une fois constituée, est absolument rigide en taille : aucun verbe n'est disponible pour l'utilitaire diskutil qui permettrait de la re-dimensionner dynamiquement, comme il est possible de le faire pour l'architecture d'un CoreStorage incluant 2 disques (dispositif Fusion Drive).
Non : le tableau que j'ai posté ci-dessus ne fait qu'enregistrer le résultat des artifices malicieux du signataire, en amont de la mise en place de la matrice-RAID. J'ai tout bonnement créé 2 volumes utilisables sur chaque disque, au format jhfs+ dans un premier temps : le principal (disk1s2 & disk2s2) de 499,1 Go et le secondaire (disk1s3 et disk2s3) de 650 Mo. Puis j'ai converti par l'utilitaire gpt les 2 partitions mineures de 650 Mo au format Apple_Boot avec l'UUID universel des «Recovery HD», ce qui m'a créé 2 volumes invisibles identifiés comme Apple_Boot Recovery HD, vides de tout dossier de boot chacun (je voulais tester une hypothèse ténue encore).
J'ai donc créé ensuite ma matrice-RAID miroir en associant les 2 partitions (et pas disques) disk1s2 & disk2s2, ce qui a bien créé les 2 bandes-RAID du tableau + créé par un petit repartionnement les 2 partitions de 134 Mo des booters disk1s3 & disk2s3, en rejetant les Recovery HD un cran après (en disk1s4 & disk2s4). J'ai installé «El Capitan» dans le volume exporté HDD-RAID et j'ai pu vérifier que, bien que des partitions d'accueil droites dans leurs bottes (Apple_Boot Recovery HD 650 Mo) ait été disponibles juste en-dessous de chaque bande-RAID ; aucune installation de dossier de boot com.apple.recovery.boot n'a été effectuée dans aucun de ces volumes.
Cela fait, j'ai injecté manuellement les dossiers com.apple.recovery.boot contenant les Boot_Files et le disque de démarrage BaseSystem.dmg d'une partition de récupération > un coup de goupillon "bless" et hop ! 2 «Recovery HD» fonctionnelles. J'ai pu tester que leur existence collatérale des bandes-RAID ne nuit absolument pas au démarrage sur l'OS du volume exporté HDD-RAID ; qu'il est possible par ailleurs de démarrer sur chacune exactement comme sur une «Recovery HD» installée par défaut et que le SIP est parfaitement manipulable dans leur «Terminal» via l'utilitaire csrutil. Enfin, que l'OS «El Capitan» du volume HDD-RAID exporté par la matrice-RAID miroir est parfaitement "réceptif" aux variations de flags induites par ces commandes dans la NVRAM : le kernel les réceptionne bien et passe bien les instructions à launchd, de sorte que le SIP est soit désactivé, soit réactivé dans l'OS HDD-RAID.
☞ Ces bricolages récréatifs m'ont confirmé dans mon sentiment primitif : utiliser une matrice-RAID miroir dans un Mac pour avoir un OS installé dans le volume exporté est un non-sens qui n'amène que des ennuis. Une matrice-RAID miroir devrait être strictement réservée pour un stockage de données sans système installé.
je reboot
Chapeau à toi merci, vous autre !
Je suis ce forum de très prés maintenant
Je vois que la mentalité du monde Apple n'a rien à voir avec celle des brebis ( vous m'avez compris )
Dernière édition:
je reboot
Chapeau à toi merci, vous autre !
Je suis ce forum de très prés maintenant
Je vois que la mentalité du monde Apple n'a rien à voir avec celle des brebis ( vous m'avez compris )
Merci à toi aussi. J'ai aussi appris des choses.
Garde à l'esprit qu'un reset NVRAM (CMD-ALT-P-R) réactivera SIP, à moins que tu as mis un firmware password pour désactiver les séquences de boot alternatives. Sinon garde ta clé bootable dans la popoche.
j ai pu installer le 5.1 sur le 4.1 sur mon mac pro avec el capitan
csrutil disable a marche en mode recuperation dans le terminal
mais quand j ai voulu faire csrutil enable , j ai command not found
csrutil disable a marche en mode recuperation dans le terminal
mais quand j ai voulu faire csrutil enable , j ai command not found
