Tuto: Installer BootCamp en externe (Thunderbolt uniquement)

Est-ce que cette solution fonctionne chez vous ?

  • Oui

    Votes: 1 25,0%

  • Non

    Votes: 3 75,0%
  • Total voters
    4
Donc le message : « gpt show: /dev/disk1: Suspicious MBR at sector 0 » signifie que tu as une HMBR sur le bloc 0 du disque 1 (le Crucial).

En somme : un disque Mac possède un secteur d'amorçage, constitué par les blocs d'en-tête du disque, qui permettent à l'EFI (le Programme Interne du Mac ou Firmware recelé dans une puce de la Carte-Mère et lancé par une pression sur le bouton d'allumage) d'accéder à l'espace logique du disque.

La particularité d'un disque Mac est de porter 2 tables de partition successives sur le secteur d'amorçage :

- une carte de partition secondaire de type MBR (Master Boot Record) qui réside sur le seul bloc 0 et dont les descripteurs représentent l'espace du disque en mode Windows.

- une carte de partition principale de type GPT (GUID Partition Table) qui réside sur les blocs 1 à 32 du disque et dont les descripteurs représentent l'espace du disque en mode Apple.​

--------------------​

À présent (car l'informatique est l'inverse de la simplicité) la table MBR du bloc 0 est susceptible de revêtir 2 formes :

- la forme PMBR (Protective_MBR), qui est la forme régulière, est présente aussi longtemps qu'aucune partition du disque ne recèle un format de système de fichiers Windows (FAT-32, exFAT ou NTFS). La particularité de cette forme PMBR est de représenter l'espace total du disque comme s'il était constitué d'une seule et unique partition. Cette représentation est évidemment erronée par référence à la table de partition GPT principale qui décrit régulièrement 3 partitions : n°1 = ESP (EFI_System_Partition) > n°2 = Macintosh HD (OS) > n°3 = Recovery HD (récupération) - une partition étant une container linéaire de blocs (de 512 octets) entre 2 limites exactes : bloc n°tant = début > bloc n°tant = fin, dont l'espace est géré par un système de fichiers, et dont la définition n'existe que dans la table de partition.

La PMBR, à cause de cette « erreur » de représentation logique "vertueuse" (représenter le disque comme formé d'une seule partition alors qu'il y en a 3 selon la GPT) > empêche des programmes de type Windows de pouvoir lire les partitions existantes du disque en mode MBR et les oblige, s'ils veulent adresser une partition particulière, à passer par la représentation de la GPT. Ils doivent pour ce faire être démarrés par l'EFI en mode UEFI.

- la forme HMBR (Hybrid_MBR) est une transformation de la PMBR qui intervient dès qu'une partition est créée sur le disque du Mac dans un format Windows (FAT-32, par exemple). Il s'agit donc d'une conversion logique automatique. La spécificité d'une HMBR est de faire écho, en mode MBR, à au plus 3 partitions prédéfinies dans la GPT. On la dit donc « hybride », parce qu'elle importe la définition GPT de partitions dans le schéma de description MBR. Elle ne crée donc nullement des partitions > elle retraduit en mode descriptif MBR les exactes déliminations de 3 partitions au plus de la GPT, au bloc près.​

--------------------​

La table de partition HMBR a fait les beaux jours de Windows sur Mac aussi longtemps que les versions de Windows bootaient en mode BIOS > alors l'EFI du Mac était capable d'exécuter le code de la HMBR pour amorcer en mode MBR le démarrage de Windows. C'est le mode de démarrage « Legacy » (héritage) de Windows. W-7 boote en mode « Legacy ».

Mais un OS comme W-10 n'est pas fait pour être booté en mode « Legacy », mais en mode UEFI : via une table de partition GPT. Pour booter une telle version de Windows, l'EFI du Mac passe régulièrement par l'amorçage de la GPT et exécute ainsi le boot_loader de Windows.

Mais... c'est là que les Satrapes s'attrapent. Comme dit précédemment, il suffit qu'une partition au format Windows soit créée sur le disque Mac pour qu'automatiquement la PMBR du bloc 0 soit convertie en HMBR. Il existe donc une table HMBR sur le bloc 0 qui tend comme sur un plateau à un programme Windows une représentation des partitions modo MBR sur le secteur logique initial (0), ce qui intercepte pour un tel programme la description GPT. Or le programme d'installation de W-10 est incompatible avec un amorçage MBR > il lui faut un amorçage GPT. Mais cet amorçage lui est interféré par l'amorçage HMBR du bloc 0.

Donc le programme te dit : «Windows ne peut pas être installé sur ce disque. Le disque sélectionné possède une table de partition MBR. Sur les systèmes EFI, Windows peut uniquement être installé sur des disques GPT.» => càd. que le programme d'installation de Windows veut un amorçage GPT et pas un amorçage MBR (un comble, non ? Windows sous les fourches caudines de la GPT reniant sa minable MBR).

--------------------​

Tu vois la solution ? Il faut reconvertir la HMBR du bloc 0 en PMBR mono-partitionnée qui ne représentera plus aucune partition spéciale du disque > alors le programme Windows sera obligé de se référer à la GPT pour amorcer une partition spécifique.

Oui mais... avec l'«Assistant BootCamp» je n'ai pas tous ces tracas. Hé ! l'«Assistant BootCamp» (quand il marche) est là pour te les éviter justement. Si W-10 est impliqué > il doit reconvertir la HMBR du bloc 0 à la forme PMBR afin de forcer l'installateur Windows à passer par la GPT.

Oui mais... toi tu démarres directo sur ta clé - alors qu'une partition au format Windows est créée et donc qu'une HMBR réside sur le bloc 0. Comment faire pour permettre l'amorçage GPT ?

Il y a 2 solutions manuelles :

- a) supprimer la partition BOOTCAMP précréée > ce qui efface son système de fichiers Windows > ce qui reconvertit automatiquement la HMBR du bloc 0 en PMBR. L'espace de blocs ainsi libérés du partitionnement GPT > il ne faut pas le réallouer à la partition d'OS X > il faut le laisser libre. Ainsi, l'installateur de W-10, via l'amorçage GPT, se représentera l'espace libre comme « non alloué » > si cet espace est sélectionné > l'installateur sera capable de le convertir en une partition d'accueil pour Windows.

- b) garder ou reformater (s'il y avait eu formatage NTFS) la partition BOOTCAMP au format FAT-32 (exclusivement). Ce qui préserve évidemment une HMBR sur le bloc 0. Utiliser alors l'exécutable de tierce partie gdisk (de Roderick Smith) et utiliser son menu avancé pour reconvertir la HMBR du bloc 0 en PMBR (gdisk est capable de cette opération sans rien toucher à la GPT des blocs 1 > 32). En conséquence, l'installateur de Windows forcé de passer par l'amorçage GPT devrait pouvoir cibler la partition BOOTCAMP au format FAT-32 comme partition d'accueil pour Windows.​

--------------------​
 
Dernière édition par un modérateur:
Effectivement " l'informatique est l'inverse de la simplicité " :dead:

Merci pour l'explication et les solutions proposées. Laquelle est la plus simple et me conseilles-tu ?

La liste des partitions et disques actuels de mon mac :

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *121.3 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_HFS Macintosh HD 120.3 GB disk0s2

3: Apple_Boot Recovery HD 650.0 MB disk0s3


/dev/disk1 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.0 TB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_HFS Stockage 750.0 GB disk1s2

3: Apple_Boot Recovery HD 650.0 MB disk1s3

4: Microsoft Basic Data Untitled 249.2 GB disk1s4
 
Je te propose dans un premier temps la méthode a)

Tu passes la commande :
Bloc de code: 
diskutil eraseVolume free NULL /dev/disk1s4
et hop ! ta partition 4: Microsoft Basic Data Untitled 249.2 GB disk1s4 disparaît de l'affiche, car son système de fichiers vient d'être effacé. Mais ses 249 Go de blocs sont toujours bien là - simplement ils ont le statut de free_space (espace libre hors partitionnement GPT).

Re-démarre ton Mac > repasse un :
Bloc de code: 
sudo gpt show /dev/disk1
et poste le tableau retourné que je vérifie si la « suspicious MBR at sector 0 » a bien disparu pour être remplacée par une PMBR suite à la suppression du format de système de fichiers Windows de l'ex-partition disk1s4.
 
  • J’aime
Réactions: Membre supprimé 1126760
Et voilà :

start size index contents

0 1 PMBR

1 1 Pri GPT header

2 32 Pri GPT table

34 6

40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B

409640 1464834232 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC

1465243872 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

1466513408 487011727

1953525135 32 Sec GPT table

1953525167 1 Sec GPT header
 
Parfait. Comme tu vois la MBR du bloc 0 est bien redevenue une PMBR.

Alors il ne te reste plus, ta clé attachée, qu'à re-démarrer avec "alt" > choisir le boot UEFI sur la clé (ce doit être un volume affiché comme EFI ou EFI Boot au lieu de Windows qui doit désigner le boot en mode « Legacy ») > désigner à l'installateur comme destination pour installer Windows l'espace « non alloué » du disque 1 > ne pas reformater cet espace en préalable > laisser l'installateur se débrouiller avec.

Bon : comme je n'ai jamais utilisé Windows (et pas non plus booté sur des clés d'install de Windows) > je manque complètement de bases expérimentales ici concernant le comportement de l'installateur Windows).
 
  • J’aime
Réactions: Membre supprimé 1126760
En fait ta solution reprend ce qui était écrit dans le tuto (cf mon post #118) :

" Choisissez dans formatage espace libre puis choisissez la taille que vous voulez allouer a votre partition WINDOWS "

Sauf que ça manquait de précisions pour quelqu'un comme moi. Donc je te remercie et je vais essayer en croisant les doigts.
 
Bon ça a fonctionné, mais lorsque l'installation allait se lancer, elle s'est annulée avec le message suivant :

Windows a détecté que la partition EFI est formatée en NTFS. Formatez la partition EFI en FAT32, puis redémarrez l'installation.
 
fl0rian67 a dit:
Windows a détecté que la partition EFI est formatée en NTFS. Formatez la partition EFI en FAT32, puis redémarrez l'installation.
Cliquez pour agrandir...

Windows : c'est un véritable calvaire logique. Je n'arrive pas à concevoir ce qui peut en faire un « objet de désir » - à part une déviation masochiste de la psychè...
361608_original.png

Donc à présent l'installateur de Windows ne rechigne plus à propos de la table de partition : booté en mode UEFI > aucune table de la forme HMBR sur le bloc 0 ne lui représente un espace partitionné du disque en mode « Legacy » > mais cette table remise en forme PMBR ne lui représente... rien en terme de partitions particulières > ce qui fait que l'installateur lit la table GPT alternative qui lui représente un espace partitionné du disque conforme à ses attentes, y compris la bande de free_space de queue du disque.

Mais il a encore une objection semble-t-il : c'est que la partition EFI de la table GPT n'a pas le bon format de système de fichiers.
--------------------​

Bon : il s'agit de la partition n°1 régulière d'une table de partition GPT --> l'ESP ou EFI_System_Partition de 209,7 Mo. Celle-ci exactement :
Bloc de code: 
1: EFI EFI 209.7 MB disk1s1

Alors effectivement > cet affichage par diskutil n'est pas très causant. Ce qu'il dit c'est que la partition n°1 est de type EFI (c'est le premier EFI) : il ne s'agit pas ici d'un format de partition, mais du type de partition correspondant à un code (EFx00) qui assigne à sa création à ce petit container-disque son statut logique spécifique. Il en va ici comme pour la partition Recovery HD dont la désignation Apple_Boot ne signifie pas un format de système de fichiers > mais là encore un type de partition identifié par un code (ABx00) qui lui confère son statut logique spécifique.

Le 2è EFI affiché désigne le nom de volume montable de cette partition. Normalement, si l'on passe une commande :
Bloc de code: 
diskutil mount /dev/disk1s1
le volume EFI se monte (et on voit son icône s'afficher sur le Bureau) > si à partir de là on passe la commande informative :
Bloc de code: 
diskutil info /Volumes/EFI
on obtient régulièrement un tableau de paramètres dont voici le haut :
Bloc de code: 
 Device Identifier:        disk1s1
   Device Node:              /dev/disk1s1
   Whole:                    No
   Part of Whole:            disk1
   Device / Media Name:      EFI System Partition

   Volume Name:              EFI

   Mounted:                  Yes
   Mount Point:              /Volumes/EFI

   File System Personality:  MS-DOS FAT32
   Type (Bundle):            msdos
   Name (User Visible):      MS-DOS (FAT32)
où il apert bien que le format de système de fichiers de ce volume monté EFI est : MS-DOS FAT32.

Donc je ne vois pas a priori pourquoi l'installateur de Windows trouverait à arguer à propos d'une partition ESP régulière dont le volume monté EFI relève d'un format MS-DOS FAT32 de système de fichiers à moins que...

... à moins que, lors d'une manipulation précédente avec l'installateur booté en mode « Legacy » (volume Windows) et lisant la table de partition HMBR qui était inscrite sur le bloc 0 > il n'y ait eu un reformatage de la partition ESP de MS-DOS FAT32 à NTFS.
--------------------​

Je te propose donc de collecter des informations comparées sur les 2 partitions ESP de tes 2 disques : le SSD Apple disk0 et le SSD Crucial disk1.

Donc tu commences par passer la commande de montage en volume de l'ESP du SSD Apple :
Bloc de code: 
diskutil mount /dev/disk0s1
qui t'affiche un volume EFI sur le Bureau.

Tu demandes l'affichage des infos relatives à ce volume EFI par la commande :
Bloc de code: 
diskutil info /Volumes/EFI
qui te retourne le tableau des paramètres du volume EFI du SSD Apple.

À présent du démontes le volume EFI du SSD Apple par la commande :
Bloc de code: 
diskutil umount /dev/disk0s1
et tu vois disparaître l'affichage de l'icône du volume sur le Bureau.

Tu montes en volume à présent l'ESP du SSD Crucial par la commande :
Bloc de code: 
diskutil mount /dev/disk1s1
qui t'affiche un volume EFI sur le Bureau (l'identité nominale de ce volume avec le précédent t'explique pourquoi il valait mieux démonter le précédent au préalable, afin qu'il n'y ait pas confusion d'adressage de la commande d'info suivante).

Tu demandes l'affichage des infos relatives à ce volume EFI par la commande :
Bloc de code: 
diskutil info /Volumes/EFI
qui te retourne le tableau des paramètres du volume EFI du SSD Crucial.

Tu n'as plus qu'à redémonter ce volume EFI du SSD Crucial par la commande :
Bloc de code: 
diskutil umount /dev/disk1s1
et tu vois disparaître l'affichage de l'icône du volume sur le Bureau.

Ce jeu de commandes (qui ressemble furieusement à celui du «Fort-Da» enfantin analysé par Freud au début des «Essais de Psychanalyse» pour exemplifier le principe de répétition) t'a laissé à l'affiche de la fenêtre du «Terminal» les 2 tableaux informatifs concernant le volume EFI du SSD Apple et le volume EFI du SDD Crucial. Peux-tu poster chacun de ces tableaux ici en copier-coller ?

=> il sera aisé de vérifier s'il y a bien une variation des formats de système de fichiers : MS-DOS FAT32 pour le volume EFI de la partition disk0s1 vs NTFS pour le volume EFI de la partition disk1s1 --> ce qui révélerait qu'il y a eu manipulation indue ; ou s'il y a identité des formats de systèmes de fichiers = MS-DOS FAT32 pour les 2 volumes EFI des partitions disk0s1 & disk1s1 --> auquel cas l'installateur de Windows serait maboule...

--------------------​
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Membre supprimé 1126760
Hello ! Alors voici les 2 tableaux (à noter que disk0 : SSD Crucial, et disk1 : SSD Apple - eh oui ça s'est encore inversé) :

Bloc de code: 
 Device Identifier:        disk0s1
   Device Node:              /dev/disk0s1
   Whole:                    No
   Part of Whole:            disk0

   Volume Name:              EFI
   Mounted:                  Yes
   Mount Point:              /Volumes/EFI

   Partition Type:           EFI
   File System Personality:  MS-DOS FAT32
   Type (Bundle):            msdos
   Name (User Visible):      MS-DOS (FAT32)

   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 SATA
   SMART Status:             Verified
   Volume UUID:              0E239BC6-F960-3107-89CF-1C97F78BB46B
   Disk / Partition UUID:    1E490082-C56C-47C5-BFC2-A8C2A2C8E174

   Disk Size:                209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Units)
   Device Block Size:        512 Bytes

   Volume Total Space:       206.5 MB (206472192 Bytes) (exactly 403266 512-Byte-Units)
   Volume Used Space:        16.6 MB (16556544 Bytes) (exactly 32337 512-Byte-Units) (8.0%)
   Volume Available Space:   189.9 MB (189915648 Bytes) (exactly 370929 512-Byte-Units) (92.0%)
   Allocation Block Size:    512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         No

   Device Location:          Internal
   Removable Media:          Fixed

   Solid State:              Yes

Bloc de code: 
Device Identifier:        disk1s1
   Device Node:              /dev/disk1s1
   Whole:                    No
   Part of Whole:            disk1

   Volume Name:              EFI
   Mounted:                  Yes
   Mount Point:              /Volumes/EFI

   Partition Type:           EFI
   File System Personality:  MS-DOS FAT32
   Type (Bundle):            msdos
   Name (User Visible):      MS-DOS (FAT32)

   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 PCI
   SMART Status:             Verified
   Volume UUID:              0E239BC6-F960-3107-89CF-1C97F78BB46B
   Disk / Partition UUID:    74C01EA3-CF38-4722-B454-EA2F5A89F1E8

   Disk Size:                209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Units)
   Device Block Size:        512 Bytes

   Volume Total Space:       206.5 MB (206472192 Bytes) (exactly 403266 512-Byte-Units)
   Volume Used Space:        16.5 MB (16459264 Bytes) (exactly 32147 512-Byte-Units) (8.0%)
   Volume Available Space:   190.0 MB (190012928 Bytes) (exactly 371119 512-Byte-Units) (92.0%)
   Allocation Block Size:    512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         No

   Device Location:          Internal
   Removable Media:          Fixed

   Solid State:              Yes
   Device Location:          "SSD"
 
Oui : les 2 disques ne s'attachent pas au Système dans le même ordre systématiquement.

Eh bien ! Contrairement à mes attentes (qui se fondaient sur les dires de l'installateur de Windows) > le volume EFI de l'ESP de l'actuel disk0 (= Crucial) ne se distingue de celui du SSD Apple : il relève du même format régulier pour cette partition MS-DOS (FAT32). Par conséquent l'allégation de l'installateur de Windows : « Windows a détecté que la partition EFI est formatée en NTFS. Formatez la partition EFI en FAT32, puis redémarrez l'installation » est nulle et non avenue.

J'avais envisagé de supprimer cette partition avec l'utilitaire gpt après avoir sauvegarder son contenu de fichiers > puis de la recréer formellement avec les bons paramètres > avant de recloner les fichiers sauvegardés : c'est formellement inutile.

Je ne vois que 2 possibilités :

- 1° soit il y a eu précédemment installation dans ce volume EFI d'un dossier d'instructions Windows qui fait croire à l'installateur qu'il a affaire à un volume NTFS ;

- 2° soit il y a eu fixation indue sur l'en-tête du volume d'un boot_flag (indicateur de caractère démarrable) - encore que le rapport dans ce cas me paraît des plus ténu avec un format NTFS ;

- 3° il y a toujours une 3è possibilité quand on en aperçoit 2 : l'installateur de Windows aurait carrément déraillé > re-démarrer l'OS en clean install du volume Stockage du Crucial un coup > re-démarrer ensuite sur la clé d'install de Windows > relancer l'installation.​

Afin de de tester l'hypothèse 1° > tu passes la commande :
Bloc de code: 
diskutil mount /dev/disk0s1
(si le Crucial est bien toujours disk0 - tu n'as qu'à passer un diskutil list préalable pour vérifier. Sinon > tu mets disk1s1 en fin de commande) => un volume EFI s'affiche sur le Bureau > ouvre-le d'un double-clic --> est-ce qu'il y a un ou plus d'un dossier bizarre, à l'intitulé évoquant Windows ?

Pour comparaison > passe dans la foulée la commande :
Bloc de code: 
diskutil mount /dev/disk1s2
(l'identifiant de device alternatif ciblant l'ESP du SSD Apple) > ouvre le volume EFI concurrent affiché sur le Bureau > est-ce que vois les mêmes dossiers (genre un APPLE contenant des exécutables pour l'EFI) ou est-ce qu'il y a une différence ? Est-ce que tu peux décrire ton expérience ?
 
  • J’aime
Réactions: Membre supprimé 1126760
Alors d'après mes partitions, le volume EFI du SSD Apple se trouve sur le disk1s1 et non sur le disk1s2, donc j'ai monté ce volume et aussi le volume du disk0s1 (EFI du SSD Crucial), et les 2 ne présentent qu'un seul chemin EFI > APPLE > EXTENSIONS > Firmaware.scap. Pas de signes d'un dossier évoquant Windows.

Je ne sais pas si ça peut t'aider, mais en lançant l'installation de Windows hier soir (annulée à 0%), j'ai 2 nouvelles partitions invisibles sur le bureau :

Bloc de code: 
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Stockage                750.0 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:           Windows Recovery                         471.9 MB   disk0s4
   5:                        EFI NO NAME                 104.9 MB   disk0s5
   6:         Microsoft Reserved                         16.8 MB    disk0s6
   7:       Microsoft Basic Data Boot Camp               248.8 GB   disk0s7

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Macintosh HD            120.3 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

Edit : la partition à l'emplacement 7 s'appelle Boot Camp car je l'ai effacé avec l'Utilitaire de disque (toujours en NTFS), en espérant effacer aussi les partitions Windows Recovery et Microsoft Reserved et retenter une installation, mais elles sont toujours là.
 
Erreur de saisie de ma part : il fallait lire disk0s1 et pas disk0s2 comme tu l'as parfaitement compris.

Effectivement l'installateur de Windows a créé 3 petites partitions excédentaires (!) et je pense alors que la partition EFI à laquelle il faisait allusion est la EFI NO NAME 104.9 MB disk0s5 qu'il a dû créer dans un mauvais format.

Je te propose alors d'effacer les 4 partitions disk0s4 à disk0s7 pour restaurer une bande d'espace libre continu en-dessous de la Recovery HD en disk0s3 > de manière à ce que tu puisses relancer une installation propre et voir si ça passe ce coup-ci.

Donc tu passes l'une après l'autre les commandes :
Bloc de code: 
diskutil eraseVolume free NULL1 /dev/disk0s4
diskutil eraseVolume free NULL2 /dev/disk0s5
diskutil eraseVolume free NULL3 /dev/disk0s6
diskutil eraseVolume free NULL4 /dev/disk0s7

[la commande appelle diskutil > avec le verbe eraseVolume (effacer le système de fichiers du volume) > et une triplette [FORMAT][NOM][DEVICE] où le format = free (abrégé de free_space : ne pas recréer de système de fichiers mais laisser les blocs libres) > le nom = formellement requis mais bidon avec l'option free (car sans système de fichiers > aucun nom de volume n'est pertinent - j'ai pris NULL1 etc. mais j'aurais pu prendre BROL ou zut chaque fois) > le device est l'identifiant de la partition.]

Si tu passes un :
Bloc de code: 
diskutil list
ensuite > tu devrais ne plus voir que les 3 partitions Apple sur le disk0 Crucial => tu n'as qu'à redémarrer sur ta clé et retenter le coup en choisissant encore l'espace non alloué.

La création de 4 partitions, donc 3 auxiliaires avant la partition-Système dédiée à Windows me paraît une fumisterie pas possible.
 
  • J’aime
Réactions: Membre supprimé 1126760
Donne le retour d'un :
Bloc de code: 
diskutil list
que je vois où en est le partitionnement du Crucial.

Sinon : il y a encore le procédé manuel b) qui utilise gdisk et qui consiste : à créer une partition BOOTCAMP FAT-32 en position n°4 > puis à convertir la HMBR du bloc 0 à la forme PMBR => si l'installateur de Windows boote en mode UEFI > càd. lit la table GPT > il devrait pouvoir reconnaître la partition BOOTCAMP comme une destination d'installation valide.

J'ai encore une remarque : pourquoi n'utilises-tu pas complètement l'«Assistant BootCamp» ? Il est censé t'éviter ces affres logiques et ces repartitionnements délirants lorsque tu bootes d'entrée sur la clé d'install.

[Comme je n'utilise pas Windows > la déficience de mes tentatives d'aide est que je ne n'ai absolument aucune base expérimenale sur le sujet. Je suis obligé de tout imaginer en mode théorique - ce qui fait qu'il y a forcément des variables dont je ne tiens pas compte.]
 
J'avais essayé d'utiliser l'Assistant Boot Camp. C'est bien grâce à lui que j'ai pu créer une clé USB bootable à partir d'un fichier Windows 10 en .iso, mais c'est aussi à cause de lui que j'ai eu le message suivant lors de l'installation de Windows (cf post #118) :

Windows ne peut pas être installé sur ce disque. Le disque sélectionné est du style de partition GPT.
Cliquez pour agrandir...

J'étais tombé sur ce tuto : http://www.commentcamarche.net/foru...-ne-peut-pas-etre-installe-sur-ce-disque-help
dont tu m'as donné plus de détails. Tu peux y jeter un coup d'oeil si tu as le temps, j'ai peut-être zappé quelque chose.

Sinon, voici l'état des disques :

Bloc de code: 
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Stockage                750.0 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Macintosh HD            120.3 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

L'espace libre de 250 Go du SSD Crucial est toujours présent.
 
Le tuto que tu cites revient à faire strictement la même chose, mais par l'«Utilitaire de Disque» : virer à de l'espace libre une partition BOOTCAMP (ce qui restaure une PMBR sur le bloc 0 par suppression du format de système de fichiers Windows) et cibler l'installateur, booté en mode UEFI, sur cet espace « non alloué ». C'est censé marcher. Sauf chez toi.

--------------------​

À présent opère à partir de l'OS démarré du volume Macintosh HD.

Vérifie par un diskutil list que le Crucial est bien disk0 (sinon permute le chiffre à 1 dans ce qui suit).

Pour récupérer l'espace libre à la partition Stockage :
Bloc de code: 
diskutil resizeVolume /dev/disk0s2 0b
(le 0b = 0_byte se comprend : "ne laisser aucune byte inutilisé dans l'opération de redimensionnement") => ton volume Stockage devrait être regonflé à 999 Go.

Pour exporter une partition BOOTCAMP de 249 Go au format MS-DOS :
Bloc de code: 
diskutil resizeVolume /dev/disk0s2 750g fat32 BOOTCAMP 0b

Évidemment la création de cette partition au format Windows a viré la PMBR du bloc 0 à la forme HMBR absolument rejetée par l'installateur de W-10. Donc tu télécharges gdisk ici : ☞GPT fdisk☜ ce qui te procure un paquet d'installation disk-1.0.1.pkg > tu le double-cliques et il t'installe l'exécutable gdisk at: /usr/local/bin/gdisk (usr est un répertoire invisible graphiquement au Finder qui recèle des binaires UNIX). Tu peux désormais appeler gdisk en ligne de commande.

La commande :
Bloc de code: 
sudo gdisk /dev/disk0
lance gdisk et retourne le scan des tables de partitions du disque Crucial (tu devrais noter que la MBR du bloc 0 est une Hybrid_MBR) avec affichage en dernier de l'invite de commande interactive :
Bloc de code: 
Command (? for help):

Tu tapes simplement :
Bloc de code: 
x
(comme expert) et ↩︎ (tu valides) => le logiciel affiche la nouvelle invite de commande du mode expert :
Bloc de code: 
Expert command (? for help):

Tu tapes :
Bloc de code: 
n
(comme new Protective MBR) et ↩︎ => gdisk te réaffiche sans commentaire l'invite de commande :
Bloc de code: 
Expert command (? for help):
(la modification est seulement en cache)

Tu tapes :
Bloc de code: 
w
(comme write) et ↩︎ => tu obtiens l'affichage :
Bloc de code: 
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N):

Tu tapes :
Bloc de code: 
y
(comme yes) => gdisk te retourne :
Bloc de code: 
OK; writing new GUID partition table (GPT) to /dev/disk0.
Warning: Devices opened with shared lock will not have their partition table automatically reloaded!
Warning: The kernel may continue to use old or deleted partitions. You should reboot or remove the drive.
The operation has completed successfully.
et tu récupères l'invite de commande du «Terminal» à ton nom d'utilisateur.

Comme tu es invité à re-démarrer pour rafraîchir le kernel => tu re-démarres et tu refais un :
Bloc de code: 
sudo gpt /dev/disk0
(vérifie d'abord par un diskutil list que le Crucial est toujours disk0) --> tu devrais voir que la MBR du bloc 0 est désormais une Protective_MBR. Tu as donc à la fois une partition BOOTCAMP dans un format Windows FAT-32 mais une PMBR standard néanmoins sur le bloc 0.

Tu n'as plus qu'à booter sur ta clé en mode UEFI > amorçage GPT > voir si la partition BOOTCAMP de cette table est acceptée comme partition de destination pour Windows.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: scoliaste
J'ai bien suivi les étapes sans soucis à noter jusqu'au redémarrage. Le disque Crucial est passé en disk1 donc j'ai utilisé la dernière commande en changeant disk0 par disk1 mais j'ai eu le message :
Bloc de code: 
gpt: unkwnown command: /dev/disk1
Je te colle l'ensemble des dernières opérations pour être sûr :
Bloc de code: 
diskutil resizeVolume /dev/disk0s2 0b
Resizing to full size (fit to fill)
Started partitioning on disk0s2 Stockage
Verifying the disk
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Stockage appears to be OK
File system check exit code is 0
Resizing
Modifying partition map
Copying booter
Growing file system
Finished partitioning on disk0s2 Stockage
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Stockage                999.3 GB   disk0s2
   3:                 Apple_Boot                         650.0 MB   disk0s4
imac-de-florian:~ Florian$

diskutil resizeVolume /dev/disk0s2 750g fat32 BOOTCAMP 0b
Resizing to 750000000000 bytes and adding 1 partition
Started partitioning on disk0s2 Stockage
Verifying the disk
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Stockage appears to be OK
File system check exit code is 0
Resizing
Shrinking file system
Copying booter
Modifying partition map
4096 bytes per physical sector
/dev/rdisk0s5: 486881152 sectors in 7607518 FAT32 clusters (32768 bytes/cluster)
bps=512 spc=64 res=32 nft=2 mid=0xf8 spt=32 hds=255 hid=1466523648 drv=0x80 bsec=487000064 bspf=59440 rdcl=2 infs=1 bkbs=6
Mounting disk
Finished partitioning on disk0s2 Stockage
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Stockage                750.0 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data BOOTCAMP                249.3 GB   disk0s5
imac-de-florian:~ Florian$

sudo gdisk /dev/disk0
Password:
GPT fdisk (gdisk) version 1.0.1

Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with hybrid MBR; using GPT.

Command (? for help): x

Expert command (? for help): n

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/disk0.
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
The operation has completed successfully.
imac-de-florian:~ Florian$
  [Restauré 23 oct. 2016 à 22:33:24]
Last login: Sun Oct 23 22:33:23 on console
Restored session: Dim 23 oct 2016 22:32:56 CEST
imac-de-florian:~ Florian$

diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            120.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Stockage                750.0 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:       Microsoft Basic Data BOOTCAMP                249.3 GB   disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 TB     disk2
   1:               Windows_NTFS WD 1 To                 1.0 TB     disk2s1

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.5 GB    disk3
   1:                 DOS_FAT_32 WININSTALL              15.5 GB    disk3s1

imac-de-florian:~ Florian$

sudo gpt /dev/disk1
Password:
gpt: unknown command: /dev/disk1
 
:coucou: Fl0rian

Tout s'est correctement déroulé jusqu'à la dernière commande informative. Comme je ne suis absolument pas du soir, mais du matin > mon attention s'est relâchée au moment de saisir la commande dans mon message et j'ai saisi gpt à la place de gdisk --> ce qui a donné une commande « hybride » (sudo gpt /dev/disk1) qui n'était valide pour aucun des 2 exécutables.

À présent que l'aube a restauré ma lucidité, les commandes correctes (au choix) sont :
Bloc de code: 
sudo gpt show /dev/disk1
sudo gdisk /dev/disk1
(en résumé pour appeler le scan de gpt sur un disque il faut intercaler le verbe show = montrer ; alors que celui de gdisk s'appelle directement à destination de l'appareil).

L'intérêt est simplement de vérifier que tu as bien actuellement la combinaison : format Microsoft Basic Data (= FAT-32) pour la partition BOOTCAMP disk1s4 et la forme PMBR (Protective_MBR) de table de partition MBR sur le bloc 0. Une combinaison qui, théoriquement parlant, devrait permettre à l'installateur de la clé, booté en mode UEFI, de lire la GPT du disque 1 (la PMBR ne lui représentant aucune partition déterminée) > et d'aviser la partition n°4 BOOTCAMP comme une destination dans le bon format d'accueil (FAT-32).

Ça : c'est évidemment la théorie (l'idée générale que je me fais du processus). Je n'ai aucune base expérimentale qui me permettrait de tenir compte de facteurs additionnels susceptibles de déranger ce plan général impeccable sur le papier. Ainsi, quand tu as essayé le scénario a) [= remplacer la partition BOOTCAMP par de l'espace libre > ce qui remet une table PMBR sur le bloc 0 > ce qui permet à l'installateur booté en mode UEFI de lire la GPT > et d'aviser en mode GPT cet espace comme « non alloué » > par suite de s'en servir pour une partition de destination de Windows] => tu t'es heurté à un échec alors que, selon l'idée générale de la manœuvre, je suis persuadé que ça aurait dû marcher (ça a d'ailleurs failli marcher).

Néanmoins, la création de 3 partitions d'en-tête de la partition Windows à partir de l'espace « non alloué » > semble montrer qu'avec ce scénario une complication logique intervient : comme si l'installateur de Windows avait besoin de créer un doublon de l'ESP (la partition EFI n°1 du disque) plus une partition Microsoft Reserved (voire une pseudo-Recovery) avant la partition Windows pour que le boot soit possible en mode GPT. Ignorant totalement le fonctionnement de Windows > je manque ici de bases pour me représenter en idée la fonction logique de ces micro-partitions.
 
  • J’aime
Réactions: scoliaste
Salut macomaniac ! Ah sur ce point nous sommes donc opposé : je suis plutôt du soir (les séquelles d'une vie étudiante ?).
Avant d'avoir cet iMac j'avais un MacBook Pro 15" Rétina mi-2015 avec lequel j'avais installé Windows 10 via l'Assistant Boot Camp. Tout s'était déroulé parfaitement, et là ça fait plus d'une semaine qu'on se penche sur le sujet :banghead:.

Bon sinon voilà où ça en est après la dernière commande :
Bloc de code: 
sudo gpt show /dev/disk1
Password:
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6       
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640  1464843744      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1465253384     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1466522920         728       
  1466523648   487000064      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  1953523712        1423       
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header
 
Tout est comme il doit l'être : PMBR sur le bloc 0 + partition BOOTCAMP au format FAT-32. Donc « théoriquement parlant » l'installateur de «Windows», booté en mode UEFI, doit négliger la PMBR mono-partitionnée qui ne représente aucune partition déterminée et lire la GPT qui lui représente 4 partitions > si tu lui indiques la partition BOOTCAMP comme cible > il devrait l'accepter (« en théorie » - toujours).

Si ça ne passe pas non plus > je suis au bout de mon rouleau. Comme je n'utilise pas Windows > je ne peux pas entrer dans un niveau plus fin de détails sur un sujet que j'ignore.
 
  • J’aime
Réactions: scoliaste

Sujets similaires

W
Redimensionnement partition BootCamp, disque non visible par l'assistant
Réponses
3
Affichages
2K
Windows sur Mac
Locke
Locke
Totoleheros
Fusion drive avec BootCamp --> 2 SSD
Réponses
19
Affichages
3K
Windows sur Mac
Totoleheros
Totoleheros
thibosh62
Windows sur disque dur externe
Réponses
2
Affichages
2K
Windows sur Mac
Locke
Locke
S
erreur installation windows 10 bootcamp
Réponses
9
Affichages
2K
Windows sur Mac
saleem51
S
P
mac os et bootcamp
Réponses
1
Affichages
1K
Windows sur Mac
pierre94
P
Haut Bas
Back