les (dominicaux) matinaux remontent au créneau
Juste en-dessous de la partition
Macintosh HD en
disk0s2 > il y a la partition de récupération
Recovery HD en
disk0s3. Lorsque la commande de re-dimensionnement de
disk0s2 est lancée, le message d'erreur :
Bloc de code:
Resizing
Error: -5341: MediaKit reports partition (map) too small
revient à dire qu'il y a eu tentative d'extension de la partition
disk0s2 vers le bas avec butée immédiate sur la limite de départ de la partition
Recovery HD disk0s3. Espace libre disponible entre la
fin de
disk0s2 et le
départ de
disk0s3 =
0 bloc > l'espace libre récupérable est « trop petit » (car égale à zéro).
Lorsqu'il y avait encore un
CoreStorage Chiffré sur cette partition
disk0s2 Macintosh HD > une tentative de re-dimensionnement via le «
Terminal» avait retourné le message d'erreur suivant :
Bloc de code:
Started CoreStorage operation
Error: -69722: You can't perform this resize unless it has a booter (target partition is probably too small)
= la condition pour re-dimensionner le
CoreStorage étant qu'il «
possède un booter » (ce qui manifestement n'est pas le cas ici).
Lorsqu'un format
CoreStorage existe sur la partition
disk0s2 d'
OS X > une
dépendance de boot se crée avec la partition
disk0s3 Recovery HD > telle que le
démarreur du Système
Recovery de cette partition (le
boot_loader : boot.efi) devient le «
booter » direct du Système
OS X de la partition
CoreStorage. Le
boot_loader : boot.efi de la partition
Recovery HD n'est donc plus "vu" comme
démarreur du Système de la récupération > mais "vu" comme
booter du
Système OS X. En conséquence : si l'on démarre avec "
alt" > un volume indépendant =
Récupération 10.x n'est
plus affiché, car le
démarreur de cette partition n'est plus identifié comme un
boot_loader Recovery > mais comme un
booter CoreStorage. C'est uniquement la commande
⌘R qui est capable de lancer en mode direct un démarrage sur un système
Recovery.
Cet argumentaire on ne peut plus abstrus me conduit à la conjecture suivante : un
problème était signalé relativement à la partition
Recovery HD disk0s3 dont le
boot_loader : boot.efi ne tenait pas son rôle de «
booter » du
CoreStorage. Une fois le
CoreStorage déconstruit (via le
déchiffrement) > l'échec de re-dimensionnement de la partition
disk0s2 Macintosh HD (dont le système de fichiers
JHFS+ est 36 fois vérifié "sans erreur") sous prétexte qu'il n'y a
pas d'espace libre disponible "en-dessous" de cette partition > fait ressortir encore un
problème touchant la
Recovery HD disk0s3.
Parce qu'en conditions régulières, la présence d'une
Recovery HD intercalée entre la partition bénéficiaire
disk0s2 et une
bande d'espace libre en queue de disque ne constitue pas un
obstacle à la récupération de cet espace libre. L'utilitaire
diskutil appelé par la commande a été rendu capable de "
mettre à jour l'emplacement de la Recovery HD sur les blocs" de manière à permettre à la partition
disk0s2 de récupérer l'espace libre. Je me figure que
diskutil génère un
clone de la partition
Recovery HD de
650 Mo tout en
queue de disque >
supprime la partition originale
disk0s3 dont les blocs sont virés à du
free_space > ce qui fait que la
bande d'espace libre existe désormais en
contiguïté du bas de la partition
disk0s2 > ce qui permet l'
extension de cette dernière à tout cet espace libre jusqu'à la limite de la partition
Recovery HD clonée en queue de disque.
Je présume qu'en cas de
corruption de la
Recovery HD > celle-ci est
inclonable par
diskutil en queue de disque > ce qui empêche par suite la
suppression de l'original situé en
disk0s3 > par suite l'existence de la partition de récupération à
toucher la limite inférieure de la partition
disk0s2 Macintosh HD constitue une espèce de "mur logique" infranchissable pour un redimensionnement. La commande
échoue > parce que la
Recovery HD ne peut pas être "poussée en queue de disque" > donc
aucun espace libre n'est disponible, puisque la
fin de la
disk0s2 touche le
départ de la
disk0s3 inamovible.
Tu vas trouver que tout ça, c'est des ratiocinations d'« abstracteur de quintessence » héritier de la scolastique (de mon côté, je trouve fascinant que l'informatique puisse donner matière à pareils exercices spéculatifs). Mais ces « imaginations intellectuelles » ont des
implications logiques directes : les
40 Go de blocs manquant à l'appel doivent forcément exister quelque part >
logiquement en-dessous de la
Recovery HD verrouillée qui empêche leur récupération.
Si tu passes la commande :
et ↩︎ --> une demande de
password s'affiche (commande
sudo) --> tape ton mot-de-passe
admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ => le tableau de la distribution des blocs sur ton disque va être retourné => peux-tu le poster ici ? - histoire de voir si une bande de
40 Go de blocs libres n'est pas située
en-dessous de la
3 GPT part Recovery HD.
=> si c'était le cas - j'ai à l'idée comment débloquer la situation...
