Ce volume
Recovery HD est celui que tu as
cloné d'après l'original sur lequel tu es démarrée.
La présence en lui, en plus du dossier
com.apple.recovery.boot (listé à la fin) contenant le
RecoveryOS, d'un dossier
com.apple.boot.P --> montre que tu avais un système de stockage
CoreStorage, sans doute
Chiffré, sur la ci-devant partition de l'OS --> car c'est là le dossier
booter de ce dispositif
CoreStorage qui a été démantelé.
À présent > quand je contemple la distribution des blocs de ton disque > j'aperçois clairement que ton problème
diffère de celui de
galjb car celle-ci avait la bande de blocs libres principale
intercalée au départ entre le volume de tête rétréci et la partition de secours
Recovery HD qui était en queue de disque.
En ce qui te concerne > les
962105687 blocs logiques libres (=
458.7 Go) se trouvent absolument en
queue de disque et non intercalés.
Cela me fait conjecturer que la partition
Recovery HD originale est toujours restée
au contact de la partition (rétrécie) de l'OS au lieu d'en être disjointe. Ce doit donc actuellement bien être la
disk0s3 dont le volume est indémontable car tu es démarrée dessus > partition
disk0s3 qui doit correspondre en terme de distribution de blocs logiques à la
3 GPT PART.
S'il en est ainsi, lorsque tu as re-dimensionné la partition de tête déjà bien maigre pour créer un
clone de la
Recovery HD existante > c'est
en-dessous de cette dernière que tu l'as créée > càd. en tant que l'actuelle partition
disk0s4 qui doit correspondre à la
4 GPT PART.
S'il en est comme je viens de le conjecturer > alors la résolution du problème actuel est
simple (et l'était même au départ sans que tu aies besoin de répéter la procédure sophistiquée qui s'appliquait au cas de
galjb).
Tu n'as qu'à enchaîner les 3 commandes (
alea jacta est ! ) :
Bloc de code:
diskutil umount force disk0s4
diskutil erasevolume free null disk0s4
diskutil resizeVolume disk0s2 0b
=> à toi de dire ce qui résulte de cette opération --> en postant le retour d'affichage et le tableau d'une nouvelle commande :
