turbine (ou
trubine ?)
État des lieux
Si j'isole le tableau qui décrit le partitionnement de ton disque interne de 500 Go > voici ce qui apparaît :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 350.4 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_HFS Sans titre 37.7 GB disk0s4
5: Microsoft Basic Data BOOTCAMP 111.0 GB disk0s5
Comme tu le peux le remarquer > tu as en tête de partitionnement la triplette classique d'un disque sur lequel
OS X est installé : la partition
ESP (
EFI System Partition) de 209 Mo qui est le départ régulier d'une
GPT (
GUID Partition Table) > la partition
Macintosh HD de 350 Go (chez toi) où réside
OS X > la partition
Recovery HD de 650 Mo où réside le Système de récupération.
En-dessous de cette triplette réglementaire > je constate non pas
une partition comme attendu (la partition
BOOTCAMP où réside
Windows) > mais
2 partitions - en ce sens qu'une partition
Sans titre de 37 Go est venue s'intercaler en
4è position en-dessous de la
Recovery HD et précède désormais la partition
BOOTCAMP de 111 Go de
Windows qui se trouve reléguée en
5è position dans la table
GPT.
Interprétation : manifestement, tu as
réduit la partition
Macintosh HD n°
2 de 37 Go > ce qui a permis de
créer la néo-partition
Sans titre en n°
4 en-dessous de la
Recovery HD (toujours préservée à sa place dans ce genre de manœuvres) > mais contrairement aux allégations du sieur
Bob Dobolino (avec un nom de pitre pareil : personnellement je serais méfié) le logiciel mis en œuvre sous
Windows : «
Mini Tool Partition Wizard» a été incapable d'agréer l'espace de cette partition n°
4 Sans titre à la partition
BOOTCAMP n°
5 (que cet agrandissement se puisse "par le haut" de la partition
BOOTCAMP : ça me laisse sceptique - mais passons).
♤
Intermède herméneutique
Mézalors => pourquoi mon
BOOTCAMP a-t-il le boot qui a fichu le camp ? Pour une obscure raison que je tente de remonter de son puits d'ombre :
L'espace d'un disque est logiquement distribué en
blocs (de 512 octets de 8 bits chacun) - blocs constituant une série numérique linéaire de
0 à
n.
Les blocs
0 à
32 de tout disque portant une
GPT correspondent au
secteur de boot de disque (ou :
secteur d'amorçage par le
Programme Interne du Mac ou
EFI). Mais sur le disque d'un Mac Intel > ce secteur de boot est
bicéphale (et pas
monocéphale comme on le le figure couramment) :
- les blocs 1 à 32 supportent les fichiers de la GPT proprement dite : càd. les descripteurs logiques de l'espace du disque conforme à la norme GUID. Une redondance des écritures de ces 32 premiers blocs réside toujours sur les 32 derniers blocs du disque, qui constituent le backup (sauvegarde) de la GPT. Cette table de partition GPT écrite sur les 32 premiers blocs est la table principale.
- mais sur le bloc unique absolument initial qui est le bloc 0 résident les fichiers descripteurs d'une MBR : un table Master Boot Record de type Windows. Sur les disques des PC > c'est toujours aussi sur le bloc 0 que réside la MBR ; le disque d'un Mac n'y fait pas exception et porte donc sur son bloc liminaire 0 une MBR qui précède la GPT. Cette table de partition MBR du bloc 0 est la table secondaire du disque d'un Mac (disque-Système tablé en GPT).
Ce bref aperçu donné > montrant qu'il y a toujours sur le disque d'un Mac
dualité de tables de partitions :
MBR sur le bloc
0 +
GPT sur les bloc
1-32 > il devient intéressant de scruter d'un peu plus près la table secondaire
MBR du bloc
0.
--------------------
En quoi consiste-t-elle et pourquoi la retrouve-t-on sur le disque d'un Mac (contrairement à toute attente) ?
Régulièrement parlant : la table
MBR résidant sur le bloc
0 du disque d'un Mac est une table conforme au type : "
Protective" > c'est donc une «
Protective_MBR ». Comme cet intitulé invite à le penser > sa présence avant la table
GPT a pour fonction de "
protéger" la table
GPT principale contre les atteintes logiques que des programmes non Apple (=
Windows) pourraient induire. Car pour ces programmes les descripteurs d'une
GPT ne font pas sens > ce qui pourrait amener des tentatives d'effacement ou de reformatage logique pour approprier l'espace du disque d'une manière qui fasse sens en mode
Windows.
C'est là qu'intervient la "
Protective_MBR" du bloc
0 : elle décrit d'une manière "
compréhensible en mode Windows" l'espace du disque > avec une
spécificité absolue du mode "
Protective" :
aucun sous-partitionnement de l'espace total du disque n'est représenté par les descripteurs de cette table "
Protective" > mais l'espace total du disque est représenté comme constituant une
seule et unique partition non-repartitionnable. Pour prendre une image : si le disque était comparé à la France > du point de vue
GPT on aurait une carte géographique montrant le découpage de grandes régions administratives > du point de vue de la "
Protective_MBR" on aurait une carte monolithique montrant l'espace national impartagé de l'État Français.
--------------------
Que se passe-t-il alors lorsqu'il s'agit d'installer un OS non Apple en alternative d'
OS X sur une partition du disque d'un Mac ? Il convient de
modifier le statut de la
MBR du bloc
0 pour que ses descripteurs représentent, dans le mode
MBR, plusieurs
partitions pré-constituées dans la
GPT principale - ce, afin que l'installateur de
Windows puisse "voir" la partition dédiée à
Windows comme une partition localisée (de tel bloc à tel bloc), càd. en avoir une représentation logique selon le mode
MBR. Sans quoi, il ne pourrait pas cibler l'espace d'installation de
Windows de manière congruente avec le partitionnement
GPT.
La "
Protective_MBR" du bloc
0 est donc transformée en un autre mode de
MBR : une "
Hybrid_MBR" dans laquelle se trouve représentées
au plus 3 partitions du disque. Ces partitions ne sont absolument
pas créées en mode
MBR > mais "
échoées" (si je puis dire) à partir de
partitions pré-définies dans la
GPT principale. Il s'agit donc d'une
redondance logique : les
mêmes partitions prédéfinies dans la
GPT se trouvent
représentées en écho en mode
MBR, ce dans leurs exactes limites de blocs.
Lors de la constitution de cet "
écho_MBR" des partitions
GPT dans la "
Hybrid_MBR" > un
boot_flag (indicateur de partition démarrable) se trouve apposé à chacune > ce qui fait en dernière instance que la partition d'accueil de
Windows est vue comme démarrable.
♧
Interprétation du problème
Si j'interromps ici mon effort herméneutique > on peut dire en résumé que l'intercalement d'une partition n°
4 Sans titre de 37 Go dans la
GPT a ruiné la mise en correspondance des partitions clés dans la table "
Hybrid_MBR".
Supposons que dans cette
Hybrid_MBR on avait : la partition
GPT1=HMBR1 (
EFI) > la partition
GPT2=HMBR2 (
Macintosh HD) > la partition
GPT4=HMBR3 (
BOOTCAMP dans le dispositif primaire, où
BOOTCAMP = GPT4 interprétée par la
Hybrid_MBR comme
HMBR3).
Le décalement
GPT dû à l'intercalaire
Sans titre =
GPT4, repoussant
BOOTCAMP en
GPT5 > fait que, dans la
Hybrid_MBR qui n'a absolument pas été mise-à-jour en écho > l'ancienne correspondance logique
GPT4=HMBR3 demeure : c'est donc la partition actuellement
Sans titre n°
4 dans la
GPT qui est représentée comme la n°
3 de la
HMBR à la place de la
BOOTCAMP décalée en n°
4. Exit donc
BOOTCAMP qui n'est plus "vu" comme un volume démarrable.
♡
Opération de repartitionnement
Plutôt que de laisser en place la partition inutile
Sans titre de 37 Mo en position
GPT4 comme l'avait fait l'intervenant expert du fil des discussions Apple (parce que l'énergumène créateur du fil avait créé un
Fusion Drive bloquant après sa boulette, comme pour embrouiller encore plus la situation) > je te propose,
turbine, de la
supprimer afin d'en réallouer l'espace à la partition d'origine la
GPT n°2 Macintosh HD. Ce qui est parfaitement possible chez toi, vu la parfaite limpidité du tableau.
Tu relances donc le «
Terminal» et :
- a) fais un copier-coller de la commande
suppressive de la partition
GPT n°4 Sans titre :
Bloc de code:
diskutil eraseVolume free NULL disk0s4
et ↩︎ [si jamais, étant sous une version ancienne d'
OS X, l'utilitaire
diskutil te retournait un message du style :
Bloc de code:
Error: 2: POSIX reports: No such file or directory
> sache que c'est un bogue qui prétend que la cible ne se trouve pas - pour la bonne raison que la commande vient d'effacer cette partition !]. Tu peux repasser après la commande un :
qui devrait te montrer que la partition n°
4 Sans titre n'est plus listée sur le disque.
- b) fais alors un copier-coller de la commande qui
redimensionne la partition
GPT n°2 Macintosh HD en lui faisant récupérer l'espace libéré de l'ancienne
Sans titre :
Bloc de code:
diskutil resizeVolume disk0s2 0b
> suite à quoi le tableau du nouveau partitionnement devrait t'être retourné, qui devrait ressembler à ceci :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 388.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Microsoft Basic Data BOOTCAMP 111.0 GB disk0s4
=> comme tu peux le voir, la partition
BOOTCAMP a récupéré sa position
GPT4 initiale > je te propose de re-démarrer ton Mac avec "
alt" > histoire de vérifier si les conjectures logiques les plus élémentaires sont respectées par l'informatique : normalement, il devrait y avoir de nouveau congruence entre la distribution des partitions
GPT et leur écho représentatif dans la
Hybrid_MBR du bloc
0, soit pour la partition qui nous intéresse :
BOOTCAMP GPT4=HMBR3.
Si l'ordre des choses était aussi limpide qu'on le souhaite toujours (en imagination) > la partition
BOOTCAMP devrait être "vue" de nouveau comme démarrable par le
boot_manager de l'
EFI...
Si ce n'est pas le cas (comme on peut toujours le craindre en informatique) > il faudra recourir à l'utilitaire
gdisk de
Roderick Smith pour mettre à jour la table
Hybrid_MBR du bloc
0 de ton disque.
♢
