Spéculations dominicales
Aaah ! Et moi qui ne lis
jamais de mon propre mouvement aucune littérature informatique - me voici largement approvisionné « par l'effet d'une cause extérieure » (comme eût dit plaisamment
Spinoza) grâce aux liens postés par
cheb dans ce fil et conduisant à des articles toujours stimulants pour un esprit spéculatif
--------------------
À la lecture de l'article posté par
Mack (lien du message
#34), je ne suis pas sûr que tes problèmes d'installation de
Windows soient occasionnés par la «
GPT error » qu'il signale. Ma lecture récente de la page consacrée par
Roderick Smith au concept de "
Hybrid MBR" me fait douter, de surcroît, de la pertinence de son interprétation par
Mack.
Mack semble interpréter le concept de "
Hybrid MBR" comme si la
Table de Partition GPT (
GUID Partition Table) s'en trouvait affectée intrinsèquement en même temps que la
Table de Partition "Protective MBR" qui la double par défaut sur le disque démarrable d'un Mac --> on n'aurait donc plus qu'
une seule Table de Partition offrant un "mélange" des traits des 2 espèces existant préalablement : l'espèce "
GPT" et l'espèce "
Protective MBR". Ce n'est pas la notion que j'ai tirée de la lecture de
Roderick Smith. Mais j'ai formé l'idée que la Table
GPT primaire & maîtresse demeure toujours une carte logique séparée inscrite sur le
secteur 0 du disque ; alors que l'hybridation ne concerne que la Table "
Protective MBR" inaugurale, qui se trouve convertie en "
Hybrid MBR" par le fait qu'au lieu d'indexer les blocs du disque en mode "mono-partition" selon sa caractéristique première, elle les indexe en mode "multi-partitions" dont chacune est une répétition de partitions pré-existant dans la Table
GPT à l'intérieur de la "cartographie"
MBR. C'est donc la Table secondaire "
Protective MBR", existant toujours en parallèle de la table
GPT primaire, qui se trouve "
hybridée", en répercutant des instructions de partitionnement à partir du modèle de la table
GPT.
Je note que le problème évoqué par
Mack semble survenir exclusivement lors d'une tentative d'installation de «
Windows 8 » (alors que, pour ta part, tu cherches à installer «
Windows 7 ») et voici ce que ce cas de figure me donne à penser : tout se passe comme si l'installateur de cet OS plus récent était doté de la capacité de se référer directement à la
Table de Partition GPT du disque d'un Mac, afin de l'utiliser comme source pour "
hybrider" la carte de partition "
Protective MBR" qui en constitue la doublure par défaut et en faire la carte de partition de référence pour un émulateur de
BIOS en charge de démarrer
Windows. Tandis que l'«
Assistant BootCamp», de son côté, commence par effectuer ce travail, en convertissant à l'avance la "
Protective MBR" en "
Hybrid MBR". L'installateur de
Windows serait donc d'entrée confronté à cette table "
Hybrid MBR" toute faite neutralisant sa capacité à se référer à la table
GPT et il râlerait. En somme : sous «
Windows 8 », l'installateur veut faire le travail de conversion "
Protective MBR => Hybrid MBR" lui-même par référence directe à la Table
GPT maîtresse, alors que l'«
Assistant BootCamp» continue "
à l'ancienne" d'opérer cette conversion au préalable - ce qui bloquerait l'instruction de l'installateur sous «
Windows 8 ».
La solution de
Mack consiste à utiliser le programme
gdisk de
Roderick Smith (qui n'est pas un
executable UNIX fourni nativement avec
OS X mais qu'il faut installer en sus) afin de supprimer la table
Hybrid MBR créée par l'«
Assistant BootCamp» et recréer une table secondaire
Protective MBR par défaut. Cela fait, l'installateur de «
Windows 8 » retrouverait ses marques en étant capable de faire ce travail de conversion "
Protective MBR => Hybrid MBR" lui-même par référence à la table de partition
GUID primaire. "
Chinois" n'est-ce pas ? - comme il se disait après l'obsolescence du terme "
Byzantin"...
--------------------
Par contre, comme tu cherches à installer «
Windows 7 », je n'ai pas l'impression que ce soit cette "
GPT error" spécifique de «
Windows 8 » que tu rencontres. Non
(mais je peux errer dans mon raisonnement - ne me servant, dans ces abtruses matières logiques, que du « bon sens» - « également partagé en tous les hommes » selon Descartes et n'ayant absolument aucune formation technique en informatique. Je m'appuie, nonobstant, sur l'idée spinoziste d'une "identité fondamentale de tous les processus de l'être" <«l'ordre et la connexion des idées sont les mêmes que l'ordre et la connexion des choses»>, principe d'identité qui implique la possibilité de transposer a priori de ce que l'on connaît à ce que l'on ne connaît pas et des domaines que l'on conçoit aux domaines que l'on ne conçoit pas). Car la "
GPT error" m'apparaît comme un conflit de préséance "politique" entre l'«
Assistant BootCamp» et l'«
Installateur de Windows 8» - tandis qu'il me semble que ton problème émane d'une autre cause : l'incapacité de l'«
Assistant BootCamp» à gérer une partition au-delà de la
limite des
2 To sur un HDD. Parce qu'une partition qu'on lui désigne comme destination d'installation de
Windows au-delà de la
limite des
2 To ne relève pas a priori de la cartographie de la table secondaire "
Protective MBR", dont la "mono-partition" ne sectorise les blocs du disque que jusqu'à une
limite de
2 To, tous les blocs existant au-delà demeurant au statut d'«
espace libre » non reconnu par elle. Lorsque l'«
Assistant BootCamp» tente donc, par référence à cette partition définie dans la
Table de Partition GUID primaire, de repartitionner le modèle de la "
Protective MBR" de départ afin qu'un "écho logique" de la partition
GPT soit créé dans une "
Hybrid MBR", il se heurte au fait que l'espace de cette partition de référence est "hors-limite" de la "
Protective MBR" d'entrée. Il ne peut donc pas créer une partition "
Hybrid MBR" d'un format déterminé, parce que l'espace impliqué échappe à l'extension logique d'une table
MBR.
Je conjecture que si tu lançais l'installation de
Windows 7 à destination d'une partition en-deçà de la
limite des
2 To sur ton HDD, tu parviendrais à tes fins. Mais le problème est que, dans le cadre d'un
Fusion Drive, la partition du HDD consacrée au
CoreStorage se trouve par là fortement réduite en taille --> si tu veux consacrer un espace de 500 Go à
Windows, et si cet espace de partition doit rester situé en-deçà de la
limite des
2 To, le calcul est simple : tu ne peux consacrer au
Fusion Drive qu'une partition de 2 To - 500 Go = 1,5 To maximum du HDD. Restera, en-dessous de la partition dédiée à
Windows, un espace inemployé de 3 To (taille du HDD total) - 2 To = 1 To, ce qui est plutôt "contre-productif" dans une optique "
Fusion Drive".
--------------------
Ce qui à la fois me stimule et de déconfit, c'est le contre-exemple attesté par
zeltron (et il ne doit pas être le seul dans ce cas : toi-même, tu parais avoir bénéficié un temps d'une telle installation qui marchait) : l'installation d'un
Windows bootable sur une partition située au-delà des la
limite des
2 To sur un HDD de 3 To, quoique
théoriquement impossible, est
pratiquement réalisable cependant. Càd. que c'est
possible empiriquement, tout en restant
inintelligible rationnellement. Voici en effet le tableau de partitionnement du HDD de
zeltron (qui a lui aussi un
Fusion Drive) :
Bloc de code:
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage 2.8 TB disk1s2
3: Apple_Boot Recovery HD 650.1 MB disk1s3
4: Microsoft Basic Data BOOTCAMP 197.8 GB disk1s4
5: DE94BBA4-06D1-4D40-A16A-BFD50179D6AC 471.9 MB disk1s5
--> je relève que, sur son disque de 3 To, 209.7 MB (
EFI System Partition) + 2.8 TB (partition
CoreStorage portant le
Physical Volume n° 2 du
Fusion Drive) + 650.1 MB (partition de récupération «
Recovery HD») précèdent la partition
4: Microsoft Basic Data BOOTCAMP 197.8 GB disk1s4 où est installé un
Windows bootable, ce qui fait qu'elle est située à partir d'un peu plus de 2,5 To sur le disque. Hors champ de reconnaissance, donc, a priori de la table "
Protective MBR" et par transitivité de sa conversion en "
Hybrid MBR".
Je note que cette partition n'est pas absolument la dernière, mais qu'elle est suivie d'une micro-partition de 471 Mo manifestement connexe à la précédente sans que je sache son rôle exact ni si sa création a précédé ou suivi celle de
BOOTCAMP. Se pourrrait-il (conjecture éminemment farfelue) qu'en créant a priori une partition de queue après la partition
Windows (même sans emploi, comme certain héros...) - cela puisse débloquer l'installation de
Windows sur une partition n'allant pas jusqu'à la limite basse du disque (conjecture divergeant de la problématique de la
limite des
2 To) ?
--------------------
Il y a un autre point qui m'a intéressé, dans les nombreuses pistes de lecture fournies par
cheb à mon illettrisme informatique
: c'est le lien fourni dans le message
#31 à un fil des forums de «
CommentÇaMarche». Un intervenant nommé
xini se réjouit d'avoir pu installer un
Windows bootable grâce à la méthode de
Ritchi dont voici le descriptif :
Bloc de code:
- Supprimez toute partition crée avec BootCamp, C'est de là que vient le problème.
- Ouvrez l'Utilitaire de Disque, puis sélectionnez votre DISQUE DUR, pas la PARTITION.
- Dans l'onglet partition, Cliquez sur le petit plus en bas à gauche
- Choisissez dans formatage espace libre puis choisissez la taille que vous voulez allouer a votre partition WINDOWS.
- Cliquez sur partitionner puis confirmez et attendez que la partition se fasse.
- Rebootez sur votre Clé USB ou CD en choisissant non pas WINDOWS mais EFI BOOT. (Je sais pas si ça fait grand chose, mais ça permet d'avoir un résolution pas trop pourrie.)
- Faites Installer Maintenant puis entrez votre numéro de série et tout le tralala.
- Une fois à l'écran de sélection de partition vous devriez avoir dans les choix "Lecteur 0 Espace non alloué". choisissez le et NE LE FORMATEZ SURTOUT PAS.
- L'option suivant ne devrait plus être grisée, et le message d'erreur devrait avoir disparu. Vous pouvez à présent installer Windows normalement !
Le problème viendrait de la partition crée par Boot Camp, qui ne sarait pas au bon format.
--> voici quelque chose de tout à fait remarquable : donner comme cible à l'installateur de
Windows non pas une partition prédéfinie dans la table de partition
GPT maîtresse, mais un espace préalablement mis hors partitionnement
GPT et ayant le statut de "
Free_Space". L'installateur de
Windows serait capable d'identifier ce "
Free_Space" hors table
GPT comme "
Lecteur 0 Espace non alloué" et de l'adresser comme espace d'installation ! En créant son statut de partition (conjecturé-je) - ce prioritairement par conversion de la table "
Protective MBR" par défaut en une "
Hybrid MBR" dans laquelle cette partition se trouve instaurée. De sorte que (conjecturé-je toujours) c'est par un effet second que cette partition, instaurée en tant que partition de la table "
Hybrid MBR" en premier, se trouverait reconnue après-coup dans la table
GPT maîtresse sans avoir été créée en elle.
Malheureusement,
xini déclare avoir un
iMac dépourvu de
Fusion Drive (ce qui n'est pas un problème en soi), mais sans qu'on sache quelle est la taille de son disque unique. S'il s'agissait d'un disque d'une taille non supérieure à 2 To, le procédé remarquable de
Ritchi n'apporterait peut-être aucune solution au problème de la
limitation des
2 To qui affecte
cheb. On ne sait pas non plus quelle version de
Windows il cherchait à installer («
Windows 7 » ? «
Windows 8 » ?) - les installateurs pouvant avoir des comportements divergents.
--------------------
☞
en résumé : j'ai
spéculé sans
tuyauter. Mais les 2 dernières pistes mériteraient d'être creusées. Il faudrait re-démarrer sur la clé d'install de «
Yosemite» et dans son «
Terminal» faire :
diskutil cs list, récupérer l'
UUID du
Logical Volume Group et par un :
diskutil coreStorage deleteLVG xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx détruire une fois de plus le
Fusion Drive. Expérimenter à partir de là sur le HDD seul, parce que disque de
3 To, sans s'encombrer momentanément d'un
Fusion Drive.
Dans l'«
Utilitaire de Disque», sélectionner le disque physique global du HDD (ligne supérieure, attenante à la marge) --> menu "
Partitionner", sous-menu "
Schéma de partition" --> basculer l'onglet "
Actuel" et choisir "
3_partitions" en demandant les tailles suivantes : A) partition
Macintosh HD (format
jhfs+) = 2,5 To ; B) partition
Win (format
ms-dos) = 460 Go ; C) partition
Extra (format
jhfs+)= 40 Go.
Table de partition GUID maîtresse. Appliquer. Puis installer «
Yosemite» sur la partition
Macintosh HD. Une «
Recovery HD» sera créée entre les partitions A) et B).
À partir de là, tenter l'installation de «
Windows 7 » classiquement via «
BootCamp» --> test pour savoir si la position
pénultième de la partition-cible pour
Windows change la donne. Si échec, virer la partition «
Win» à du
Free_Space pour tester l'autre procédé. Passer plutôt, depuis la session de «
Yosemite», par le «
Terminal» (car l'«
Utilitaire de Disque» a été mis-à-jour dans les dernières MÀJ de «
Yosemite» pour le rapprocher du comportement de celui d'«
El Capitan» --> au lieu de supprimer une partition en laissant le
Free_Space hors partitionnement, il réalloue automatiquement le
Free_Space à la partition du dessus - ce sans obstacle de la «
Recovery HD» si elle est sur le chemin - ce qu'on ne souhaite pas). Dans le «
Terminal», donc, faire un
diskutil list pour vérifier l'identifiant de la partition «
Win» (je suppose en exemple que c'est
/dev/disk0s4), puis passer la commande :
Bloc de code:
sudo diskutil eraseVolume free brol /dev/disk0s4
ce qui va virer la partition à de l'espace libre --> vérifier sans passer par «
BootCamp» si l'installateur de
Windows accepte la donne en identifiant comme cible un : "
Lecteur 0 Espace non alloué" (à ne pas formater)...
--------------------
