Jean &
BeRZaN
Je m'immisce dans ce fil, car il atteste d'un « paradoxe » dont ne peut manquer de se délecter un amateur d'absurdités à la
Lewis Carroll
Le paradoxe de la « présence d'une absence » (une partition BOOTCAMP absente, qui continue de se présenter comme une possibilité de démarrage). Paradoxe on ne peut plus de saison, en ce temps de
Pentecôte qui commémore la « descente du Saint-Esprit » : car ne s'agit-il pas là,
in nuce, de la Présentation de l'Absent par excellence ? Qu'une Absence puisse donc faire Acte de Présence dans un Mac - voilà qui aurait sans doute ravi
Henri Bergson, lequel ne cessait d'en appeler à l'intervention d'un « Supplément d'Âme » dans l'univers des « Machines »...
Tout lecteur de ce préambule aura tout de suite saisi que ce qui se « présente » ici, est une version dominicale de
macomaniac « absente » du sérieux des jours laborieux - autant dire d'un qui profite de l'occasion pour faire de l'« esprit »...
--------------------
Ce n'est pas la peine,
BeRZaN, que tu t'évertues à passer des commandes de re-dimensionnement de la partition majeure
/dev/disk0s2 du disque de ton Mac, pour la raison qu'il n'existe aucun espace libre suffisant en queue de disque (la partition de récupération intercalaire «
Recovery HD» ne jouant pas le rôle d'obstacle à sa récupération éventuelle) qui permettrait cette opération.
Tout l'espace de l'ancienne partition
BOOTCAMP a manifestement été récupéré par la partition de l'OS
Macintosh HD et il n'y a plus de blocs libres disponibles pour l'augmenter. C'est le sens des messages retournés :
Bloc de code:
Error: -69742: The requested size change for the target disk or a related disk is too small; please try a different disk or partition, or make a larger change
aussi bien lorsque le système de fichiers du
Macintosh HD était hébergé dans un format
CoreStorage, qu'actuellement qu'il a récupéré le format standard
JHFS+.
Tu peux le vérifier en faisant un copier-coller de la commande :
et ↩︎ (tu presses la touche "Entrée" du clavier pour activer la commande) --> 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 ↩︎ --> cette commande appelant l'utilitaire de gestion des
tables de partition GUID gpt, avec le verbe
show ("montrer") sur la cible du
disk0 ou premier disque (disque interne de ton Mac) va retourner le tableau de l'allocation des blocs de ton disque => peux-tu poster ce tableau en copier-coller ici ? Il sera facile de vérifier qu'il n'existe aucune bande de blocs libres suffisante (à part une éventuelle bande tampon, comme cela arrive régulièrement) en-dessous des
GPT PART 2 (
Macintosh HD) et
3 (
Recovery HD) et avant les 32 derniers blocs qui recèlent le backup de la table
GPT des 32 premiers blocs.
--------------------
Il n'existe donc aucune autre partition que celles que révèle la commande
diskutil list (3 au total, avec l'
ESP ou
EFI System Partition n°1 de tête), et aucune bande d'espace libre qui correspondrait à l'ancienne partition
BOOTCAMP.
S'il n'existe aucune autre partition que ces 3 citées, cela revient à dire qu'aucun secteur de blocs du disque en-dehors d'elles n'est actuellement géré par un système de fichiers, ce qui automatiquement « transfigure » cet espace en partition, càd. le convertit en secteur reconnu de la table de partition
GPT (
GUID Partition Table). Qui dit absence de système de fichiers, dit absence radicale d'écritures sur les blocs correspondants susceptibles d'être interprétées comme des
DATA logiques (des données "signifiantes" logiquement). Parmi lesquelles aucun
boot_loader .efi (fichier démarreur d'un OS) correspondant à un Système
Windows lançable.
Or, lorsqu'un Mac est démarré avec la touche "
alt", c'est la « présence » ou l'« absence » de tels fichiers
boot_loaders sur les partitions existantes que le logiciel de scan de l'
EFI :
DiskManager reconnaît, lors de son scan préliminaire des partitions - ce qui lui permet de n'afficher que les partitions porteuses d'un
boot_loader .efi identifiées comme possiblement démarrables (et d'exclure toutes les partitions sur lesquelles un tel
boot_loader est absent, càd. les partitions de simple stockage).
Par une absurdité magnifique, ne voilà-t-il pas que le
DiskManager identifie, par la présence d'un
boot_loader .efi, une partition
BOOTCAMP, en l'absence de toute partition
BOOTCAMP effective, càd. de système de fichiers gestionnaire d'une bande de blocs, et en l'absence donc forcément de tout
boot_loader .efi affecté au démarrage d'un Système
Windows, puisqu'en l'absence de système de fichiers, aucune écriture sur des blocs n'est plus interprétable comme une
DATA = un
boot_loader ici...
--------------------
Toute absurdité donne lieu à spéculation, càd. à développement de « conjectures de l'esprit » marquées par l'imagination. En voici un échantillonnage :
- a) se pourrait-il qu'une adresse résiduelle, dans la mémoire
NVRAM de la Carte-Mère, continue de pointer, sur une partition disparue dont l'
UUID aurait été conservé, à un
boot_loader disparu en tant que donnée logique interprétable ? Et que cette résilience d'une adresse, sans destinataire réel, suscite cette « présence d'une absence » dont je me délecte ?
Voici une façon de s'en assurer => passe dans le «
Terminal» la commande :
qui va te retourner le tableau des tous les paramètres destinés à l'
EFI de cette mémoire d'instructions de boot => peux-tu malgré sa longueur et son caractère abstrus en faire un copier-coller ici ? Il devrait sauter aux yeux si, à la rubrique
efi-boot-device, une adresse « fantôme » est ou non toujours mentionnée.
- b) se pourrait-il que la Table de Partition secondaire de type
MBR qui occupe toujours le
secteur de boot (ou
secteur 0 = le bloc initial) du disque d'un Mac, au lieu d'être une
PMBR =
Protective MBR régulière (Table de Partition "mono-secteur", mappant tous les blocs du disque en une seule partition "default" et ayant pour unique fonction de protéger la table
GPT maîtresse portée par les 32 blocs suivants contre l'instruction de Systèmes d'exploitation non-Apple), soit une
HMBR =
Hybrid MBR (Table de Parition "multi-secteurs", mappant les blocs du disque en plusieurs partitions et offrant une "carte" de boot pour un Système d'exploitation non-Apple) ?
Hybrid MBR qui continuerait d'être lue (au démarrage ou au scan) comme désignatrice d'une partition
MBR BOOTCAMP, laquelle n'existe plus dans les faits, mais continuerait d'être "représentée" formellement ?
Il sera très facile de s'en assurer par l'en-tête du tableau retourné par la commande
sudo gpt show /dev/disk0 précédente...
- c) se pourrait-il que dans le Volume de ton OS Macintosh HD, tu aies conservé des ressources d'installation de
Windows, incluant un
boot_loader .efi, ce qui occasionnerait une "double-interpétation" de cette partition : d'une part, comme une
Macintosh HD régulière, d'autre part comme une pseudo
Windows prétendûment démarrable ?
À toi d'inspecter les données de ton volume
Macintosh HD, pour vérifier si c'est le cas...
- d) [FACTEUR X] autant dire un
Malin Génie dans la Machine [je m'avise ici d'une possibilité : que l'
ESP ou partition
EFI d'en-tête de la Table de Partition
GPT aurait été ré-écrite dans ses contenus, pour donner une «
EFI MBR » porteuse d'exécutables, dont éventuellement un
boot_loader dédié à
Windows ? - conjecture à suivre...]
[NB. Le fait qu'un disque de démarrage intitulé «Récupération 10.11.3» soit apparu après ta commande de réversion du format CoreStorage est normal : aussi longtemps qu'un format CoreStorage encapsule, en effet, le système de fichiers d'OS X, la partition de récupération «Recovery HD» ne peut pas être affichée à l'écran des disques de démarrage obtenu par la touche "alt". C'est encore une question de boot_loader - mais permets-moi de ne pas ici en développer le mécanisme explicatif...]
