M
Membre supprimé 1060554
Invité
Comme attesté par ce tableau de diskutil -->
Mais comme tu avais précédemment activé FileVault > ce qui avait généré un système de stockage CoreStorage requis pour le chiffrement > et que le CoreStorage actuel est attesté « Unencrypted » (non chiffré) > j'en déduis ceci -->
Je conjecture que c'est ce qui arrive ici --> l'UUID = C4EC0060-013E-461D-B172-21AE0959F84B correspond bien au Logical Volume du CoreStorage qui... existait avant le processus de déchiffrement qui a fait disparaître le CoreStorage de la partition. Donc cet UUID n'a de validité qu'en terme de résilience dans la mémoire du kernel > mais ne correspond plus à la réalité de la configuration actuelle de la partition disk0s2 où l'on a actuellement affaire à un format jhfs+ standard.
La résolution de ce paradoxe consiste en un re-démarrage > qui va forcer une mise-à-jour du chargement par le kernel de la configuration actuelle de la partition. Si tu as bien un format jhfs+ standard sur la partition > cela va se voir comme le nez sur la figure si tu repasses un :
Il se pourrait d'ailleurs que la partition de secours disk0s3 contenant l'OS de secours dans son volume Recovery HD > ait été supprimée du disque avec la déconstruction du CoreStorage Chiffré > parce qu'elle jouait aussi (de manière absolument prioritaire) le rôle de « booter » (partition auxiliaire de pré-démarrage) du Volume Logique du CoreStorage. Càd. de condition logicielle de son exportation en tant que disque virtuel. Elle est donc dans ce cas logiciellement solidaire du CoreStorage > ce qui fait que la suppression du CoreStorage implique la suppression de cette partition auxiliaire à fonction de « booter ».
Tu devrais donc te retrouver sans partition de secours disk0s3 qui aurait été supprimée > et comme l'espace libre en-dessous de 49 Go se sera trouvé à portée directe du système de fichiers jhfs+ de la partition principale --> alors le système de fichiers aura automatiquement récupéré tout l'espace libre à la partition disk0s2. Je fais donc le pari qu'après re-démarrage --> tu vas avoir la configuration-disque suivante :
Bloc de code:
Logical Volume on disk0s2
C4EC0060-013E-461D-B172-21AE0959F84B- l'UUID est bien celui d'un Logical Volume CoreStorage exporté à partir de la partition disk0s2 du disque.
Mais comme tu avais précédemment activé FileVault > ce qui avait généré un système de stockage CoreStorage requis pour le chiffrement > et que le CoreStorage actuel est attesté « Unencrypted » (non chiffré) > j'en déduis ceci -->
- le déchiffrement a été exécuté > ce qui régulièrement déconstruit le système de stockage CoreStorage impliqué et ramène la partition disk0s2 au format Apple_HFS+ standard (sans perte pour le volume Macintosh HD). C'est ce qui a dû se passer mais...
- ... mais c'est le kernel du Système démarré qui prend entièrement en charge la configuration des partitions et les volumes qui s'en exportent pour les monter. Or dans le cas de certaines modifications "live" de configuration --> le kernel ne se met pas à jour de la re-définition d'une partition > mais continue de charger la configuration antérieure. C'est un phénomène de résilience dans la mémoire du kernel.
Je conjecture que c'est ce qui arrive ici --> l'UUID = C4EC0060-013E-461D-B172-21AE0959F84B correspond bien au Logical Volume du CoreStorage qui... existait avant le processus de déchiffrement qui a fait disparaître le CoreStorage de la partition. Donc cet UUID n'a de validité qu'en terme de résilience dans la mémoire du kernel > mais ne correspond plus à la réalité de la configuration actuelle de la partition disk0s2 où l'on a actuellement affaire à un format jhfs+ standard.
La résolution de ce paradoxe consiste en un re-démarrage > qui va forcer une mise-à-jour du chargement par le kernel de la configuration actuelle de la partition. Si tu as bien un format jhfs+ standard sur la partition > cela va se voir comme le nez sur la figure si tu repasses un :
Bloc de code:
diskutil list- et postes le tableau mis-à-jour.
Il se pourrait d'ailleurs que la partition de secours disk0s3 contenant l'OS de secours dans son volume Recovery HD > ait été supprimée du disque avec la déconstruction du CoreStorage Chiffré > parce qu'elle jouait aussi (de manière absolument prioritaire) le rôle de « booter » (partition auxiliaire de pré-démarrage) du Volume Logique du CoreStorage. Càd. de condition logicielle de son exportation en tant que disque virtuel. Elle est donc dans ce cas logiciellement solidaire du CoreStorage > ce qui fait que la suppression du CoreStorage implique la suppression de cette partition auxiliaire à fonction de « booter ».
Tu devrais donc te retrouver sans partition de secours disk0s3 qui aurait été supprimée > et comme l'espace libre en-dessous de 49 Go se sera trouvé à portée directe du système de fichiers jhfs+ de la partition principale --> alors le système de fichiers aura automatiquement récupéré tout l'espace libre à la partition disk0s2. Je fais donc le pari qu'après re-démarrage --> tu vas avoir la configuration-disque suivante :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 121.1 GB disk0s2
