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

fl0rian67

Membre junior
10 Octobre 2016
57
2
28
Bon ça n'a pas fonctionné. Je vais rester exclusivement sur macOS et abandonner Windaube ! En fait je le voulais pour utiliser un logiciel exclusif Windows et 2 jeux. Je vais me rabattre sur un équivalent Mac et jouer sur ma console.
Est-ce qu'un diskutil eraseVolume free NULL1 /dev/disk0 suffit pour effacer proprement tout mon disque Crucial, l'espace libre, le GPT fdisk etc. ?
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
74 448
22 661
Forêt de Fontainebleau
Tu ne pourras pas dire que tu n'auras pas essayé ! Mais tu peux voir aussi le bon côté de ces échecs : la « Main Invisible de la Providence » (Adam Smith) s'est sans nul doute avérée à l'œuvre, ici, pour te « forcer à devenir libre »


Ton projet de commande : diskutil eraseVolume free NULL1 /dev/disk0 ne marcherait pas, parce que le verbe eraseVolume (effacer le volume) n'est valide que lorsque le device-cible est une partition > pas un disque entier comme ton disk0. Pour effacer un disque entier, il convient d'utiliser le verbe eraseDisk. De plus, si tu ne veux pas te contenter d'effacer les systèmes de fichiers en place sur les partitions sans les remplacer, mais si tu veux recréer un système de fichiers JHFS+ vide sur une partition principale qui montera un volume, alors il ne faut pas introduire le paramètre free (= free_space), mais jhfs+.

Une commande valide avec le verbe eraseDisk serait :
Bloc de code:
diskutil eraseDisk jhfs+ Stockage gpt /dev/disk0
(à supposer bien sûr que le disque cible (le Crucial) porte le n°0 au moment où tu passes la commande).

Personnellement parlant, je n'aime pas employer le verbe eraseDisk avec diskutil, pour la raison suivante : je trouve que l'ordre des paramètres pour que son emploi soit valide est dérangeant. Comme tu le vois dans la commande précédente (qui est valide) : l'ordre consiste à désigner d'abord le format de système de fichiers (jhfs+) > puis le nom du volume (Stockage) > puis le type de carte de partition (gpt) > enfin l'identifiant de device du disque (/dev/disk0) => on procède donc du particulier (une doublette [FORMAT][NOM] paramétrant la partition principale : jhfs+ Stockage) au général (une doublette
[DEVICE]
désignant le disque total : gpt /dev/disk0 ).

Je préfère employer le verbe partitionDisk qui donnerait la commande suivante :
Bloc de code:
diskutil partitionDisk /dev/disk0 gpt jhfs+ Stockage 100%
parce que l'ordre va du général au particulier : d'abord une doublette [DEVICE]
= /dev/disk0 gpt qui cible le disque entier et sa table de partition générale > ensuite seulement intervient un triplette paramétrant la partition principale : [FORMAT][NOM][TAILLE] = jhfs+ Stockage 100% .

Je trouve en outre que le verbe partitionDisk a beaucoup plus de souplesse d'emploi, parce qu'après la doublette définissant le disque [DEVICE]
> on peut si l'on veut partitionner finement le disque en alignant autant de triplettes [FORMAT][NOM][TAILLE] que de partitions envisagées (dans le respect bien entendu de la capacité totale du disque). Par exemple :
Bloc de code:
diskutil partitionDisk /dev/disk0 gpt jhfs+ Macintosh\ HD 750g fat32 BOOTCAMP 0b
créerait 2 partitions principales (après l' ESP = EFI System Partition de 209 Mo qui se crée automatiquement en en-tête) : une partition Macintosh HD (tu notes l'antislash \ destiné à échapper l'espace libre entre Macintosh et HD afin que ce groupe de mots soit lu d'un seul tenant sans casser la commande) au format JHFS+ d'une taille de 750 Go (la désignation des valeurs de taille n'est pas sensible à la casse : 750g = 750G => les 2 sont lus comme 750 GB ou 750 Go ) > puis une 2è partition BOOTCAMP au format FAT-32 (idem : pas de sensiblilité à la casse => fat32 possible aussi bien que FAT32 ) dont la taille astucieusement assignée par 0b signifie : racler les fonds de tiroirs pour utiliser tous les bytes disponibles (tu noteras encore que le b ne désigne pas le bit ici, mais le byte pour lequel on utilise couramment le B ) > ce qui donnera environ 250 Go .
 
  • J’aime
Réactions: scoliaste

ninkasi67

Membre émérite
24 Octobre 2016
760
32
47
strasbourg
salut la team , j'ai fait les manip gpt ! windows a commencer à se lancer fin d'installation erreur ! bref la loose ....

Last login: Sun Oct 30 10:11:43 on console
MacBook-Pro-de-riemer:~ marco$ diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *250.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Sierra 249.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3

/dev/disk2 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +232.5 GB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS Time Machine Backups 232.1 GB disk2s2

ensuite

MacBook-Pro-de-riemer:~ marco$ diskutil cs list
No CoreStorage logical volume groups found
MacBook-Pro-de-riemer:~ marco$

vous pouvez m'aider
 

ninkasi67

Membre émérite
24 Octobre 2016
760
32
47
strasbourg
MacBook Pro 2011 osx Sierra , Windows 8,1 ou 10 .... j'ai fait les manip via terminal et gdx j'ai planté qq part
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
74 448
22 661
Forêt de Fontainebleau
Win-8 ou 10 bootent en mode UEFI : via la table de partition principale GPT de l'en-tête du disque, décrivant les partitions (dont la BOOTCAMP) en mode GUID. Il est donc nécessaire que la table de partition secondaire MBR du bloc 0 du disque soit une PMBR (Protective_MBR) ne décrivant pour sa part aucune partition particulière mais représentant le disque comme un espace d'un seul tenant > en conséquence de quoi, cette table n'est pas lue pour démarrer Windows, mais c'est la GPT des blocs 1 > 32 qui sert de carte d'amorçage.

Le tableau des partitions actuel de ton disque ne comporte aucune partition dans un format Windows > en conséquence, la MBR du bloc 0 de ton disque doit être automatiquement une PMBR comme requis. Tu peux vérifier ce point en postant le retour de la commande :
Bloc de code:
sudo gpt show /dev/disk0
qui devrait révéler une PMBR sur le bloc 0. S'il en bien ainsi > l'«Assistant BootCamp» a donc toutes les conditions logiques requises au départ pour installer Windows.
 
D

Deleted member 1099514

Invité
Win-8 ou 10 bootent en mode UEFI : via la table de partition principale GPT de l'en-tête du disque, décrivant les partitions (dont la BOOTCAMP) en mode GUID. Il est donc nécessaire que la table de partition secondaire MBR du bloc 0 du disque soit une PMBR (Protective_MBR) ne décrivant pour sa part aucune partition particulière mais représentant le disque comme un espace d'un seul tenant > en conséquence de quoi, cette table n'est pas lue pour démarrer Windows, mais c'est la GPT des blocs 1 > 32 qui sert de carte d'amorçage.

Le tableau des partitions actuel de ton disque ne comporte aucune partition dans un format Windows > en conséquence, la MBR du bloc 0 de ton disque doit être automatiquement une PMBR comme requis. Tu peux vérifier ce point en postant le retour de la commande :
Bloc de code:
sudo gpt show /dev/disk0
qui devrait révéler une PMBR sur le bloc 0. S'il en bien ainsi > l'«Assistant BootCamp» a donc toutes les conditions logiques requises au départ pour installer Windows.
Hello @macomaniac :coucou:

Ça part dans tous les sens. Voir la réponse ici : #39
 

ninkasi67

Membre émérite
24 Octobre 2016
760
32
47
strasbourg
je crois que je vais abandonner windows sur Mac ....
 

ninkasi67

Membre émérite
24 Octobre 2016
760
32
47
strasbourg
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 486717952 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC

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

488397128 7

488397135 32 Sec GPT table

488397167 1 Sec GPT header
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
74 448
22 661
Forêt de Fontainebleau
:coucou: ninkasi

J'ai vu qu'il y avait eu pas mal de péripéties dans le fil parallèle que tu as créé. Pour en revenir au tableau retourné par gpt > tu notes qu'il confirme une PMBR (Protective_MBR) sur le bloc 0.

Rien ne s'oppose, théoriquement parlant, à ce que l'«Assistant BootCamp» t'installe Windows sur une partition créée ad hoc. S'il ne le fait pas > je ne peux pas le faire à sa place. Certains préfèrent tenter leur chance en démarrant sur un clé d'install de Windows, ce qui est loin d'être gagné comme te le montre l'exemple de ton précécesseur dans ce fil.
 

bergui45

Membre junior
19 Novembre 2008
17
0
J'ai lu sur macrumors que le MBPro mid 2012 (Ivy Bridge) ne gère pas bien Win10 en UEFI et qu'il faut du MBR et non du GPT!
Avec une clé USB d'installation j'ai pu installer en MBR Win10 sur un SSD externe dans un dock Thunderbolt.
Pour ce faire, j'avais déconnecté les 2 disques internes du MBPro... Résultat Windows boote nickel mais si je reconnecte les disques internes au Boot à la commande Option mon disque Windows est bien vu mais ça ne boote pas.
J'aimerais bien savoir comment modifier le boot loader pour que ça fonctionne, sans avoir à déconnecter les nappes internes...
Merci
 

Locke

What am I doing here?
Modérateur
Club MacG
20 Juillet 2011
34 681
4 021
Ca fonctionne avec Catalina et de l'USB-C/TB3 ?
Par défaut il est impossible de faire une installation directement dans un disque dur USB même en Thunderbolt. Il faut passer impérativement par une installation en interne puis utiliser Winclone pour faire un rétro clonage de la sauvegarde pour finir par supprimer la partition interne via Assistant Boot Camp. C'est ce que j'ai fait depuis depuis de nombreuses années dans un boîtier USB en Thunderbolt. Ça ne fonctionnera en aucun cas en voulant utiliser un boîtier USB 3.0 ou autre.
 

Locke

What am I doing here?
Modérateur
Club MacG
20 Juillet 2011
34 681
4 021