Le problème posé par
Antoine est purement théorique et rétrospectif > je le traite comme tel.
En me référant aux données de ton message
#1 (qui ne sont plus d'actualité) > après clonage du contenu de ton
macOS Sierra dans
El Captian > ce qui, fait avec «
CCC», t'aurait cloné une
Recovery HD en-dessous d'
El Captian > tu te serais retrouvé avec le tableau de partitions suivant :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS El Captian 125.0 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_CoreStorage macOS Sierra 124.4 GB disk0s4
5: Apple_Boot Recovery HD 650.0 MB disk0s5
/dev/disk1 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: macOS Sierra +123.4 GB disk1
Logical Volume on disk0s3
7673E79-4009-45F2-894F-0E99C2B7259E
Unlocked Encrypted
La partition
disk0s4 macOS Sierra supportait un
CoreStorage Chiffré exportant le
Volume Logique déverrouillé
macOS Sierra identifié comme un
disk1 (internal, virtual). Pour supprimer cette partition, il aurait fallu commencer par déconstruire le format
CoreStorage résident utilisant les blocs de cette partition par une commande spécialisée qui aurait eu la forme suivante :
Bloc de code:
diskutil coreStorage deleteLVG XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
le
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX étant l'
UUID de 32 caractères alpha-numérique du
Logical Volume Group (l'enveloppe globale du
CoreStorage) que la commande préliminaire :
aurait permis de connaître.
Un
re-démarrage du Mac aurait été absolument impératif > le
kernel n'intégrant jamais en mode "
live" la suppression d'un
Volume Virtuel disk1 (internal, virtual) comme celui d'un
CoreStorage > d'où une "représentation logique" des partitions erronée en mode "
live".
Suite à la déconstruction formelle du
CoreStorage et après re-démarrage ayant mis à jour le
kernel > tu te serais retrouvé avec le tableau de partition implifié suivant :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS El Captian 125.0 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_HFS Untitled 124.4 GB disk0s4
5: Apple_Boot Recovery HD 650.0 MB disk0s5
où tu aurais remarqué la suppression du format
CoreStorage remplacé par un format de fichiers
JHFS+ standard sur la
disk0s4 > avec suppression du
Volume Logique disk1 > et avec reformatage automatique exportant un volume
Untitled.
Alors les 2 commandes (successives) :
Bloc de code:
diskutil eraseVolume free NULL disk0s4
diskutil eraseVolume free NULL disk0s5
aurait effacé le système de fichiers des 2 partitions de queue (
Untitled n°4 &
Recovery HD n°5) sans recréer de système de fichiers (mention "
free" = "
free_space" - avec un nom de volume bidon :
NULL ou
MACHIN car sans système de fichiers > aucun volume ne monte > aucun nom de volume n'est donc pertinent > et comme cible le
device chaque fois).
Tu aurais donc obtenu le tableau de partition suivant :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS El Captian 125.0 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
où comme tu le vois
125 Go de blocs en queue de disque se seraient trouvés hors partitionnement
GUID > condition pour qu'ils soient récupérables à la partition
El Captian du dessus.
Alors par la commande :
Bloc de code:
diskutil resizeVolume disk0s2 0b
tu aurais demandé le redimensionnement de la partition bénéficiaire
disk0s2 de
El Captian avec la simple mention abrégée
0b =
0_byte signifiant : ne laisser aucun byte d'espace libre inutilisé en-dessous de la partition bénéficiaire. Ce qui t'aurait donné le tableau de partitions :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS El Captian 250.1 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
et tu n'aurais plus eu qu'à renommer à la main le volume
El Captian en
macOS Sierra pour que le nom soit en adéquation avec la chose.
Remarque 1 : le clonage du contenu du volume
macOS Sierra dans
El Captian n'exporte pas le format
CoreStorage (
Chiffré ici) encapsulant > mais seulement le système de fichiers
jhfs+ terminal inclus avec les données en relevant > donc
El Captian, contenant le Système démarrable
Sierra (clone), aurait bien été au format
JHFS+ standard.
Remarque 2 : tu n'es pas sans t'aviser d'un petit problème : la partition
Recovery HD disk0s3 est intercalée sur les blocs entre la partition bénéficiaire
El Captian disk0s2 et la bande d'espace libre de
250 Go en-dessous d'elle > comment va-t-elle être "contournée" sans suppression par les blocs libres à rajouter à la
disk0s2 ? Il n'y a aucun mystère : les blocs en terme de numérotation restent
inamovibles. C'est la partition
Recovery HD qui doit être « déplacée sur les blocs ». Comment ? Par un
clonage spécifique (le seul pris en charge par
diskutil) en créant un
duplicata tout en queue de disque (les
650 derniers Mo) > puis
suppression de l'original intercalé en
disk0s3 > ce qui fait que la bande de blocs libres de
250 Go aurait été juste
contiguë de la limite basse de la
disk0s2 El Captian > donc un "ressoudage logique" était donc possible (càd. un étirement du système de fichiers gestionnaire de la
disk0s2 à gérer
250 Go de blocs libres de plus en-dessous...
