Je te propose une petite rétrospective des opérations d'hier - qui se sont toutes soldées par des échecs.
Le problème était (et est toujours) constitué par la partition n°
3 de ton disque -->
Bloc de code:
#: TYPE NAME SIZE IDENTIFIER
3: Apple_Boot Recovery HD 149.8 GB disk0s3
Cette ligne décrit la partition de secours du disque dont le volume s'intitule
Recovery HD. Tu observes qu'au lieu des
650 Mo habituels > elle fait actuellement
149,8 Go --> un accident logique lui a fait récupérer l'espace libéré par la suppression de la partition
BOOTCAMP.
Tu observes aussi que le
TYPE de cette partition est désigné par "
Apple_Boot" qui peut se traduire ainsi : "
partition Apple de pré-démarrage". C'est ainsi que cette partition est enregistrée dans la table de partition
GUID de l'en-tête du disque qui gère les partitions. Ce
TYPE "
Apple_Boot" accollé à une partition a un effet collatéral : il
verrouille en taille cette partition > au sens où elle ne peut pas être re-partitionnée - même si, comme c'est le cas ici, le
système de fichiers contenu dans cette partition est d'un format
jhfs+ (Mac os étendu journalisé) qui permet en soi une modification de taille de la partition de résidence.
C'est la raison exacte pour laquelle j'ai eu l'idée de
changer le
TYPE de la partition n°
3 de "
Apple_Boot" (= rigide) à "
Apple_HFS" (= plastique). Ce changement de type n'affecte en aucune manière le contenu de la partition : son système de fichiers n'est pas altéré et continue de générer le même volume
Recovery HD. Une fois le type de la partition changé > il devenait possible, en effet, de
re-dimensionner cette partition par une commande --> de manière à la ramener aux
650 Mo de départ > en laissant les
149,2 Go libérés à l'état d'
espace libre.
Cette opération faite > il suffisait de rechanger à rebours le
TYPE de la partition n°
3 de "
Apple_HFS" à "
Apple_Boot" --> et tu avais à nouveau une partition de secours à la bonne taille, système de fichiers et volume
Recovery HD laissés intacts. Il était alors possible de passer la commande que je t'avais donnée au tout début :
Bloc de code:
diskutil resizeVolume disk0s2 0b
et la partition n°
2 de l'OS aurait récupéré sans problème les
149,2 Go d'espace libre. Problème résolu.
Ça --> c'était la
théorie. Je me suis amusé une série de fois pendant que tu tentais ton démarrage par internet à la répéter sur le second disque de mon Mac (ou réside le clone
jhfs+ de mon OS
High Sierra - flanqué d'une partition
Recovery HD) : la manœuvre opère impeccablement (et ne prend que quelques secondes à être exécutée)... à condition que les commandes de
changement de
TYPE de la partition soient
honorées. Chez moi > la commande
asr fonctionnait sans aucune difficulté. Comme la commande
gdisk un peu plus complexe à mettre en œuvre.
Dans la
pratique --> chez toi
rien n'a fonctionné. La commande
asr a buté sur un déni d'autorisation (malgré le
sudo) et la commande
gdisk n'a pas pu ouvrir l'en-tête du disque pour lire les tables de partition. Je me demande encore ce matin pour quelle raison exactement. Je ne veux pas trop m'avancer en conjectures.
Étant donné l'échec de l'approche d'hier (
changer le
TYPE de la partition de secours > la
re-dimensionner >
restaurer son
TYPE original >
récupérer l'espace-disque) --> j'ai eu l'idée d'une démarche alternative moins complexe. Tu n'auras qu'à faire signe dans ce fil et je te la détaillerai.