de ma part (autant dire : de petites « gloses endormeuses » - autant que le cours de la
- a) lorsqu'à ton message
#25, tu as proposé à
Swaity la commande
diskutil suivante :
La commande est :
diskutil eraseVolume free space /dev/disk1s1
il est clair que, en conséquence de cette suppression de la partition de tête
Microsoft Reserved indexée en
1 (
/dev/disk1s1) par virage à du
free_space, l'indexage de la partition-Système
Macintosh HD du HDD s'est trouvé automatiquement modifié de
2 (
/dev/disk0s2) à
1 (
/dev/disk1s1). Or, l'utilitaire
gpt n'a pas de fonctionnalité documentée dans son
man qui permettrait une manipulation des index de partitions existantes a posteriori. Une fois la partition
Microsoft Reserved supprimée par la commande
diskutil et l'index de la partition-Système modifié de
2 à
1, recréer une partition
EFI est certes possible via
gpt (je viens de le faire sur une clé), mais les blocs
40 à
409600 affectés à son secteur vont être indexés en n°
2 (index vacant) l'index
1 étant déjà pris. La partition
ESP créée sera donc identifiée comme
/dev/disk1s2, la partition-Système étant la
/dev/disk1s1. Nul doute que ce cas de figure ne soit rejeté par l'«
Assistant BootCamp».
Je lis dans les notes finales du
man de
gpt : «
The development of the gpt utility is still work in progress. Many necessary features are missing or partially implemented. In practice this means that the manual page, supposed to describe these features, is farther removed from being complete or useful. As such, missing functionality is not even documented as missing» => il est clair qu'une fonctionnalité "
index" (indexer), sous forme de verbe par exemple, permettant de manipuler les index de partitions existantes sans modifications de la série numérotée de leurs blocs assignés, serait précieuse. Existerait-elle déjà en mode non documenté ? Si non, peut-on l'espérer en chantier ? Pour le cas évoqué dans mon
a, ce serait un moyen de réaffecter un index
1 à une
ESP créée avec un index
2 et donc invalide en l'état pour «
BootCamp».
--------------------
- b) je pense comme toi que, outre la question d'index précédente (l'
ESP doit avoir l'index
1 et pas
2), ce n'est pas au contenu de l'
ESP que l'«
Assistant BootCamp» est sensible, mais à son
format de partition. Lorsqu'on est amené à recréer une
ESP en récupérant les blocs
40 à
409600 rattachés à du
free_space, l'option
-t est décisive pour générer le
format attendu : effectivement soit mention de
efi tout court, soit de l'
UUID constant
C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
Il y a des chances que l'«
Assistant BootCamp» vérifie la correspondance attendue : secteur
1 =
C12A7328-F81F-11D2-BA4B-00A0C93EC93B, sans s'attarder à d'autres critères. On doit pouvoir conjecturer que la taille de la partition ne serait pas même un problème : créer un partionnement pour l'
ESP dépassant largement la limite du
409600è bloc, en décalant en conséquence le point de départ de la partition-Système suivante (avec zone tampon intercalaire
ad-hoc), ne devrait normalement pas bloquer l'«
Assistant BootCamp».
Quant au contenu de l'
ESP, la présence ou l'absence d'un dossier
EFI/APPLE avec ses exécutables ne m'a pas l'air du tout décisive sur le HDD d'un
Fusion Drive. Même si l'on peut évidemment restaurer une copie de ce dossier sur une
ESP créée de toutes pièces.
--------------------
- c) pour manipuler via
gpt la
Table de Partition GUID directrice d'un disque, il est nécessaire que les systèmes de fichiers des partitions existantes soient démontés en volume ; dans le cas contraire, une commande
gpt écrivant à la
Table de Partition avorte avec le message : «
Resource busy ».
Dans le cas de figure qui était celui de
Swaity (partition principale du HDD solidaire du
Volume Logique global monté du
Fusion Drive), impossible de démonter toutes les partitions du HDD afin de faire opérer
gpt si l'OS démarré est celui du
Fusion Drive, donc. D'où la nécessité de démarrer sur un Système auxliaire.
L'utilitaire
gpt est églement présent dans le répertoire
/usr/sbin du Système de la «
Recovery HD» et donc manipulable directement dans son «
Terminal». Néanmoins (je n'ai pas essayé => conjecture), la «
Recovery HD» résidant sur le secteur
s3 du HDD dans un «
Fusion Drive», en cas de démarrage sur elle et même si le Volume monté recelant le Système démarré est celui d'un disque virtuel
.dmg (
BaseSystem.dmg =>
OS X Base System), ne faut-il pas considérer que le système de fichiers primaire du secteur
3 (recelant le dossier global de
boot :
com.apple.recovery.boot) est lui aussi à la base monté en volume et non démontable ? Auquel cas, il ne serait pas possible, dans le «
Terminal» de la «
Recovery HD», d'opérer récursivement sur la
Table de Partition du disque support.
Il faudrait donc que le Système de démarrage réside sur un disque externe (DDE, porteur d'un clone de l'OS du
Fusion Drive, par exemple). À supposer donc cette condition pour que l'utilitaire
gpt soit utilisable à destination de la
Table de Partition du HDD d'un
Fusion Drive, supprimer le
Fusion Drive, retabler le HDD, recréer le
Fusion Drive, rétro-cloner le clone au
Volume Logique neuf (ta dernière préconisation à
Swaity) n'aurait pas constitué une démarche tellement plus
longue que de recréer une
ESP conforme à la
Table de Partition du HDD. Par contre, du point de vue de l'
utilisateur intéressé (et pas de l'expert), une démarche effectuable tout seul avec seulement quelques directives préalables, alors que la recréation d'une
ESP via
gpt nécessiterait d'opérer en mode interactif permanent, étape à étape
(procédé de type "hotline" qui, personnellement parlant, m'a toujours prodigieusement "gavé" ).
Cela dit, d'un point de vue logique formel, la satisfaction intellectuelle de re-créer une
ESP via
gpt est bien supérieure à la satisfaction pragmatique de supprimer/recréer un
Fusion Drive et de rétro-cloner un OS dans son
Volume Logique afin de satisfaire
in fine aux attentes de l'«
Assistant BootCamp»...
