Vivid
Une ré-installation de l'OS n'affectera que la couche la plus élevée du dispositif du
CoreStorage : le volume
Macintosh HD.
Ce volume
Macintosh HD est défini par un système de fichiers
jhfs+ standard qui s'ancre à un
dev node (un nœud d'appareil) purement virtuel porté par l'instance logique du
Logical Volume (
Volume Logique CoreStorage) - lequel, malgré ce que son intitulé laisse imaginer, n'est pas un "volume", mais un
disque virtuel. Un disque virtuel de second ordre, miroir du disque virtuel de premier ordre du
Physical Volume (
Volume Physique CoreStorage).
Ce laïus abscons pour dire : la ré-installation de l'OS ne modifiera absolument pas la configuration des partitions de tes disques. Elle n'opérera que tout en haut de la pile du
CoreStorage > qui repose sur 3
Physical Volumes inscrits sur les 3 partitions
disk0s1 >
disk1s1 >
disk1s5 (c'est toujours
disk1s5 au lieu de
disk1s3 parce que tu n'as
pas re-démarré - ce que tu devrais faire sans attendre pour permettre au
kernel de se mettre-à-jour). Ces
Physical Volumes basiques sont des re-descriptions de l'espace interne de blocs de ces 3 partitions comme équivalant à des "disques physiques virtuels".
Ces "disques physiques virtuels" sont incapables d'exporter automatiquement leur instance-miroir : le "disque logique virtuel" du
Logical Volume unique du
CoreStorage. D'où la nécessité de «
boot_helper_partitions » : des «
booters » ou auxiliaires d'exportation du
Volume Logique à partir des
Volumes Physiques supports. Il faut autant de «
booters » que de
Volumes Physiques participant d'un
CoreStorage. Tu as un «
booter »
Boot OS X en
disk0s2 sur le SSD pour le
Volume Physique de la partition
disk0s1 > un «
booter »
Boot OS X en
disk1s6 (qui deviendra
disk1s4 si tu redémarres) sur le HDD pour le
Volume Physique de la partition
disk1s5 (qui deviendra
disk1s3 si tu redémarres) et... et pour le
Volume Physique de la partition
disk1s1 de
2,2 To (te demandes-tu) ?
Il existe également mais il ne se voit pas. Car c'est la partition
Recovery HD disk1s2 elle-même, qui sous ses apparences de partition de secours, est la «
boot_helper_partition » du
Volume Physique disk1s1 > en ce qu'elle recèle son «
booter » dans un dossier spécial intitulé
com.apple.Boot.R du volume
Recovery HD.
Bref : ré-installer l'OS ne va absolument pas affecter la distribution actuelle des partitions sur les 2 disques --> les 3 partitions «
Volumes Physiques » > accompagnées des 3 «
boot_helper_partitions » des «
booters », permettant l'exportation du disque virtuel de second ordre du
Volume Logique > sur lequel va se monter un volume
Macintosh HD standard > dans lequel vont résider les fichiers de l'OS.
[La « Métaphysique » s'est réfugiée chez les Américains dans l'« Informatique » (au lieu de la « Philosophie ») - le CoreStorage Apple constituant le sommet de la Métaphysique Informatique > en attendant son évolution prochaine : le système de fichiers APFS (qui n'est qu'un surjet du CoreStorage).]
--------------------
Tu peux toujours dans le «
Terminal» passer les 2 commandes :
Bloc de code:
sudo gpt show /dev/disk0
sudo gpt show /dev/disk1
- après validation de la première > une demande de password va s'afficher - commande sudo --> tape ton mot-de-passe de session admin à l'aveugle - aucun caractère ne se montrant à la frappe - et de nouveau valide ;
- après validation de la seconde > aucune demande de password ne va s'afficher --> car dans les 5' suivant une première authentificaiton pour un sudo > aucun mot-de-passe n'est requis par commodité pour l'utilisateur du shell.
=> ces 2 commandes vont afficher les tableaux de la distribution des blocs des 2 disques > avec les secteurs occupés par les tables de partition > par les partitions > et par les bandes d'espace libre.
Tu n'as qu'à les poster ici > il sera facile d'aviser s'il y a sur chacun des 2 disques (SSD & HDD) un secteur de blocs :
ayant le statut d'espace libre (non défini comme
GPT part) et la taille (=
209 Mo) d'une
EFI_System_Partition. Si oui > alors un programme d'installation de
Windows aura supprimé ces partitions à un moment donné > en laissant les blocs correspondants à l'état d'espace libre.
Dans ces conditions > il est toujours possible de récupérer ces blocs > pour en refaire des partitions de type
EFI > le tout étant de savoir si l'index de ces partitions recréées sera bien le n°
1 comme requis. Tout dépend de la manière dont ces partitions ont été supprimées au départ > càd. de la question de savoir si une redistribution des index de partitions a été enregistrée dans la
GPT des blocs
1 >
32 ; ou si chaque partition
CoreStorage de tête (
disk0s1 &
disk1s1) > apparemment indexée comme n°
1 sur chaque disque > se trouve en fait indexée comme n°
2 dans chaque
GPT > de sorte que l'index n°
1 ne soit qu'une
apparence suscitée par le
kernel.
L'existence de ces partitions
EFI en tête de disques lorsqu'une table
GPT en décrit l'espace de blocs > peut être décisive > s'il s'agit d'inscrire des exécutables de boot (par exemple ceux du gestionnaire de démarrage «
rEFInd» - voire des exécutables
Windows) qui revendiquent cette partition.
