Tu as superbement repris la suite des démarches logiques qui ont été effectuées. Il faut dire qu'il n'y a eu à aucun moment d'étape "libératoire" - le genre où : pof ! tout est réglé d'un coup.
Qu'est-ce qui a pu causer la modification de la table de partition GPT ou du TYPE de mon volume 'Macintosh HD' pour le rendre illisible ?
Eh bien ! figure-toi que je me le demande toujours. Après avoir supprimé les 2 partitions
Ubuntu de
50 Go en tout > tu as passé la commande :
Bloc de code:
diskutil resizeVolume disk0s2 0b
qui n'est pertinente que si la partition
disk0s2 porte un système de fichiers
JHFS+ classique et pas un
CoreStorage. Car dans ce cas > il faut passer une commande du type :
Bloc de code:
diskutil coreStorage resizeStack [LV-UUID] 0b
Donc ta commande était non-peritinente à cause du
CoreStorage > mais normalement elle est avortée dans ce cas-là. Est-ce qu'elle a pu susciter des effets en chaîne ? - parce que le dispositif logique : {
CoreStorage > avec volume
JHFS+ résidant sur la couche du
Volume Logique } était déjà grevé d'erreurs ? --> c'est une éventualité.
Pourquoi ensuite cette cascade d'incidents ? - je me demandais si tu n'avais pas un Mac ancien avec une nappe défaillante > mais avec un
MacBook Pro Retina 2015 qui a un SSD PCie barrette connecté directement à la Carte-Mère > ça ne peut pas être la cas.
----------
Qu'est-ce qu'a permis la réversion logique du CoreStorage ?
Tu avais activé «
FileVault» qui met en place un chiffrement protégeant l'accès au volume de l'OS. Et c'est là que les choses se compliquent --> pour rendre possible ce chiffrement > les ingénieurs de la ont inventé à l'époque de «
Lion 10.7» (OS injustement décrié) un système de stockage dit
CoreStorage. En résumé : la partition
disk0s2 est logiquement convertie au statut de
Physical Volume : magasin de stockage physique. En regard > s'
exporte un disque virtuel
Logical Volume qui est une redondance logique de l'espace du
Physical Volume. Sur l'en-tête du disque virtuel
Logical Volume > est ancré le système de fichiers
JHFS+ > qui monte donc un volume
Mactintosh HD sur l'espace logique du
Logical Volume.
Il y a donc 2 couches logiques intercalaires :
Physical Volume / Logical Volume > définies par des
headers (en-têtes) inscrits sur la partition de résidence
disk0s2. Ces deux disques virtuels sont reliés par un processus de traduction des blocs logiques de l'un dans ceux de l'autre. S'il y a un
chiffrement > les blocs logiques du
Physical Volume seuls sont
chiffrés > les blocs logiques du
Logical Volume non : ils sont la contrepartie
déchiffrée de ceux du
Physical Volume > grâce au traducteur qui emploie un algorithme de déchiffrement.
Le
Logical Volume est
verrouillé au départ par le statut chiffré du
Physical Volume qui est la base de données d'écritures. Le
déverrouillage du
Logical Volume > et son
exportation logique > ne se font jamais automatiquement (sinon, à quoi servirait le chiffrement ?) > mais par l'intermédiaire d'un gestionnaire de pré-démarrage : le «
booter » > qui affiche un écran de déverrouillage et déclenche d'exportation.
Le «
booter » doit nécessairement résider dans le volume qui monte sur une
partition accollée à celle où est inscrit le
Physical Volume du
CoreStorage = une
disk0s3 pour une
disk0s2. Mais il y a un petit problème : en
disk0s3 > doit nécessairement résider la partition de récupération sur laquelle monte le volume
Recovery HD. Qu'à cela ne tienne : le problème a été réglé par la
coexistence de 2 dossiers aux fonctions différentes dans le volume
Recovery HD : le dossier
com.apple.recovery.boot contenant le
RecoveryOS et le dossier
com.apple.Boot.R recelant le «
booter » du
CoreStorage.
Il faut bien comprendre qu'au démarrage du Mac > le
Volume Logique verrouillé n'est
jamais monté automatiquement. Donc le volume
Macintosh HD qui est son hôte est
inadressable en terme de boot. C'est donc le «
booter » du volume
Recovery HD qui réceptionne le
rôle de démarrage : l'en-tête du volume
Recovery HD est
béni (
blessed) de telle sorte que le chemin pour l'
EFI pointe sur le
boot_loader boot.efi du dossier «
booter ». Suite à cette bénédiction > le volume
Recovery HD monté à l'écran du
boot_manager (touche
alt - dans le temps du boot tous les volumes sont montés et adressables --> les démarrables sont donc affichés) est donc
monté en tant que volume de pré-démarrage du volume
Macintosh HD non monté et inaccessible. Ainsi > le volume
Recovery HD monté > est monté en
mode boot sous le
disk_label :
Macintosh HD > càd. l'
intitulé de son volume de référence (lequel n'est
pas monté).
Dommage collatéral : le chemin de boot sur l'en-tête du volume
Recovery HD ne pointe plus sur le
boot_loader boot.efi du
RecoveryOS --> le volume
Recovery HD ne peut donc
plus être affiché en tant que volume de démarrage de l'OS de secours. Solution au problème : une commande
⌘R lance directement le démarrage du
RecoveryOS dont le volume est inaffichable en tant que tel.
Le problème chez toi est que la partition du «
booter » du
CoreStorage (la
disk0s3, donc) était
séparée par une bande de blocs libres de
134 Mo de la partition
disk0s2 de résidence du
Physical Volume du
CoreStorage. Situation anormale : les 2 partitions doivent être
accollées sans espace de blocs libres. Le dossier du «
booter » (contenu dans le volume
Recovery HD) assumait des
fonctions de pré-démarrage du
CoreStorage (heureusement, encore) > mais sa partition ne semblait
pas reconnue par une commande de repartitionnement comme partition du «
booter » ayant à être
déplacée sur les blocs en concomitance de la partition de référence du
CoreStorage disk0s2.
Bref... une situation inextricable. La
désactivation de «
FileVault» a supprimé logiquement le système de stockage
CoreStorage. Donc les couches logiques :
Physical Volume et
Logical Volume ont été déconstruites > et le
système de fichiers JHFS+ s'est retrouvé inscrit sur l'en-tête brut de la partition
disk0s2 (d'où l'image : descendez, on vous demande). Par effet collatéral : le dossier du «
booter » :
com.apple.Boot.R a été
supprimé dans le volume
Recovery HD > qui est redevenu le volume exclusif du
RecoveryOS.
Il s'est trouvé dans ton cas que cette partition
Recovery HD disk0s3 à fonction désormais réduite à celle de secours > ne permettait toujours pas un re-dimensionnement de la
disk0s2 > car elle était toujours
séparée par la bande de blocs libres de
134 Mo. Bande
trop petite pour que le
système de fichiers JHFS+ de la
disk0s2 puisse être étiré afin de la récupérer. Donc : sauvegarde des 2 ressources-clés du dossier
com.apple.recovery.boot > suppression de la
disk0s3 > re-dimensionnement de la
disk0s2 > recours à
dmtest pour recréer la
disk0s3.
Par ailleurs > l'installateur d'«
El Capitan» avait créé également un
CoreStorage sur la partition
disk0s4.
CoreStorage non chiffré, lui, mais qui avait aussi son
pré-démarreur («
booter ») dans le volume de la
Recovery HD disk0s5. Lorsqu'un
CoreStorage existe > son disque virtuel
Physical Volume est identique à sa partition d'inscription =
disk0s2 ou
disk0s4. Mais le
Logical Volume qui s'exporte en regard > a le statut logique de
disque logique virtuel de second ordre > puisque c'est sur son espace-disque que se trouve monté le volume standard
Macintosh HD ou
SOS. En cette qualité de
disque virtuel > il est identifié comme un
disk1 ou un
disk2 par rapport au disque physique
disk0.
Le
kernel (noyau du Système démarré) charge ce statut de disque secondaire rapporté au
Physical Volume de la partition concernée comme à sa base de données. Il n'est pas alors possible de supprimer directement cette partition (la
disk0s4, par exemple) > parce qu'elle est la partition de résidence du
Physical Volume d'un
CoreStorage > dont le disque secondaire
Logical Volume est chargé par le kernel comme un disque de second ordre. La "
ressource" de la partition est considérée comme
occupée. Il faut
supprimer le dispositif
CoreStorage > ce qui refait du
système de fichiers JHFS+ sur l'en-tête de la partition le gestionnaire direct de la partition > et alors on peut supprimer la partition.
----------
• Comment as-tu pu accéder à ces connaissances ?
Je n'ai aucune formation informatique non plus qu'aucun métier dans l'informatique. J'ai une formation de Lettres Classiques, Philosophie et Logique Mathématique. À l'instar du dispositif du traduction qui permet la transformation des écritures chiffrées d'un
Physical Volume dans l'espace logique déchiffré du
Logical Volume d'un
CoreStorage > je procède à une transformation en continu du langage informatique dans le langage naturel et vice-versa. Jusqu'à une certaine limite > la traduction opère.
)
