# Tuto: Installer BootCamp en externe (Thunderbolt uniquement)



## Moontyx (7 Janvier 2014)

Bonjour,

Après mainte et mainte recherches concernant l'installation d'un bootcamp sur un HDD externe, et la solution de BleepToBleep n'étant pas fonctionnel pour moi j'ai fait une belle trouvaille c'est pourquoi je souhaite vous la partager.

Cela concerne les supports de stockage :

- Thunderbolt
(Disque dur simple avec un convertisseur Goflex Sata => Thunderbolt)

 - L'usb n'est pour l'instant pas fonctionnel mais j'y travail.

Edit : après plusieurs recherches au sujet d'un boot de Windows 7 sous USB 3.0, les modifications ne sont pas viables avec BootCamp.  

Windows 8 Pro permet d'être utilisé via Windows To Go qui ne nécéssite pas d'installation BootCamp mais elle désactivera le Windows Store (néglibable) et l'utilisation des autres disques par défaut (modifiable).
c'est certes un peu cher Windows en USB, mais cela fait parti des solutions viable à l'heure d'aujourd'hui. 




La méthode est très simple :

Tout d'abord, téléchargez Winclone (freeware)=> Le lien <= (sur votre OS principale)

Si vous avez déjà une partition boot camp fonctionnel, c'est parfait.
Si non, il faut créer une partition boot camp sur l'HDD interne au Mac (nécessaire)

*1. *Préparer la partition -externe- de votre disque dur, de préférence plus de 25 Go (espace minimum réquis par BootCamp)

*2.* Démarrez sur Bootcamp -interne - et faite une vérification de la  partition, pour les erreurs de disque (F8 ou F10 sinon, allez dans les  outils de windows pour faire un rédémarrage avec vérification de la  partition)

*4. *Redémarrez sous Os X -interne- puis ouvrez winclone, et créez l'image  du système de bootcamp sur le disque dur interne (cela sauvegarde en  intégralité le disque dur BootCamp -interne- et même son BootMBR).

*5.* Après que Winclone ai fini de créer l'image de BootCamp -interne-, supprimez la partition Bootcamp -interne- de votre Mac. 
(étape  nécessaire car votre Mac ne fera aucune différence entre le MBR du  BootCamp -interne- et -externe- ce qui créera un conflit entre les deux  partitions car elles ont la même ID, donc le mac reconnaitra la partition interne par défaut) 

*6.* Rouvrez Winclone, et déployez l'image BootCamp sur la partition  externe de votre disque dur. 

Voilà votre partition BootCamp est finalisé, il ne vous reste plus qu'à essayer.

N'hésitez pas à donner votre expérience avec cette méthode !


----------



## RLeBavard (14 Février 2015)

C'est dommage que personne ne t'ai fait echo plus tôt. Ça m'aurait évité de changer de SSD pour avoir la place de loger les deux OS. Testé et approuvé avec mon ThunderBay 4. Mais ça reste galère d'utiliser le Thunderbolt (stockage) sous BootCamp (sur le SSD interne). Des idées pour éviter les blockages lors du boot et les pertes de connexion en sortie de veille ?


----------



## eryllion (14 Mars 2015)

*Merci pour l'info "Windows to Go" sur usb.*
J'ai installé Windows 8.1 comme ça sur un boitier externe usb3 (icy box) et un ssd crucial BX100.
Ca fonctionne bien.

Le disque dur interne Mac n'est pas visible (heureusement) mais mes autre disques externes sont visibles (si partitionné comme il faut).

La prochaine fois ce sera en thunderbolt.


----------



## Moontyx (6 Mai 2015)

RLeBavard a dit:


> C'est dommage que personne ne t'ai fait echo plus tôt. Ça m'aurait évité de changer de SSD pour avoir la place de loger les deux OS. Testé et approuvé avec mon ThunderBay 4. Mais ça reste galère d'utiliser le Thunderbolt (stockage) sous BootCamp (sur le SSD interne). Des idées pour éviter les blockages lors du boot et les pertes de connexion en sortie de veille ?



Quel problème rencontres tu sur le stockage, le boot et les sortie de veille ?



eryllion a dit:


> *Merci pour l'info "Windows to Go" sur usb.*
> J'ai installé Windows 8.1 comme ça sur un boitier externe usb3 (icy box) et un ssd crucial BX100.
> Ca fonctionne bien.
> 
> ...



Avec la methode de bleeptobleep ? Perso le disque dur interne mac est visible avec Paragon mais payant, et le heureusement est malheureusement pour moi puisque nativement il n'y a aucune possibilité, ni avec des drivers ni avec l'adaptation de logiciel libre d'utiliser plusieurs système de fichiers différents autre que ceux prévu pour le fonctionnement intrinsèque du systeme.


----------



## eryllion (12 Juin 2015)

La technique bleeptobleep ou équivalente, je l'avais testé et réussi avec windows 10 et hdd usb3.
Par contre le ssd externe ne fonctionnait pas avec cette méthode. A prioi c'était le uasp qui posait souci avec win10. 
J'avais un windows 8.1 entreprise (merci mon msdn) et j'ai pu installé en winToGO. Depuis cela fonctionne parfaitement et uasp est prise en compte vu les débits et le temps de boot.
J'essaierai ta méthode avec thunderbolt. Winclone semble pouvoir cloner vers un disque externe usb. As-tu essayer ?


----------



## Moontyx (19 Juillet 2015)

Non je n'ai pas essayé en usb, je suis resté sur mon thunderbolt et heureusement que j'ai trouvé cette méthode car le câble sata interne du mac à laché... depuis le thunderbolt fonctionne toujours parfaitement et c'est toujours stable sur les deux partitions.


----------



## eryllion (19 Juillet 2015)

Ok, de mon côté Windows 8.1 sur USB marche aussi.
Je dois m'acheter prochainement un autre gros ssd à mettre en externe, je testerai WinClone et d'autre méthode aussi. L'adaptateur GoFlex m'intéresse aussi et ton tuto me sera utile.


----------



## snd4 (30 Juillet 2015)

Merci moontyx pour ton message ta solution est parfaite 

Je viens d'acheter un adaptateur goflex thunderbolt pour mettre windows sur un SSD

J'ai 2 questions :

1) Quand je serai sur windows 7 en externe est ce que je pourrai accéder aux fichiers du disque dur interne ou il y aura OSX ? (en utilisant paragon)

2) Quand on utilise Mavericks ou yosemite on est obligé de prendre la version payante de Winclone ?

Merci.


----------



## Moontyx (30 Juillet 2015)

Salut,

Alors pour les accès à la partition Os X depuis Windows, c'est le même fonctionnement qu'une partition bootcamp donc non. Il te faut un programme tiers qui te permette de lire le systeme de fichier HFS sur Windows.

Pour l'utilisation de winclone, oui tu sera obligé d'utiliser au moins la version "basic", désolé je n'ai pas mentionné que cela était payant car j'ai utilisé la version du boulot.


----------



## snd4 (7 Août 2015)

Merci pour ton message Moontyx 

Je vais bientôt faire l'installation (j'ai pas eu le temps ces derniers jours)

Je me demande un truc :

Le SSD externe une fois formaté dispose de 464go de libre donc, concernant la partition interne qu'il faudra cloner, est-ce que je peux faire une partition bootcamp windows interne de 464go ?

Ou il faut faire un peu moins ?

Merci


----------



## bergui45 (27 Août 2015)

J'ai un MBPro 15" mid 2012
J'ai un Bootcamp sur le sata interne en Win10 et Mac Yosemite sur un SSD dans l'optique baie.
J'ai suivi le tuto: winclone5 pour faire l'image et restaurer l'image dans mon disque dur externalisé dans une baie Thunderbolt Rocketstor 5212
j'ai viré le disque interne contenant Bootcamp et essayer de Booter du Thunderbolt
;-( Oualou!
Si je demande à Winclone de rendre le disque EFI_Bootable, le disque n'est pas vu au Boot en appuyant sur ALT
Il est vu en Legacy Mode mais là j'ai le -- au Boot ou Error system
Bref c'est la Me...
@+
Bernard


----------



## AngryKiller (19 Octobre 2015)

J'ai OS X El Capitan et j'ai voulu faire la manip avec Windows 10.

Tout va bien jusqu'a ce que je fasse la manip pour "dupliquer" la partition BOOTCAMP du dd interne sur la partition du dd externe

car lorsque que je veut booter sur windows sur le dd externe si je choisis la partition nommée "Windows" au menu alt sa me met une erreur me disant qu'il ne trouve pas le fichier C:/System32/Winboot.efi et si je choisis la partition EFI Boot sa démarre mais sa met un BSOD me disant INACCESSIBLE_USB_DEVICE

Donc je ne sais plus comment faire.


----------



## asus27 (5 Novembre 2015)

Bonjour,

J'ai utilisé cette méthode et tout fonctionne très bien. Mais, car il y a un mais, je suis avec Windows 10 et lorsque que je souhaite faire la mise a jour des drivers Bootcamp sortis le mois dernier, je n arrive pas à finaliser l'installation me disant qu'il manque un fichier...

Avez vous eu des problèmes pour installer les drivers Bootcamp pour Windows 10?

Merci


----------



## Moontyx (22 Février 2016)

AngryKiller a dit:


> J'ai OS X El Capitan et j'ai voulu faire la manip avec Windows 10.
> 
> Tout va bien jusqu'a ce que je fasse la manip pour "dupliquer" la partition BOOTCAMP du dd interne sur la partition du dd externe
> 
> ...



Tout à fait normal puisque le tuto est prévu uniquement pour du "Thunderbolt" et pas d'USB !


----------



## Moontyx (22 Février 2016)

bergui45 a dit:


> J'ai un MBPro 15" mid 2012
> J'ai un Bootcamp sur le sata interne en Win10 et Mac Yosemite sur un SSD dans l'optique baie.
> J'ai suivi le tuto: winclone5 pour faire l'image et restaurer l'image dans mon disque dur externalisé dans une baie Thunderbolt Rocketstor 5212
> j'ai viré le disque interne contenant Bootcamp et essayer de Booter du Thunderbolt
> ...



En toute logique pas besoin de le rendre EFI Bootable puisque la partition MBR/EFI est déjà créé... donc tu à flingué ta partition... désolé pour toi :s


----------



## asus27 (24 Février 2016)

Bonjour Moontyx

J' ai donc effectué la migration de bootcamp vers mon disque SSD externe en Thunderbolt et tout va bien  Je boot normalement bref je te remercie pour ton tuto.
J' ai effectué la mise a jour vers windows 10 et j' ai voulu installer les drivers Apple prévus pour cette version. Il est la le probleme...

Que je télécharge via Apple software update ou via le site d' Apple ces drivers (6.0.....) j' ai le message suivant :
"Dossier $WinPEDriver$ introuvable. Vérifiez que le dossier $WinPEDriver$ se trouve au meme emplacement que le dossier BootCamp et retentez l' installation" ....

Je pense que c' est du au fait que j' ai effacé la partition Bootcamp comme prevu dans ton tuto. As tu une solution a ce probleme?

Merci

Fab


----------



## Moontyx (25 Février 2016)

asus27 a dit:


> Bonjour Moontyx
> 
> J' ai donc effectué la migration de bootcamp vers mon disque SSD externe en Thunderbolt et tout va bien  Je boot normalement bref je te remercie pour ton tuto.
> J' ai effectué la mise a jour vers windows 10 et j' ai voulu installer les drivers Apple prévus pour cette version. Il est la le probleme...
> ...



Je peux pas te dire puisque windows 10 est un tout nouvel os donc rien à avoir avec la migration en externe du windows.
De plus tout dépend de ton mac, si tout est à jour de ton côté.
As tu essayé d'installer les drivers en mode administrateur ?

Le mieux que tu aurais à faire c'est de migrer vers windows 10 sur le hdd interne du mac puis de transferer la partition sur le ssd externe


----------



## asus27 (28 Février 2016)

Bonjour moontyx 

Alors oui mon ordi est à jour, installer les drivers en mode administrateur ne fonctionne pas plus malheureusement.

Une idée? Je pense que ce dossier est installé lors de la présence de Bootcamp. Ayant donc supprimé ce logiciel lors du transfert, je pense que le problème vient de la.

Fab


----------



## Moontyx (4 Mars 2016)

Bah non puisque rien n'est installé par l'utilitaire bootcamp. De plus tu n'a pas l'air d'avoir tout lu ce que j'ai écrit plus haut. Je te conseil de reprendre tout a zéro, installation de windows 10 (même si c'est de la merde)  en disque interne puis transfert vers le disque externe.


----------



## asus27 (7 Mars 2016)

Bonjour

Oui j'ai bien lu tes conseils néanmoins je veux éviter de tout refaire. S'il n'y a pas d'autre solution cela restera comme ça!


----------



## Mazelles (26 Avril 2016)

Bonjour.  Grande déception : pour moi, ça ne marche pas... ( Win 10 )

- à l'étape 4 : j'ai fait l'image du système Boot Camp du disque interne, avec Winclone "Standard", sur un disque externe, faute de place sur le disque interne préconisé par le tuto. Cela peut-il avoir un effet pervers ?

- après l'étape 6,  et redémarrage final  avec touche "ALT" pour choisir de démarrer sur Boot Camp, la partition sur laquelle est installée la nouvelle partition de Boot Camp n'est pas détectée. 
Apparait une partition nommée simplement "Windows" . Et un message d'erreur :  "OXc0000225"... / PC needs to be repaire ... /use recovery tools ... /don't have any installation media" ... / 

Quelqu'un voit-il une solution ?  Merci.  Cordialement.  M.


----------



## Moontyx (26 Avril 2016)

Mazelles a dit:


> Bonjour.  Grande déception : pour moi, ça ne marche pas... ( Win 10 )
> 
> - à l'étape 4 : j'ai fait l'image du système Boot Camp du disque interne, avec Winclone "Standard", sur un disque externe, faute de place sur le disque interne préconisé par le tuto. Cela peut-il avoir un effet pervers ?



Oui, si tu es en USB et pas en Thunderbolt comme cité explicitement au début du tuto, de plus il est toujours conseillé de faire une copie fonctionnel du Windows.



Mazelles a dit:


> - après l'étape 6,  et redémarrage final  avec touche "ALT" pour choisir de démarrer sur Boot Camp, la partition sur laquelle est installée la nouvelle partition de Boot Camp n'est pas détectée.
> Apparait une partition nommée simplement "Windows" . Et un message d'erreur :  "OXc0000225"... / PC needs to be repaire ... /use recovery tools ... /don't have any installation media" ... /
> 
> Quelqu'un voit-il une solution ?  Merci.  Cordialement.  M.



Malheureusement Windows 10 à beaucoup changé depuis Windows 8.1, je ne peux pas t'aider car je n'ai pas migré et je ne compte pas migrer vers Windows 10.

Cela me parait louche qui Winclone n'arrive pas à faire une copie parfaite de la partition, est-une installation neuve ou ancienne de Windows 10 ? était-elle parfaitement fonctionnelle ? 

Cela peut tout à fait venir de ton USB qui n'est pas prévu pour fonctionner ainsi par limitation technique des systèmes Windaube contrairement à Linux et Os X, désolé.


----------



## Mazelles (26 Avril 2016)

Moontyx a dit:


> Oui, si tu es en USB et pas en Thunderbolt comme cité explicitement au début du tuto, de plus il est toujours conseillé de faire une copie fonctionnel du Windows.
> 
> 
> 
> ...




Merci pour cet avis.

La partition Windows 10 était neuve et fonctionnelle. Et l'USB n'est pas en cause, puisque j'ai migré BootCamp sur un disque externe Thunderbolt.

Mais je commence à avoir une idée sur la cause du problème. Ce n'est  probablement pas Winclone qui a mal fait son travail.  C'est plus probablement moi qui ai fait une vraie bourde...

A l'étape 5, après  avoir créé l'image de BootCamp, il fallait supprimer la partition BootCamp du disque interne : " Pour que le Mac ne  s'égare pas entre les deux MBR de BootCamp" ( interne et externe ; initiale et nouvelle ).  Sinon, explique bien le tuto, le Mac reconnaîtra encore la partition interne ( ancienne ) par défaut.

La bourde, c'est sans doute d'avoir supprimé la partition de BootCamp "à la hache" : avec l'utilitaire de disque ! Au lieu de la désinstaller proprement avec l'Utilitaire BootCamp. Ce qui ne m'est pa venu à l'idée à ce moment là...

Avec la méthode brutale, certains fichiers de l'ancien BootCamp ne sont pas probablement pas supprimés, il reste des partitions EFI "trompeuses", le Mac détecte quand même deux partitions bootable, et tente de démarrer sur l'interne (pourtant supprimée).

Heureusement, j'avais lancé juste avant une sauvegarde Time Machine. Je suis en train de restaurer le disque interne complet du Mac, BootCamp compris, pour reprendre le tuto à zéro, et supprimer cette fois la partition avec la méthode douce.

Il aurait même mieux valu formater avant le disque pour une installation plus "clean".
J'essaie comme ça, et je donne le résultat.


----------



## macomaniac (29 Avril 2016)

Salut *Mazelles
*


Mazelles a dit:


> Avec la méthode brutale, certains fichiers de l'ancien BootCamp ne sont pas probablement pas supprimés, il reste des partitions EFI "trompeuses", le Mac détecte quand même deux partitions bootable, et tente de démarrer sur l'interne (pourtant supprimée).



Cette question m'intéresse - théoriquement parlant (comme elle t'importe - pratiquement parlant).

Est-ce que tu peux aller à : _Applications/Utilitaires_ pour lancer le «Terminal» ? Dans la fenêtre qui s'affiche, passe la commande (purement informative : n'agit qu'en mode lecture_seule) :

```
sudo gpt show /dev/disk0
```
 et ↩︎ (presse 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  ↩︎ => en retour, tu vas voir s'afficher le tableau de l'allocation des blocs sur ton disque interne (*disk0* ou premier disque), dont la désignation des tables de partitions inscrites sur le *secteur de boot* (la série de blocs de tête) => peux-tu faire un copier-coller de ce tableau ici ?

*- a)* Si jamais tu avais ceci en tête de tableau :

```
gpt show: /dev/disk0: Suspicious MBR at sector 0
    start     size  index  contents
        0        1         MBR
```
 alors tout serait dit : cela voudrait dire qu'une table de partition alternative de la *GPT* des 32 premiers blocs existe sur le *secteur 0* : à savoir une *Hybrid MBR* (désignée ici comme : "*suspicious MBR*"), dont la caractéristique est d'intégrer dans sa carte de partition la description de partitions localisées, dont une avec un "*bootable_flag*" (un attribut de "démarrabilité") = une partition dédiée à Windows.

*- b)* Si par contre il n'était pas déclaré de "*Suspicious MBR at sector 0*", cela voudrait dire que la table de partition *MBR* inscrite sur le *secteur 0* ne serait qu'une *Protective MBR*, càd. une *MBR* dont la carte de partition n'inclut pas la description de partitions localisées, mais est conforme au "default" d'une mono-partition mappant l'ensemble des blocs du disque => ce type de *Protective MBR* double toujours régulièrement sur le *secteur 0* du disque la *GPT* des 32 premiers blocs, afin de protéger cette dernière contre l'intrusion de Systèmes d'exploitation non-Apple ou encore de programmes d'installation externes non-Apple (elle a donc un simple rôle de tampon, et absolument pas de description d'une partition bootable localisée comme l'*Hybrid MBR*).​
=> si ce qui ressortait dans ton tableau était le cas de figure *a)*, il conviendrait alors de re-convertir (indolore, mais technique) l'*Hybrid_MBR* (= "*Suspicious MBR*") du *secteur 0* en *Protective MBR* (ce qui ferait disparaître la description d'une partition Windows bootable sur le *disk0*) ; si c'était le cas de figure *b)* = rien qu'une *Protective MBR* par défaut, alors il faudrait chercher un autre facteur explicatif de ton problème : une partition invisible (graphiquement) sur ton disque, en-dessous de la «Recovery HD» ?


----------



## Locke (29 Avril 2016)

macomaniac a dit:


> Cette question m'intéresse - théoriquement parlant (comme elle t'importe - pratiquement parlant).


Moi aussi, je serais curieux d'en apprendre plus.


----------



## Mazelles (2 Mai 2016)

Salut,
Je n'ai guère de compétences en la matière, mais j'essaie de répondre quand même :
La procédure indiquée me donne ( une semaine plus tard ) : 
  start       size  index  contents

          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
        34          6         

donc "Protective MBR" . Et là j'ai épuisé mon niveau de compétence.
Sauf si la suite continue à t'intéresser...
Cordialement.
M


----------



## macomaniac (3 Mai 2016)

Contrairement à ma conjecture d'une "*Hybrid MBR*", tu as donc actuellement une "*Protective MBR*" tout ce qu'il y a de standard et d'inoffensif sur le secteur *0* de ton disque interne. 

Mais étant donné que tu annonçais de grandes manœuvres : récupération d'une sauvegarde TimeMachine, recréation d'une partition BootCamp puis sa suppression réglementaire par le même logiciel - au moment où tu as passé la commande, ton problème était peut-être déjà résolu => est-ce le cas ?


----------



## Mazelles (3 Mai 2016)

Dans le domaine du  Mac / loisirs, les grandes manœuvres que j’entreprends parfois sont un peu comme les velléités des politiques : l’ambition y excède largement l’expertise… Mais mon Mac ne soûle a priori personne.

Je voulais essayer d’installer la partition BootCamp *sur un disque externe Thunderbolt*, ce qui est l’objet du tuto.

Time Machine, à ma connaissance, ne permet pas de sauvegarder la partition BootCamp du disque dur (interne). J’ai donc réalisé la sauvegarde de BootCamp avec Winclone. Classique.

Et c'est là que les ennuis ont commencé : au moment de transférer la sauvegarde sur le disque externe Th., formaté préalablement en NTFS, Winclone ne le « voyait » pas !. J’ai demandé une aide au support de Winclone, qui a vu de suite l’explication : pour réinstaller une sauvegarde, Winclone ne doit trouver qu’une seule partition NTFS sur l’ensemble des disques, sinon il ne sait pas gérer.

Je découvre alors que mon disque dur interne comporte deux mini partitions en NTFS, d’environ 470 Mo, appelées « Windows ??? » ( je ne  me souviens plus exactement ; peut-être « Win. Récupération »), probablement créées par le système avec la partition BootCamp. Je *ne parviens pas* à les supprimer avec l’utilitaire de disques, car *les commandes sont grisées et inactives*. A défaut de les supprimer, j’essaie de les formater autrement qu’en NTFS, pour qu’elles ne parasitent  plus Winclone, et je n’y parviens pas davantage, pour la même raison.

Je soumets donc cette question surprenante au Support Apple. Le premier « Advisor » en reste baba. Il me passe son « Supervisor », qui me demande d’accéder à mon Mac. J’accepte. Finalement il échoue lui aussi ; puis pense à un utilitaire tiers à tester d’abord (par ses soins) pour que je ne risque pas de perde le contenu de mon disque. Et déclare finalement qu’il doit soumettre le problème à un ingénieur ! ( peut-être à Tim Cook ? ) ? Cela fait au moins une semaine, et je n’ai toujours pas de réponse ; je viens de relancer ce matin…. Donc mon "ambition" est en stand by.

Après l’échec de Winclone, je pensais éventuellement recourir à True Image (Mac) pour effectuer et transférer une sauvegarde de BootCamp. Ce que True Image sait faire. Mais mon Mac ne peut pas booter sur cette sauvegarde externe, et je n’en connais pas non plus la raison. Parce que la sauvegarde est défectueuse ? Parce que les sauvegardes True Image *ne peuvent pas* être bootables ? etc. Si quelqu’un a une idée…

J’ai tenté aussi avec Carbon Copie Cloner (CCC), mais en vain : « CCC ne peut pas faire la sauvegarde bootable d'une partition Windows. Vous pouvez copier des éléments non-système à partir d'un volume de Windows, mais il y a des obstacles logistiques et techniques liées à la copie de fichiers système de Windows ». ( support Bombich SoftWare, éditeur de CCC).

Autre contournement tenté : puisque je suis en panne avec le disque dur d'un iMac, et en attendant la solution d’Apple, j’essaie, de nouveau avec Winclone, de faire la copie de BootCamp sur un disque externe Th., mais cette fois avec un MacBook Pro 13  de fin 2015. *Normalement, ça marche, foi de support* !


Cinq ou six essais vains : parfois la procédure va à son terme, mais au démarrage du Mac (avec « Alt »), le choix « Windows » donne un écran bleu ; erreur 0xc0000225 » ; ou l’image « est trop grosse pour la partition », ce qui est faux ; etc. ; ou le tuto de l’éditeur, en anglais, est insuffisamment précis ? …

Et voilà comment je suis toujours en panne. Et peut-être d’autres aussi ?

Cordialement.  M.


----------



## r e m y (3 Mai 2016)

C'est étonnant car WinClone permet de transférer facilement une image d'une partition BootCamp vers un disque quel qu'il soit (interne ou externe)

Par contre il faut:
1 - que le disque ou la partition de destination soit formatté en FAT32 (c'est WinClone qui se charge de la passer en NTFS)
2- que ce disque ou partition ait une taille de quelques Go de plus que le volume BootCamp que WinClone a copié pour constituer l'image disque servant de source.

Accessoirement WinClone peut faire en une seule étape la copie de la partition BootCamp interne vers un disque externe formatté en FAT32 (et table de partition GUID)


----------



## macomaniac (3 Mai 2016)

Salut *Mazelles
*
Quand je lis le compte-rendu de tels _pataquès_ - je ne peux que me réjouir de me sentir (personnellement) aussi concerné par Windows que par l'apprentissage des _Runes   _





En ce qui concerne le disque interne de ton Mac, il arrive que des installations de Windows, au lieu d'être "mono-partitionnées" (une seule partition *BOOTCAMP*), soient "tri-partitionnées" => quelque chose du style :

```
4: EFI NO NAME             104.9 MB   disk0s4
5: Microsoft Reserved      134.2 MB   disk0s5
6: Microsoft Basic Data    XXX.X GB   disk0s6
```
 (la partition *1: disk0s1* étant la *EFI* de 209 Mo régulière de la *Table de Partition GUID *;  la* 2: disk0s2* étant la partition principale d'OS X et la *3: disk0s3* étant la partition de récupération «Recovery HD» de 650 Mo) => tu remarqueras qu'il y a effectivement dans ce cas de figure 2 "mini-partitions" (*5* & *6*) précédant la partition majeure (*6*) constenant l'OS Windows. Je conjecture que la *EFI NO NAME* (*5*) est une espèce de réplique *MBR* de la partition de démarrage *EFI* (*1*) de la *Table de Partition GUID*.

Si tu as eu (et éventuellement a toujours) sur ton disque ce type de partitions (invisibles graphiquement), nul doute que ce serait là une des racines de tes ennuis. Afin de le vérifier, relance le «Terminal» et passe la commande (purement informative = n'opère qu'en lecture seule des tables de partitions) :

```
diskutil list
```
 et ↩︎ => peux-tu poster le tableau retourné ici (en copier-coller) ? - Je pourrais te dire si tu as encore des partitions parasites, et si c'était le cas, comment les supprimer et récupérer leur espace à la partition de ton OS.

--------------------​Pour ce qui est de Winclone, je sais que, lorsqu'il s'agit de rétro-cloner une image-archive *Win.winclone* à une partition du disque interne créée _ad hoc_ au préalable, le requisit est que cette partition d'accueil doit être au format initial *MS-DOS* (*FAT-32*) et pas du tout dans un format initial *NTFS* - «Winclone» se chargeant de re-formater en *NTFS* la partition en question.

Pourquoi n'essaies-tu pas ce procédé ? Débrouille-toi pour avoir le disque global de ton DDE en *Table de Partition GUID*, et la partition principale au format *FAT-32* (si tu es sous «El Capitan», dans l'«Utilitaire de Disque» tu sélectionnes le disque global de ton DDE avec le menu "_Effacer_" et tu peux choisir d'une part la table de partition et d'autre part le format).


PS. Quelle est la taille globale (en Go) du disque externe sur lequel tu cherches à installer ton «Windows« ?


----------



## Moontyx (8 Mai 2016)

Salut,
effectivement depuis même Windows 8, les caractéristiques Boot MBR et GPT partition on fait un peu capoté mon tuto dont je ne m'étais pas rendu compte... je ne peux plus éditer mon message... j'enverrais un message aux modos.
La méthode la plus simple serait surement de passer autrement que par l'utilitaire Bootcamp ?
De faire une clé usb bootable pour l'installation, d'insérer le disque dur "externe" en "interne" puis de faire l'installation pour repasser le disque dur externe en "thunderbolt" et de tester par la suite pour éviter l'étape de transfert de partition ?


----------



## Mazelles (8 Mai 2016)

macomaniac a dit:


> Salut *Mazelles
> *
> Quand je lis le compte-rendu de tels _pataquès_ - je ne peux que me réjouir de me sentir (personnellement) aussi concerné par Windows que par l'apprentissage des _Runes   _
> 
> ...





Salut Macomaniac,

1.  S’agissant des partitions « parasites » sur le disque dur, le support Apple m’avait effectivement indiqué qu’il s’agissait « probablement » de partitions « annexes » créées lors de créations de partitions Boot camp. Le problème c’est aussi qu’Apple ne sache pas me dire comment les supprimer (rappel du message initial : les commandes habituelles, grisées, semblent inaccessibles). Ni d’ailleurs comment le formater autrement. Plus personne au bout du fil…

Voilà ce que j’obtiens sous Terminal :

  #:  TYPE NAME  SIZE  IDENTIFIER

  0:  GUID_partition_scheme  *500.3 GB  disk0

  1:  EFI EFI  209.7 MB  disk0s1

  2:  Apple_HFS  iMac 27  419.0 GB  disk0s2

  3:  Apple_Boot Recovery HD  650.0 MB  disk0s3

  4:  Microsoft Basic Data BOOTCAMP  79.5 GB  disk0s4

  5:  Windows Recovery  471.9 MB  disk0s5

  6:  Windows Recovery  471.9 MB  disk0s6

Effectivement, deux partitions « Windows Recovery » de 471 MB ( partitions 5 et 6 ).

Merci par avance de ton aide.


2.  S’agissant de Winclone, j’essaierai le procédé indiqué (format). Mais avant, je dois régler un autre problème pour lequel une solution semblait se profiler…

Mon message du 26 avril indiquait que le tuto d’installation de Windows 10 conduisait ( dans le meilleur des cas ) à un « écran bleu » à la place de Boot Camp, au lancement : avec un message d’erreur : "OXc0000225"... / PC needs to be repaired ... /use recovery tools ... /don't have any installation media" ... / etc.

Le Support de WinClone m’en a donné l’explication, et la solution ( en anglais, traduction approximative de mon cru…) :

« « Cette erreur au démarrage (0xc0000225) est courante quand le pilote de stockage installé dans Windows n'est pas compatible avec la puce de stockage et de contrôle (ou le contrôleur ?) du nouveau  lecteur externe d’accueil. »

« En migrant Windows, vous devez *prendre en compte les différences de matériel* qui peuvent être à l’origine des problèmes :


- Le Mac accepte-t-il le démarrage de Windows en externe ? S'il est de *2013 ou ultérieur, il l’accepte* effectivement.

( c’est mon cas, début 2015 ) ;

- La version de Windows peut-elle démarrer sur un disque externe ? Si c'est *Windows 8.1 ou 10, elle peut* démarrer sur un lecteur externe. ( O.K. )


- Les pilotes de l’appareil peuvent-ils être remplacés ? C'est la *cause probable de l'erreur de démarrage. »*


« Windows inclut *l'utilitaire Sysprep *dans chaque version, et celui-ci peut être utilisé pour remplacer des pilotes d’appareils dans Windows…. »

Suit un tuto pour faire le nécessaire sous Sysprep. Peut-être un peu long pour tout publier ici, mais j’ai un document Word de 38 pages qui reprend toute la démarche du tuto (de Moontyx) , avec copies d’écrans… ( depuis l’objectif d’installer Boot Camp en externe, jusqu’aux manip. Sysprep).

Je croyais être sorti d’affaire. Mais un message d’erreur me dit que « Sysprep n’a pas pu valider votre installation de Windows » ; et me renvoie vers un fichier journal sur :  Windows / System32 / Sysprep / Panther / setupact.log. Où j’apprends, au milieu d’une centaine de lignes de code hermétique (pour moi) que « Sysprep will not run on an upgraded OS. You can only run Sysprep on a custom (clean) install version of Windows » ? En somme que Sysprep ne marche pas avec une version upgradée de Windows. Mais seulement avec une version nativement installée ( achetée en tant que Windows 10). Effectivement, les miennes sont toutes des versions upgradées de Windows 8 ou 8.1.


3.  Enfin, pour répondre à ta dernière question, le disque externe sur lequel je souhaitais installer Windows est un SSD de 500 Go. Je venais de faire une affaire ( ?) : un SSD Samsung Série 850 EVO - 500 Go 2,5" SATA III (pour 159 Euros) chez Mac Way, qui devait doubler (de volume) le SSD interne de mon MacBook. Avec un adaptateur Sata / Thunderbolt, j’espérais que ça ne ramerait pas trop… Mais c’est moi qui rame !...

Merci à tous. J’espère que mon odyssée vous inspirera… et que les solutions vont pleuvoir !

Cordialement.


----------



## Moontyx (8 Mai 2016)

Mazelles a dit:


> Salut Macomaniac,
> 
> 1.  S’agissant des partitions « parasites » sur le disque dur, le support Apple m’avait effectivement indiqué qu’il s’agissait « probablement » de partitions « annexes » créées lors de créations de partitions Boot camp. Le problème c’est aussi qu’Apple ne sache pas me dire comment les supprimer (rappel du message initial : les commandes habituelles, grisées, semblent inaccessibles). Ni d’ailleurs comment le formater autrement. Plus personne au bout du fil…
> 
> ...



Je penses que tu te prend trop la tête, d'ailleurs bootcamp ne créer qu'une seule et même partition de base en NTFS pour que Windows la reconnaisse (ce qui n'est pas toujours le cas...).

Le reste des partitions sont créés par Windows lui même qui à la même manière de Os X s'en sert pour du recovery et depuis Windows 8 pour faire chier le boot notamment avec le Boot Secure des BIOS UEFI.

Bref, ce qui serait le plus facile pour toi, c'est de faire installation propre à partir de ton SSD 500 go en le connectant sur la nappe SATA intérieur du MAC. Puis une fois l'installation fini, le replacer dans ton boitier Thunderbolt et transvaser tout tes documents et application à partir de la copie de ta partition.


----------



## macomaniac (8 Mai 2016)

Salut *Mazelles
*
Je réponds spéciquement en ce qui concerne le partitionnement de ton disque interne - *Moontyx* étant plus compétent que moi en ce qui concerne la question «Windows» =>

Tu as effectivement 2 partitions *Windows Recovery* parasites. Mais pour ce qui est de gérer leur [suppression / réallocation de l'espace], la question décisive est : est-ce que tu tiens à conserver ton actuelle partition *4: Microsoft Basic Data BOOTCAMP 79.5 GB disk0s4* ou non ?

--------------------​
Je te pose cette question, pour la raison suivante : je peux très bien te donner 2 commandes à passer dans le «Terminal» qui vont supprimer sans problème les 2 partitions : *5: Windows Recovery 471.9 MB disk0s5* & *6: Windows Recovery 471.9 MB disk0s6*. « Supprimer » signifiant effacer leur *système de fichiers* gestionnaire, ce qui va avoir comme résultat que les espaces correspondants n'auront plus un statut de partitions (définies dans la *GPT* de l'en-tête du disque), mais un statut d'espace libre (*free_space*) hors tableau de partition.

Mais aussi longtemps qu'une partition *4: Microsoft Basic Data BOOTCAMP 79.5 GB disk0s4* s'intercalera entre la partition *2: Apple_HFS iMac 27 419.0 GB disk0s2* d'OS X et cette bande d'espace libéré située en queue de disque, il sera impossible de récupérer l'espace libre en question à la partition de l'OS. Ce qui va te faire 2 x 471 Mo dans la nature...

[la raison pour laquelle cette récupération est impossible, est que l'espace du disque est défini comme une suite continue de blocs numérotés de *1* à *n* dans la table de partition *GPT*, chaque partition correspondant à une série linéaire de ces blocs, et que cet ordre numérique est essentiel pour les questions de re-dimensionnement des partitions => il est possible d'intégrer des blocs situés en-dessous - numéralement parlant - d'une partition à cette partition, seulement si aucune autre partition n'est intercalée sur le chemin, à l'exclusion d'une partition de type *Apple_Boot Recovery HD*, car l'utilitaire *diskutil* sait, dans ce cas de figure unique, gérer le déplacement de cette partition sur les blocs].

--------------------​
- Si ça ne te fait rien de supprimer la partition *4: Microsoft Basic Data BOOTCAMP 79.5 GB disk0s4*, alors pas de problème en vue : il suffit de supprimer les 3 partitions *4*, *5* & *6*, puis de ré-intégrer leur espace libre continu (numéralement parlant) à la partition de l'OS.

- Si tu tiens à conserver la partition *4: Microsoft Basic Data BOOTCAMP 79.5 GB disk0s4*, alors soit il suffit de supprimer les 2 partitions *5* & *6* et de laisser leurs blocs au statut d'espace libre (= perdu : presque 1 Go) ; soit, grâce à «Winclone», tu fais une image-archive *Win.winclone* de l'OS «Windows» de cette partition => on supprime les 3 partitions : *4*, *5* & *6* et on récupère leur espace libéré à la partition n°*2* de l'OS => tu recrées une partition *FAT-32* unique => tu demandes à «Winclone» de te rétro-cloner un «Windows» démarrable sur ta néo-partition unique.

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


----------



## bergui45 (17 Juin 2016)

Moontyx a dit:


> Je peux pas te dire puisque windows 10 est un tout nouvel os donc rien à avoir avec la migration en externe du windows.
> De plus tout dépend de ton mac, si tout est à jour de ton côté.
> As tu essayé d'installer les drivers en mode administrateur ?
> 
> Le mieux que tu aurais à faire c'est de migrer vers windows 10 sur le hdd interne du mac puis de transferer la partition sur le ssd externe


ben c'est facile:
il faut copier le dossier des drivers Bootcamp dans le dossier "download" de ton windows 10 et ensuite tu fais  setup.exe!
ce transfert de fichiers peut se faire depuis le bureau de MacOs vers Windows grâce à un utilitaire qui permet de lire du NTFS depuis MacOs. 
Chez moi sur un Bootcamp (Mbr) sur la partition interne il s'est avéré impossible de mettre à jour vers Windows 10 Threshold2 qui implémente des drivers optimisés pour la gestion du Thunderbolt.
J'ai donc sans commencer avec bootcamp, pu avec une clé USB d'installation avec l'iso de Win10Threshold2 reussir une installation complète en EFI/Boot. Ensuite installation des drivers Bootcamp depuis le directory Download de Windows et ça fonctionne jusqu'au bout. Il n'y a plus de bug vidéo mais pour une raison que j'ignore, ça n'est pas stable puisque ça reboote rapidement pour faire une réparation automatique et ça recommence...
Je vais refaire le même plan d'installation en Mbr pour voir si c'est plus stable.
Dommage car l'EFI/Boot c'est plus moderne que l'antique émulation d'un BIOS avec MBR...


----------



## bergui45 (17 Juin 2016)

Moontyx a dit:


> Salut,
> effectivement depuis même Windows 8, les caractéristiques Boot MBR et GPT partition on fait un peu capoté mon tuto dont je ne m'étais pas rendu compte... je ne peux plus éditer mon message... j'enverrais un message aux modos.
> La méthode la plus simple serait surement de passer autrement que par l'utilitaire Bootcamp ?
> De faire une clé usb bootable pour l'installation, d'insérer le disque dur "externe" en "interne" puis de faire l'installation pour repasser le disque dur externe en "thunderbolt" et de tester par la suite pour éviter l'étape de transfert de partition ?


j'ai testé cette manip et ça ne marche pas pour Windows alors que ça marche pour déplacer un OSX!


----------



## bergui45 (17 Juin 2016)

Bon j'ai testé SUDO GPT:
MBPdeBG:~ bxxxxgyyyy$ sudo gpt show /dev/disk0
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  1951844440  2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  1952254080  1269536  3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1953523616  1519   
  1953525135  32  Sec GPT table
  1953525167  1  Sec GPT header


----------



## macomaniac (17 Juin 2016)

*bergui
*
Ta répartition de blocs est propre comme un sou neuf 
	

	
	
		
		

		
		
	


	




- sur le bloc 1, tu as une *Protective MBR*
- sur les blocs 1-32, ta *GPT *
- une micro bande de  *free_space* (6 blocs)
- sur les blocs 40 > 409639 (= 209 MB) ta première partition *disk0s1 ESP* (EFI System Partition)
- sur les blocs 409640 > 1952254079 (= 999 GB) ta deuxième partition *disk0s2 Macintosh HD*
- sur les blocs 1952254080 > 1953523615 (= 650 MB) ta troisième partition *disk0s3 Recovery HD*
- une petite bande de *free_space* de 1519 blocs (0.7 MB)
- sur les 32 derniers blocs, le *backup* de la GPT.​
=> RAS.


----------



## fl0rian67 (10 Octobre 2016)

Bonjour à tous,

Je suis nouveau sur le forum. Je vous explique rapidement le contexte avant de vous parler de mon soucis :
Je viens d'acquérir un iMac 27" fin 2013 occasion. L'ancien propriétaire a remplacé le HDD du fusion drive par un SSD Crucial de 1 To pour pouvoir installer Windows sur un SSD et ainsi avoir un OS rapide.

Avec Bootcamp, Windows ne s’installe que sur le disque système du Mac et j’aimerais l’installer sur le SSD mais pendant l’installation de Windows à l’étape « Où voulez-vous installer Windows ? » la partition Bootcamp ne se détecte pas.

J’ai un peu cherché comment faire sur les forums mais je n'ai pas vraiment trouvé, il y a des sujets avec Winclone mais je crois que c'est plus pour les disques durs externes. Moi c'est un disque interne, mais " secondaire ". J'ai aussi demandé à l'ancien proprio mais il ne m'a pas répondu.

Après avoir quitté l’installation de Windows, MacOS boot correctement et Bootcamp est visible dans l’utilitaire de disque. Je me demande s’il ne faut pas le formater en NTFS vu que là il est en FAT32.

Merci d'avance à ceux qui essaieront de m'aider


----------



## macomaniac (10 Octobre 2016)

Salut *fl0rian
*
Je te conseille d'aller à : _Applications_ > _Utilitaires_ > pour lancer le «Terminal». Dans la fenêtre qui s'affiche, saisis l'une après l'autre les 2 commandes (simplement informatives) que je te liste ensemble dans un même panneau :

```
diskutil list
diskutil cs list
```
 et ↩︎ (presse la touche "_Entrée_" du clavier après chaque commande pour l'activer).

- la 1ère va te retourner le tableau des disques attachés à ton Mac (en interne / externe) > avec leurs tables de partition > et leurs partitions décrites en format > nom > taille > device (appareil logique).

- la 2è le tableau d'un *Groupe de Volumes Logiques* > si tu as un format *CoreStorage* sur la partition de l'OS.​
=> peux-tu poster ce ou ces 2 tableaux ici *en copier-coller *(tu les sélectionnes > *⌘C* pour copier la sélection dans le presse-papier >  *⌘V* pour la coller ici - ne fais pas de photo d'écran quand il y du texte comme ici) ? - c'est pour avoir une vision claire du dispositif des disques de ton _iMac_.


----------



## fl0rian67 (10 Octobre 2016)

Merci pour la réponse, voici le texte issu du Terminal :

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 Apple SSD               120.5 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                749.0 GB   disk1s2

   3:       Microsoft Basic Data BOOTCAMP                250.9 GB   disk1s3


imac-de-florian:~ Florian$ diskutil cs list

No CoreStorage logical volume groups found

imac-de-florian:~ Florian$


----------



## macomaniac (10 Octobre 2016)

Tu as donc 2 disques internes > qui sont 2 SSD de surcroît :

- un *120 Go* (*disk0*) dans le volume *disk0s2 SSD* duquel est installé l'OS - le Système de secours étant installé sur la partition *disk0s3* du dessous.

- un *1 To* (*disk1*) dont le volume principal *disk1s2 Stockage* de *749 Go*, comme son nom l'indique, n'est qu'un volume de stockage de données sans Système démarrable - une partition *BOOTCAMP* de *250 Go* au format *FAT-32* ayant été créée en dessous (*disk1s3*) en vue d'accueillir Windows.​
Eh bien ! L'«Assistant BootCamp» refusera toujours d'installer «Windows» dans le volume *BOOTCAMP* du *disk1* > car le seul disque valide d'installation pour l'«Assistant BootCamp» est le *disk0* sur lequel l'OS est installé.

Tu as 2 solutions pour parvenir à tes fins :

*- a)* Fusion Drive => faire un clone = image-miroir démarrable (avec la démo gratuite un mois de «CCC») de ton volume *SSD* sur un DDE + sauvegarder itou les données qui peuvent résider dans le volume *Stockage* > démarrer sur le clone > effacer les 2 disques internes > générer un «Fusion Drive» qui associera logiquement les 2 SSD pour exporter un seul volume apparent pour l'utilisateur > rétro-cloner ton clone dans ce super-volume > ce qui clonera aussi une «Recovery HD» en-dessous > démarrer sur ton OS cloné du «Fusion Drive» > lancer l'«Assistant BootCamp» > qui n'aura aucun objection à installer Windows dans une partition créée ad-hoc exclusivement sur le 2è disque associé = le SSD de *1 To*.

[ce sera logiquement un vrai «Fusion Drive» - quoique l'égalité matérielle des 2 disques - SSD - lui ôtera ses enjeux d'optimisation.]

*- b)* Second OS=> sauvegarder les données de «Stockage» > effacer entièrement le disque *disk1* (*1 To*) à partir de la session du volume *SSD* (*disk0s2*) > installer un OS dans le néo-volume *Stockage* vide > démarrer sur cet OS > lancer son «Assistant BootCamp» > installer Windows sur une partition créée en-dessous > effacer les fichiers de l'OS dans «Stockage» (sans reformater) en ayant re-démarré sur l'OS du volume *SSD* du *disk0* > se servir de ce volume pour du stockage de données. Une «Recovery HD» aura été créée en-dessous de «Stockage» (et avant la partition *BOOTCAMP*) > la laisser en place (*650 Mo*) > car sa suppression pourrait invalider le caractère démarrable de la partition *BOOTCAMP*.​
=> à mon avis : le «Fusion Drive» de luxe (2 SSD associés) est une solution supérieure au bricolage de la méthode *b)* - mais c'est toi qui vois.


----------



## Locke (10 Octobre 2016)

fl0rian67 a dit:


> Avec Bootcamp, Windows ne s’installe que sur le disque système du Mac et j’aimerais l’installer sur le SSD mais pendant l’installation de Windows à l’étape « Où voulez-vous installer Windows ? » la partition Bootcamp ne se détecte pas.
> 
> J’ai un peu cherché comment faire sur les forums mais je n'ai pas vraiment trouvé, il y a des sujets avec Winclone mais je crois que c'est plus pour les disques durs externes.


Pour le cas où, un peu de lecture... #38


----------



## fl0rian67 (12 Octobre 2016)

Merci pour vos réponses. Ta solution *a)* macomaniac me conviendrait vraiment mais je pense que je ne suis pas assez calé pour me lancer dans ces opérations car je me demande comment effectuer certaines étapes : cloner le SSD sur un DDE, démarrer sur le clone, générer un Fusion Drive, rétro-cloner. À la rigueur avec un tuto vidéo, même anglais.


----------



## r e m y (12 Octobre 2016)

Cloner le SSD ca se fait tres simplement avec un utilitaire comme CarbonCopyCloner (utilisable gratuitement pendant 1 mois). Il suffit de lui indiquer le disque source et le disque cible et il s'occupe de faire cette copie à l'identique. 

Demarrer sur le disque extérieur cloné, il suffit d'allumer le Mac en maintenant la touche alt appuyee, puis de choisir le disque parmis ceux qui seront presenteés à l'écran

Réaliser un FusionDrive à partir des 2 SSD, là Macomaniac va te venir en aide quand tu en seras là en te guidant étape par étape (il te suffira de copier/coller les lignes de commandes qu il te donnera)

Rétro-cloner le disque externe vers le nouveau FusionDrive, il suffira de réutiliser une deuxième fois CarbonCopyCloner.


----------



## macomaniac (12 Octobre 2016)

Salut *fl0rian
*
Pareil que *r e m y* 

Ne te fais pas un monde de l'ensemble (qui t'apparaît forcément comme une montagne) > concentre-toi uniquement sur le début : l'étape n°1 qui est la seule décisive =

-  création d'un clone du volume *SSD* (et sauvegarde parallèle des données du volume *Stockage* s'il y a lieu). Les autres étapes ne poseront aucun problème et s"enchaîneront quasiment naturellement =>

--> démarrage sur le clone : presser la touche "_alt_" au départ > un écran affiche les volumes démarrables au choix > choisir le volume affiché du clone > tu te retrouves dans une session analogue à celle de ton disque interne.

--> création du Fusion Drive après effacement des disques internes  => c'est l'affaire de quelques commandes à te passer en mode "live" (au moment où tu en as besoin) et qui te prendront 2 minutes en tout maximum d'opération dans le «Terminal» du clone.

--> ré-importation d'une image du clone dans le volume du Fusion Drive => c'est la même manœuvre que la n°1 mais en sens inverse. Trivial avec «Carbon Copy Cloner».​
=> pour savoir combien il y a de données à cloner dans ton volume *SSD* et combien à sauvegarder par ailleurs dans le volume *Stockage* > passe dans le «Terminal» la commande :

```
df -H
```
 qui appelle l'utilitaire *df* (*d*isplay_*f*ree_space : afficher l'espace libre) avec l'option *-H* (*H*uman_readable : en valeurs humainement lisibles = *Mo*, *Go*, *To*) --> en retour, tu vas voir s'afficher en mode tableau autant de lignes que de volumes montés qui auront été scannés > avec mention pour chacun de la capacité totale > taille de l'espace occupé > taille de l'espace libre.

=> en fonction de ces valeurs > tu sauras combien de Go doit avoir au maximum le volume du DDE destiné au clone de *SSD* > et combien le volume parallèle de sockage d'une copie des données du volume *Stockage*.


----------



## fl0rian67 (13 Octobre 2016)

Bonsoir,
Est-ce possible de sauvegarder mes données *Stockage* sur le disque dur externe que j'utilise comme clone du *SSD* ou est-ce que ce dernier est entièrement dédié au clone ?


----------



## macomaniac (13 Octobre 2016)

Salut *fl0rian
*
Le mieux serait de partitionner ton DDE > ce qui peut très se faire (non destructivement = mode "_live_") à partir d'un volume déjà occupé par un clone (dès lors que la table de partition est *GPT* = *GUID* et le format du système de fichiers du volume *jhfs+* - ce qui doit être le cas pour que ton clone soit démarrable). «Carbon Copy Cloner» peut te cloner aussi le contenu d'un volume de données (il ne clone que les fichiers, pas l'espace entier du volume) dans ce nouveau volume d'accueil.

Le tout est donc de savoir : combien du tas de données dans ton volume "source" = *Stockage* > quelle est la taille du disque de ton DDE > combien il y a déjà de données dans le volume du clone > pour décider si un repartitionnement est ou non pertinent afin d'accueillir les données de *Stockage* en parallèle dans un nouveau volume.

Pour cela (_bis repetita placent_) > après avoir attaché ton DDE à ton Mac > passe la commande déjà évoquée :

```
df -H
```
 et poste ici le tableau retourné en copier-coller. On saura tout !


----------



## fl0rian67 (13 Octobre 2016)

Je vais plutôt mettre mes données sur un DDE à part.
Est-ce que je dois préalablement formater mon DDE en un certain format avant de lancer l'opération de clonage sur CCC ?


----------



## macomaniac (13 Octobre 2016)

Tu veux dire ton nouveau DDE pour les données de *Stockage* ? --> si tu n'envisages de l'utiliser qu'avec un Mac > choisis une Table de Partition *GUID* pour le disque complet et un format *Mac OS étendu (journalisé)* pour le volume d'accueil.


----------



## fl0rian67 (13 Octobre 2016)

Je vais mettre mes données de *Stockage* sur un DDE, et cloner mon *SSD* sur un deuxième DDE, et ma question concernait le deuxième DDE : Carbon Copy Cloner s'occupe de tout lors du clonage ou est-ce que je dois d'abord formater le deuxième DDE avant de lancer le clonage du *SSD* ?


----------



## macomaniac (13 Octobre 2016)

Il faut d'abord que tu initialises logiquement ce DDE pour Mac : table de partition *GUID* pour le disque et format *JHFS+* (*Mac OS étendu journalisé*) pour le volume. Sans ce paramétrage du disque et du volume > le clone ne serait pas démarrable.

Je peux te le faire en ligne de commande si tu veux > il suffit que tu attaches ce nouveau DDE à ton Mac (seul en externe) et que tu donnes le retour de la commande :

```
diskutil list
```


----------



## fl0rian67 (13 Octobre 2016)

D'accord merci ! Je m'en occupe ce week-end.


----------



## macomaniac (13 Octobre 2016)

À la fin du clonage des fichiers de ton volume SSD dans celui de ton DDE > «CCC» va te demander si tu veux qu'il clone aussi la partition de récupération (= *Recovery HD*) sur le DDE > il est important que tu répondes : *OUI*. Ainsi > quand tu en seras à l'étape finale de cloner à rebours ton clone dans le volume du Fusion Drive flambant neuf > il sera possible de cloner aussi une partition *Recovery HD* (sur le 2è disque de ton Mac). Ainsi, tu auras un dispositif complet : OS + Récupération sur les disques de ton Mac.


----------



## fl0rian67 (19 Octobre 2016)

Bonsoir,
J'étais un peu occupé ces derniers temps avec la recherche d'emploi, les entretiens à préparer etc., mais ça y est je me suis lancé.
J'ai cloné mon *SSD* sur un DDE, puis démarré dessus pour vérifier. Ça fonctionne mais c'est très lent (la faute au disque dur PATA).
J'attends les instructions pour la prochaine étape, quand tu aura le temps bien sûr :


macomaniac a dit:


> --> création du Fusion Drive après effacement des disques internes => c'est l'affaire de quelques commandes à te passer en mode "live" (au moment où tu en as besoin) et qui te prendront 2 minutes en tout maximum d'opération dans le «Terminal» du clone.


----------



## macomaniac (19 Octobre 2016)

Salut *fl0rian
*
Tu as cloné ton volume *SSD* sur un DDE - est-ce que tu as aussi sauvegardé les données du volume *Stockage* du HDD ?

Si tout est en ordre côté sauvegarde --> démarre sur ton clone du DDE > une fois la session du clone ouverte > passe la commande :

```
diskutil list
```
 et poste le tableau retourné pour que je voie quels sont les identifiants des disques dans ce cas de figure d'un démarrage externe.


----------



## fl0rian67 (19 Octobre 2016)

Oui tout est en ordre côté sauvegarde. Le tableau :

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 Apple SSD               120.5 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                999.9 GB   disk1s2


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


imac-de-florian:~ Florian$


----------



## macomaniac (19 Octobre 2016)

Alors une petite série de commandes (fais des copier-coller dans la fenêtre du «Terminal») =>

*- a)* la commande :

```
diskutil partitionDisk /dev/disk0 gpt jhfs+ SSD 100%
```
 va réinitialiser le SSD *disk0* en exportant un seul volume utile intitulé *SSD*.

*- b)* la commande :

```
diskutil partitionDisk /dev/disk1 gpt jhfs+ HDD 100%
```
 va réinitialiser le HDD *disk1* en exportant un seul volume utile intitulé *HDD*.

*- c)* la commande :

```
diskutil coreStorage createLVG FUSION /dev/disk0s2 /dev/disk1s2
```
 va créer les bases d'un Fusion Drive en mettant en place le *Groupe de Volumes Logiques* global et en important un *Physical Volume* (disque virtuel émulant un disque dur) sur chacune des partitions principales : la *disk0s2* du SSD et la *disk1s2* du HDD.

=> en sortie de la l'opération *c)* aucun Volume de synthèse ne sera encore exporté > mais tu obtiendras en retour un *UUID* de 32 caractères alpha-numériques identifiant le *Groupe de Volumes Logiques*.

Tu n'as qu'à passer alors les 2 commandes :

```
diskutil list
diskutil cs list
```
 et poster les 2 tableaux retournés > afin que je vérifie si tout est en ordre et que je te passe la dernière commande pour parachever le Fusion Drive.


----------



## fl0rian67 (19 Octobre 2016)

*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_CoreStorage FUSION                  121.0 GB   disk0s2

   3:                 Apple_Boot Boot OS X               134.2 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_CoreStorage FUSION                  999.9 GB   disk1s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk1s3


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


*diskutil cs list*

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group C62E315B-19EE-48D3-B0B0-840ED549934F

    =========================================================

    Name:         FUSION

    Status:       Online

    Size:         1120849764352 B (1.1 TB)

    Free Space:   1120228990976 B (1.1 TB)

    |

    +-< Physical Volume 43CC49F8-35E5-4854-B6F8-EB53F5079C31

    |   ----------------------------------------------------

    |   Index:    0

    |   Disk:     disk0s2

    |   Status:   Online

    |   Size:     120988852224 B (121.0 GB)

    |

    +-< Physical Volume 56647E90-957A-4B59-9B8D-2A53DDB72F35

        ----------------------------------------------------

        Index:    1

        Disk:     disk1s2

        Status:   Online

        Size:     999860912128 B (999.9 GB)


----------



## macomaniac (19 Octobre 2016)

Mais c'est très joli tout ça - tout propre 
	

	
	
		
		

		
		
	


	




Pour parachever le travail :

*- d)* la commande :

```
diskutil coreStorage createLV C62E315B-19EE-48D3-B0B0-840ED549934F jhfs+ Macintosh\ HD 100%
```
 va exporter un *Volume Logique* unique intitulé *Macintosh HD* à partir des 2 partitions majeures du SSD et du HDD.

Tu n'as qu'à reposter encore le résultat d'un :

```
diskutil cs list
```
 que je vérifie s'il n'y a pas de lézard.


----------



## fl0rian67 (19 Octobre 2016)

diskutil cs list

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group C62E315B-19EE-48D3-B0B0-840ED549934F

    =========================================================

    Name:         FUSION

    Status:       Online

    Size:         1120849764352 B (1.1 TB)

    Free Space:   122880 B (122.9 KB)

    |

    +-< Physical Volume 43CC49F8-35E5-4854-B6F8-EB53F5079C31

    |   ----------------------------------------------------

    |   Index:    0

    |   Disk:     disk0s2

    |   Status:   Online

    |   Size:     120988852224 B (121.0 GB)

    |

    +-< Physical Volume 56647E90-957A-4B59-9B8D-2A53DDB72F35

    |   ----------------------------------------------------

    |   Index:    1

    |   Disk:     disk1s2

    |   Status:   Online

    |   Size:     999860912128 B (999.9 GB)

    |

    +-> Logical Volume Family EAA796FE-E32E-425A-A2B6-D3509D460B70

        ----------------------------------------------------------

        Encryption Type:         None

        |

        +-> Logical Volume 9C432294-6920-4275-BD6A-E6202D9EA096

            ---------------------------------------------------

            Disk:                  disk3

            Status:                Online

            Size (Total):          1120228868096 B (1.1 TB)

            Revertible:            No

            LV Name:               Macintosh HD

            Volume Name:           Macintosh HD

            Content Hint:          Apple_HFS

            LVG Type:              Sparse


----------



## macomaniac (19 Octobre 2016)

Eh bien ! tout va bien. Ton Fusion Drive est créé complètement et exporte le volume *Macintosh HD* de *1,1 To* qu'en tant qu'utilisateur tu peux considérer comme d'un seul tenant.

J'avais oublié que le disque  *1 To* est aussi un SSD, non ? Alors tu as un super Fusion Drive (une sorte de super Fusée Directe).

Il ne te reste plus qu'à lancer «Carbon Copy Cloner» (qui doit avoir été cloné dans les applications de ton clone) > à supprimer la tâche enregistrée qui allait dans le sens disque interne --> disque externe > puis à créer un nouvelle tâche telle que : "_source_" = le volume *MAXTOR* du clone sans exclusion > "_destination_" = le volume *Macintosh HD* du Fusion Drive > et presser le bouton "Cloner" > à la fin, quand «CCC» te demande si tu veux qu'il crée aussi une partition de secours : tu réponds OUI.

=> il ne te restera plus qu'à re-démarrer en pressant la touche "_alt_" à l'écran noir > et à démarrer sur le volume *Macintosh HD* du Fusion Drive.


----------



## fl0rian67 (19 Octobre 2016)

Merci *énormément*  quelle assistance au top  ! Je vais lancer le rétro-clonage.

Edit : Oui, le disque *1 To* est aussi un SSD. Je me suis demandé en voyant *HDD* dans les lignes de commandes, si tu l'avais zappé ou si il fallait justement la combinaison " SSD + HDD ".


----------



## macomaniac (19 Octobre 2016)

Lorsque tout sera fini et que tu auras redémarré sur ton *Macintosh HD* > j'aimerais que tu postes encore le résultat d'un :

```
diskutil list
```
 simple > que je vérifie si la *Recovery HD* a bien été clonée en position *disk1s3* en queue du disque de *1 To*.

[Normalement c'est toujours sur le grand disque (qui est un HDD) qu'elle est créée - je suis curieux de vérifier si la règle s'applique aussi en cas de double SSD.]


----------



## fl0rian67 (20 Octobre 2016)

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_CoreStorage FUSION                  121.0 GB   disk0s2

   3:                 Apple_Boot Boot OS X               134.2 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_CoreStorage FUSION                  999.9 GB   disk1s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk1s3


/dev/disk2 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            Macintosh HD           +1.1 TB     disk2

                                Logical Volume on disk0s2, disk1s2

                                9C432294-6920-4275-BD6A-E6202D9EA096

                                Unencrypted


/dev/disk3 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk3

   1:                        EFI EFI                     209.7 MB   disk3s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk3s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk3s3


----------



## fl0rian67 (20 Octobre 2016)

Si j'ai bien compris il n'y a pas de *Recovery HD* mais bien un *Boot OS X* sur chaque disque. Quand je démarre le Mac en appuyant sur alt, j'ai le choix entre _" Macintosh HD "_ et _" Macintosh HD 2 "_, et quand je regarde dans _À propos de ce Mac,_ j'ai bien 2 disques : le premier a 41 Go de _" Système "_ en jaune quand le deuxième a 45 Go d'_" Espace utilisé "_ en gris, alors qu'ils ont le même nom et le même volume. Bizarre...
En plus de ça le Mac démarre en 45 secondes contre 15 à 20 secondes avant


----------



## macomaniac (20 Octobre 2016)

*fl0rian*


Pas-sion-nant !

Tout allait évidemment trop bien pour que ça se finisse tout aussi bien. Il y a une paille dans l'alliage. Possiblement parce que les 2 disques sont égalitairement des SSD.

Dès la création du *Groupe de Volumes Logiques* (cf. ton message #59), en effet, j'avais constaté la génération d'une petite partition *Apple_Boot Boot OS X 134.2 MB* sur les *2* disques (en *disk0s3* et en *disk1s3*). Normalement, en cas de Fusion Drive associant un SSD *disk0* et un HDD *disk1* > une seule partition *Apple_Boot Boot OS X 134.2 MB* se trouve générée > uniquement sur le SSD càd. en position *disk0s3*. Par contre, sur le 2è disque (le HDD), il n'y a aucune partition *Apple_Boot Boot OS X 134.2 MB* en-dessous de la partition du *CoreStorage disk1s2* (mais c'est la partition de secours *Recovery HD* qui occupe la position *disk1s3*).

Une partition *Apple_Boot Boot OS X 134.2 MB*, càd. une partition dont le volume est *Boot OS X *et dont le type de partition est : *Apple_Boot*, est ce qu'on appelle la partition du « *Booter* » du *CoreStorage*. « *Booter* » signifiant "démarreur". Le statut de cette partition *Boot OS X* est pour moi une des grandes énigmes du format *CoreStorage*. Pour l'exacte raison suivante : je me suis amusé de nombreuses fois, expérimentalement, à créer des formats *CoreStorage* (solitaires ou Fusion Drive) qui donnaient lieu à la génération d'une partition *Apple_Boot Boot OS X 134.2 MB* > et, m'interrogeant sur la nature de cette partition, j'ai monté une série de fois cette partition en un volume *Boot OS X *afin d'en inspecter le contenu. L'issue constante de l'inspection de ce volume monté *Boot OS X* est qu'il est absolument *vide* du moindre fichier.

Ainsi donc, la partition du *Booter* d'un *CoreStorage* porte un volume vide, sans aucun fichier exécutable. Qui dit partition avec un volume vide de fichiers > suggère : partition inutile. Pourtant, toute création d'un format *CoreStorage* s'accompagne constamment de la génération d'une telle partition d'un « *Booter* » > ce qui laisse entendre que cette partition dont le volume est vide de contenu a néanmoins une fonction logique nécessaire. La « fonction du vide » : cela plairait immanquablement aux _Taoïstes_ qui ne cessent de déclarer que le vide est nécessaire, en prenant des exemples triviaux de l'expérience. Par exemple une casserole : si elle ne comportait pas de vide > comment pourrait-on s'en servir pour recueillir un liquide à chauffer ? Ou encore une porte : si la porte ne comportait pas de vide > comment servirait-elle de passage ?

Cette interpolation qui peut paraître oiseuse de considérations _taoïstes_ dans un domaine logique déterministe > me conduit à une conjecture. Ces exemples _taoïstes_ illustrent la « fonction du vide » dans le sens suivant : le vide la casserole ou le vide de la porte, intrinsèquement parlant, sont indifférents ; c'est relativement au processus d'une action (réchauffer, passer) qu'ils prennent une valeur utile. En ce que le vide de la casserole recueille le liquide qu'on veut chauffer ou en ce que le vide de la porte accueille momentanément la présence de celui qui passe.

Si j'extrapole donc du _taoïsme_ au *CoreStorage* (par un acte d'imagination hardi) > je me figure que le volume vide de la partition *Boot OS X* est destiné à recueillir un contenu provisoire lors du démarrage du Mac - contenu qui sera évacué à l'issue du démarrage. Quel contenu ? Je ne suis pas ingénieur informaticien : j'en suis réduit à des spéculations. Tout ce que je sais est que, dans une architecture *CoreStorage*, le *Volume Logique* monte à partir du *Volume Physique* qui émule un disque dur par l'intermédiaire d'une instance de pilotage appelée *Famille de Volumes Logiques*. Je conjecture que cette instance médiatrice doit créer à la volée dans le volume vide de la partition *Boot OS X* une ressource éphémère de montage du *Volume Logique* qui se purge après emploi. Je n'ai pas affiné mes conjectures plus avant.​
Pour revenir donc à ton cas particulier > l'anomalie consiste dans la présence de *2* partitions *Boot OS X* alors qu'une seule est requise, puisque le *Volume Logique* à monter est unique. La *Famille de Volumes Logiques* doit donc créer *2* ressources provisoires de montage du *Volume Logique*, une dans chacun des volumes *Boot OS X* > ce qui fait que tu vois affichés *2* *Volumes Logiques* (qui sont 2 versions du même) : *Macintosh HD* et *Macintosh HD 2*. Lorsque tu choisis de démarrer sur un de ces 2 volumes (qui sont 2 représentations parallèles du même) > je conjecture encore que le démarrage doit « passer » par ces *2* instances *Boot OS X* au lieu d'une seule et unique > ce qui doit entraîner le doublement du temps de boot que tu constates [un peu comme si, pour passer d'une pièce à une autre pièce de ma maison, je disposais de 2 portes côte-à-côte dont j'aurais à emprunter le passage l'un après l'autre - ce qui m'obligerait bien sûr à passer à rebours une des 2 portes pour pouvoir passer à l'endroit la 2è porte - ce qui renvoie au « Problème des sept ponts de Königsberg » de _Kant_.]

Bon : toute cette rhétorique que je viens de dérouler n'a fait qu'emballer diplomatiquement (comme tu l'auras sans doute deviné) la rigueur de la décision suivante => il faut nécessairement supprimer un des 2 *booters* et ce sera celui du grand disque de *1 To *[parce que c'est sur ce disque que tu as assez de place pour une future partition *BOOTCAMP* > et que c'est sur le disque du Fusion Drive sans *booter* mais avec *Recovery HD* - le HDD par défaut - que l'«Assistant BootCamp» est programmé pour créer cette partition]. Si tu examines la table de partition du grand disque > tu remarques qu'occupant la position *disk1s3* juste en-dessous de la partition *CoreStorage* n°2 > le *booter* a empêché de ce fait même la création de la partition de récupération *Recovery HD* par «Carbon Copy Cloner». Car une *Recovery HD* se crée immédiatement en-dessous d'une partition-Système et ne peut se créer après l'intercalaire d'un *booter*.

Comme tu as un clone démarrable > tu ne risques rien en pratique à cette passionnante expérimentation. Je t'invite donc à démarrer sur ton clone *MAXTOR* et à passer dans le «Terminal» les commandes suivantes :

*- a)* la commande :

```
diskutil eraseVolume free NULL /dev/disk1s3
```
 qui supprime la partition *Boot OS X* du disque de *1 To* et convertit ses blocs au statut de *free_space* (espace libre hors partition). Si tu obtenais un message d'erreur (du style : "*resource busy*") > il faudrait alors en préalable passer la commande de démontage du *Volume Logique Macintosh HD* :

```
diskutil umount force /dev/disk2
```
 et après le message : "*volume Macintosh HD on disk2 force unmounted*" > repasser la commande donnée : 
	
	



```
diskutil eraseVolume free NULL /dev/disk1s3
```

*- b)* la commande :

```
diskutil coreStorage resizeStack 9C432294-6920-4275-BD6A-E6202D9EA096 0b
```
 qui récupère le petit espace libre de *134 Mo* au *Volume Logique Macintosh HD* (spécifiquement : à la partition *disk1s2* du grand disque). À condition que cet espace ne soit pas trouvé trop petit pour cette opération. Si tu avais démonté le *Volume Logique* précédemment > il faudrait le remonter d'abord par la commande :

```
diskutil mount /dev/disk2
```
 avant de passer la commande :

```
diskutil coreStorage resizeStack 9C432294-6920-4275-BD6A-E6202D9EA096 0b
```
 qui requiert le *Volume Logique* monté.

*- c)* à présent : je ne sais pas si «Carbon Copy Cloner» sait cloner une partition de récupération *Recovery HD* lorsque le volume-cible est le *Volume Logique* de synthèse d'un Fusion Drive. Il te suffit de faire l'essai > tu lances «CCC» > tu négliges dans la colonne de gauche la partie supérieure dédiée aux "_Tâches_" > tu avises dans la portion inférieure dédiée aux "_Volumes" _l'affichage des volumes montés > tu sélectionnes le volume *Macintosh HD*.

Normalement cette sélection démasque un champ bleu central avec un bouton subalterne *Recovery HD* > presse ce bouton s'il est affiché > normalement un panneau se démasque : "*Clonage de la partition de secours Apple*" > presse le bouton "*Restaurer Recovery HD*" s'il est disponible.

Peux-tu poster le résultat d'un :

```
diskutil list
```
 à la fin de cette opération «CCC» que je vérifie l'état des lieux ?

=> superbe d'audace à présent > re-démarre ton Mac avec la touche "_alt_" pressée : vérifie si tu vois affiché un volume *Macintosh HD* (et un seul, puisqu'il n'y a plus qu'un *booter Boot OS X* > celui du petit SSD) > tente de démarrer sur ce volume > est-ce que le démarrage s'effectue ? Est-ce qu'il est plus rapide que précédemment (dans les 20" au lieu de 40") ?


----------



## fl0rian67 (20 Octobre 2016)

Salut ! Wahou j'ai eu un peu de mal à suivre ta réthorique. J'ai effectué l'opération *a)* qui a fonctionné sans message d'erreur, puis la *b)* qui m'a affiché :

_" 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 "_

J'ai donc refais la *a)* en passant la commande de _" démontage du *Volume Logique Macintosh HD *"_, toujours ce même message d'erreur de disque trop petit en faisant l'opération *b)*.

À l'étape *c)*, le message suivant avec impossibilité de créer un Recovery HD :

_" Ce volume ne peut pas contenir de volume Recovery HD car : 
- Le volume choisi est un volume CoreStorage dont il est impossible d'emprunter de l'espace pour la création d'un volume Recovery HD. "
_
Et le tableau du diskutil list :

/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_CoreStorage FUSION                  999.9 GB   disk0s2

   3:                 Apple_Boot Boot OS X               134.2 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_CoreStorage FUSION                  121.0 GB   disk1s2


/dev/disk2 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            Macintosh HD           +1.1 TB     disk2

                                Logical Volume on disk1s2, disk0s2

                                9C432294-6920-4275-BD6A-E6202D9EA096

                                Unencrypted


/dev/disk3 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk3

   1:                        EFI EFI                     209.7 MB   disk3s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk3s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk3s3


/dev/disk4 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:     FDisk_partition_scheme                        *1.0 TB     disk4

   1:               Windows_NTFS WD 1 To                 1.0 TB     disk4s1


Voilà, par contre je n'ai pas encore essayé de redémarrer.


----------



## macomaniac (20 Octobre 2016)

La partition du *booter* n°2 (grand disque) a bien été supprimée. Qu'il y ait *134 Mo* de blocs libres dans la nature : pas grave > comme tu as vu, c'est considéré comme trop peu pour mériter un re-dimensionnement.

Après : «CCC» n'est pas capable de gérer un volume Fusion Drive pour installer une *Recovery HD*. J'avais des doutes. Alors voici la méthode > tu démarres sur la *Recovery HD* de ton DDE (tu peux passer par "_alt_" et le choix du volume affiché : *Récupération 10.x* ou par *⌘R*) > option "_Ré-installer OS X_" => tu choisis comme volume de "_destination_" : *Macintosh HD* > téléchargement d'un installateur de la même version que l'OS du clone et du volume *Macintosh HD* (dans les 1H 45) > puis restauration du seul Système (avec préservation du compte utilisateur, réglages, applications tierces) et... création d'une *Recovery HD* si celle-ci faisait défaut - ce qui est le cas (dans les 30' à 40' selon les OS).

=> après toutes ces manœuvres > poste le résultat d'un *diskutil list* et décris les événements notables. Boot  sur *Macintosh HD* > temps requis > affichage à l'écran obtenu avec _alt_.


----------



## fl0rian67 (20 Octobre 2016)

Il y a comme un soucis : le disque *Macintosh HD* est grisé quand je veux réinstaller macOS (je ne peux pas cliquer dessus) : 
_" Ce disque ne peut pas être configuré pour démarrer votre ordinateur "
_
Au démarrage en appuyant sur alt je n'avais plus *Macintosh HD* mais seulement *Macintosh HD 2*, alors c'est peut-être là le soucis ?


----------



## fl0rian67 (20 Octobre 2016)

Bon, mis à part le problème avec le *Recovery HD*, le mac se démarre en 17 secondes ce qui me va très bien


----------



## macomaniac (20 Octobre 2016)

Ne pas avoir de *Recovery HD* et ne pas pouvoir ré-installer le volume de l'OS : ce n'est pas une situation saine. De plus, l'«Assistant BootCamp» va probablement refuser de créer une partition pour «Windows» dans ces conditions.

Je pense que la racine de tous les problèmes vient de ce que le grand disque de *1 To* est lui aussi un SSD, et pas un HDD comme attendu dans une association Fusion Drive. Par suite, lors de la création du Fusion Drive > les 2 disques sont traités à parité (chacun avec sa partition du *booter*) au lieu qu'un seul (le SSD) soit privilégié (le seul ayant un *booter*) > l'autre (le HDD) étant considéré comme une espèce de remorque du premier disque considéré lui comme la partie motrice de l'attelage.

Si tu n'y vois pas d'inconvénient, il faudrait que tu démarres sur ton clone > qu'on supprime le Fusion Drive > et qu'on essaye de le rebâtir avec un seul *booter*  : sur le petit SSD de *120 Go*.

Je viens justement de faire une expérimentation avec 2 clés USB associées en mode Fusion Drive - parce qu'il s'agit de 2 disques de type égalitaire. Effectivement > à la création du *Groupe de Volumes Logiques* > *2* partitions *booter* sont créées > une sur chaque disque. J'ai supprimé le *booter* de la clé n°2 avant de créer un *Volume Logique*  de synthèse > aucune difficutlé n'est faite > je présume alors, cette fois-ci, qu'on obtient un *Fusion Drive* à un seul *booter* dans lequel le disque avec *booter* est considéré comme moteur de l'attelage et le disque sans *booter* comme remorque de l'attelage.

=> est-ce que tu te sens pour cette nouvelle entreprise ?


----------



## fl0rian67 (20 Octobre 2016)

En fait à l'opération *a*) du post #67 il aurait fallu supprimer la partition *Boot OS X* du SSD de *120 Go* à la place de celle du SSD de *1 To *non ?
Sinon oui je suis chaud car je préfère avoir une installation " propre ", et si on me propose de l'aide je ne peux qu'accepter


----------



## macomaniac (20 Octobre 2016)

Non : je pense qu'il faut garder le *booter* du *120 Go* et supprimer celui du *1 To* > afin que le disque *1 To* « apparaisse » logiquement comme disque "remorqué" > c'est à cette seule condition qu'une *Recovery HD* pourra être créée sur ce grand disque, puis que l'«Assistant BootCamp» acceptera de créer une partition pour «Window». Tu te souviens ? C'est cette seule perspective d'une partition Windows démarrable qui motive cette histoire de Fusion Drive. Et pour avoir une partition Windows conséquente > autant qu'elle soit créée sur le grand disque. Ce qui implique qu'il ait le statut logique de disque "remorqué".

Si tu es prêt pour l'expérience > moi aussi. Démarre sur ton clone *MAXTOR* et là passe les commandes :

```
diskutil coreStorage deleteLVG C62E315B-19EE-48D3-B0B0-840ED549934F
```
 qui supprime l'association Fusion Drive et exporte 2 volumes vides *Untitled* sur chacun des SSD.


```
diskutil partitionDisk /dev/disk0 gpt jhfs+ SSD 100%
```
 qui ré-initialise le petit SSD en exportant un volume *SSD*.

```
diskutil partitionDisk /dev/disk1 gpt jhfs+ HDD 100%
```
 qui fait pareil avec le grand SDD en exportant un volume humoristiquement appelé *HDD*.


```
diskutil coreStorage createLVG FUSION /dev/disk0s2 /dev/disk1s2
```
 qui recrée les bases d'un Fusion Drive (sans le *Volume Logique*).

=> à ce stade > passe encore un :

```
diskutil list
```
 et poste le tableau retourné.


----------



## fl0rian67 (20 Octobre 2016)

Ça commence mal :

diskutil coreStorage deleteLVG C62E315B-19EE-48D3-B0B0-840ED549934F

Started CoreStorage operation

Unmounting Logical Volumes

The volume "Macintosh HD" on disk2 couldn't be unmounted

Error: -69888: Couldn't unmount disk


----------



## macomaniac (20 Octobre 2016)

Passe la commande :

```
sudo diskutil umountDisk force /dev/disk2
```
 (tu valides > tu tapes ton mot-de-passe admin à l'aveugle à la demande de password > tu revalides) => message de succès ou d'échec ?


----------



## fl0rian67 (20 Octobre 2016)

_Forced unmount of all volumes on disk2 was successful_


----------



## fl0rian67 (20 Octobre 2016)

Le SSD *120 Go* a bien été réinitialisé. Le SSD *1 To* est bloqué à _" Unmounting disk [ \ \ \ \ \ \ \ \ \ ] "_ avec les slash qui " chargent " là où ils devraient aller assez vite.


----------



## macomaniac (20 Octobre 2016)

C'est un grand disque : il faut peut-être du temps (il n'a peut-être pas digéré la suppression du booter 
	

	
	
		
		

		
		
	


	




 ).

Si ça s'éternise > signale-le : comme les 2 disques doivent être séparés logiquement > il y a moyen de régler le compte du grand SSD isolément.


----------



## fl0rian67 (20 Octobre 2016)

Ben là ça fait bien 8-9 minutes et toujours les \ \ \ \ \, même pas un 0% symbolique.


----------



## macomaniac (20 Octobre 2016)

Force l'extinction de ton Mac > démarre sur ton clone > passe un :

```
diskutil list
```
 et poste le résultat.


----------



## fl0rian67 (20 Octobre 2016)

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 SSD                     121.0 GB   disk0s2


/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_CoreStorage FUSION                  999.9 GB   disk1s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk1s3


/dev/disk3 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk3

   1:                        EFI EFI                     209.7 MB   disk3s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk3s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk3s3


----------



## macomaniac (20 Octobre 2016)

Donc le SSD 121 Go est complètement dissocié. Le SSD 1 To a encore des reliquats de *CoreStorage* (le curieux : c'est qu'il a un *booter* en *disk1s3* - on l'avait bien supprimé pourtant ?).

Que donne le résultat d'une commande :

```
diskutil cs list
```


----------



## fl0rian67 (20 Octobre 2016)

Oui on l'avait bien supprimé. Comme il y en avait 2, le *booter* du *120 Go* est peut-être passé automatiquement sur le *1 To* comme ce dernier est encore en mode Fusion Drive, non ?

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group C62E315B-19EE-48D3-B0B0-840ED549934F

    =========================================================

    Name:         FUSION

    Status:       Initializing

    Size:         999860912128 B (999.9 GB)

    Free Space:   -none-

    |

    +-< Physical Volume 43CC49F8-35E5-4854-B6F8-EB53F5079C31

    |   ----------------------------------------------------

    |   (No properties)

    |

    +-< Physical Volume 56647E90-957A-4B59-9B8D-2A53DDB72F35

        ----------------------------------------------------

        Index:    1

        Disk:     disk1s2

        Status:   Checking

        Size:     999860912128 B (999.9 GB)


----------



## macomaniac (20 Octobre 2016)

C'est ce qui s'appelle un *CoreStorage* bien décapité, qui garde des traces du *Physical Volume* du petit SSD.

Est-ce que la commande directe :

```
diskutil partitionDisk /dev/disk1 gpt jhfs+ HDD 100%
```
 passe ?


----------



## fl0rian67 (20 Octobre 2016)

Non toujours pas, ça charge dans le vide.


----------



## macomaniac (20 Octobre 2016)

Tu peux arrêter l'opération en cours en pressant les 2 touches *ctrl C*.

Essaie la commande suivante :

```
sudo gpt destroy /dev/disk1
```
 => est-ce que tu obtiens un message d'erreur ? ou est-ce que tu récupères l'invite de commande ?


----------



## fl0rian67 (20 Octobre 2016)

En fait les précédentes opérations ne bloquaient pas le Terminal, ça chargeait juste dans le vide, en continu, mais je pouvais fermer le Terminal pour annuler la commande en cours. Désolé si je me suis mal exprimé. Sinon là avec la dernière commande j'ai :

_sudo gpt destroy /dev/disk1

Password:_

d'abord avec le cadenas après Password, donc je le tape, il se déverrouille et passe à la ligne, sans aucun autre message.


----------



## macomaniac (20 Octobre 2016)

La commande *gpt destroy* en fait zappe la carte de partition *GPT* de l'en-tête du disque cible, ici le *disk1*.

Mais aussi longtemps que ce disque reste attaché au Système (ici celui de ton clone) > le *kernel* (noyau opérateur du clone ici) continue de faire comme si... rien ne s'était passé et comme si le disque avait toujours une table de partition.

Alors je t'invite à re-démarrer ton Mac une fois de plus en rebootant sur ton clone. Lorsque ta session s'ouvrira > si un panneau affiche : "_le disque que vous avez inséré n'est pas lisible par cet ordinateur_" => c'est gagné.

Presse le bouton *Ignorer* et passe la commande : 

```
diskutil partitionDisk /dev/disk1 gpt jhfs+ HDD 100%
```
 après quoi tu refais un :

```
diskutil list
```
 et tu postes le tableau.

=> tout ça : c'est si rien n'accroche en chemin.


----------



## fl0rian67 (20 Octobre 2016)

Je n'ai pas eu le panneau dont tu as parlé au redémarrage, mais la commande a enfin marché (il me semble) :

*diskutil partitionDisk /dev/disk1 gpt jhfs+ HDD 100%*

Started partitioning on disk1

Unmounting disk

Creating the partition map

Waiting for partitions to activate

Formatting disk1s2 as Mac OS Extended (Journaled) with name HDD

Initialized /dev/rdisk1s2 as a 931 GB case-insensitive HFS Plus volume with a 81920k journal

Mounting disk

Could not mount disk1s2 after erase

Finished partitioning on disk1

/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 HDD                     999.9 GB   disk1s2


*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 SSD                     121.0 GB   disk0s2


/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 HDD                     999.9 GB   disk1s2


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


----------



## macomaniac (20 Octobre 2016)

Eh ben dis donc ! Il a été coriace celui-là... Oui : tout est comme il doit être. Les 2 disques sont initialisés comme il faut.

Alors à présent tu passes la commande :

```
diskutil coreStorage createLVG FUSION /dev/disk0s2 /dev/disk1s2
```
 qui va créer le socle du Fusion Drive sans le *Volume  Logique*.

Évidemment > il va y avoir 2 *booters* : un *Boot OS X disk0s3* et un *Boot OS X  disk1s3*. Poste le résultat d'un :

```
diskutil list
```
 que je vérifie > car tout va se jouer avant la génération du *Volume Logique*.

[Tu sais que c'est complètement expérimental, tout ça ? - Un pionnier : voilà ce que tu es 
	

	
	
		
		

		
			





 ]


----------



## fl0rian67 (20 Octobre 2016)

C'est pas très rassurant dis comme ça  mais j'ai confiance. Un pionnier avec une superbe équipe d'une personne derrière lui .

*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_CoreStorage FUSION                  121.0 GB   disk0s2

   3:                 Apple_Boot Boot OS X               134.2 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_CoreStorage FUSION                  999.9 GB   disk1s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk1s3


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


----------



## macomaniac (20 Octobre 2016)

fl0rian67 a dit:


> Un pionnier avec une superbe équipe d'une personne derrière lui


... et un clone : ça fait donc trois.​
Évidemment les 2 *booters* sont au rendez-vous.

Alors par la commande :

```
diskutil eraseVolume free NULL /dev/disk1s3
```
 tu effaces le *booter* du grand SSD. Et comme j'ai oublié de te demander de la passer > passe la commande :

```
diskutil cs list
```
 et poste le tableau retourné > que je connaisse l'*UUID* du *Logical Volume Group* afin de pouvoir créer le *Volume Logique*.


----------



## fl0rian67 (20 Octobre 2016)

Et voilà :

*diskutil cs list*

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group 7D0B3277-1B6A-4A83-A18F-8AC19A619234

    =========================================================

    Name:         FUSION

    Status:       Online

    Size:         1120849764352 B (1.1 TB)

    Free Space:   1120228990976 B (1.1 TB)

    |

    +-< Physical Volume 654ECFAE-7A2E-435D-9C1C-67C4C509C9F5

    |   ----------------------------------------------------

    |   Index:    0

    |   Disk:     disk0s2

    |   Status:   Online

    |   Size:     120988852224 B (121.0 GB)

    |

    +-< Physical Volume EC114CCC-1957-4D3E-89B2-62AF6454AA81

        ----------------------------------------------------

        Index:    1

        Disk:     disk1s2

        Status:   Online

        Size:     999860912128 B (999.9 GB)


----------



## macomaniac (20 Octobre 2016)

Alors pour créer le *Volume Logique* la commande est :

```
diskutil coreStorage createLV 7D0B3277-1B6A-4A83-A18F-8AC19A619234 jhfs+ Macintosh\ HD 100%
```

Une fois l'opération effectuée, poste encore le résultat d'un :

```
diskutil list
```
 pour voir à quoi ressemble le dispositif des disques.


----------



## fl0rian67 (20 Octobre 2016)

*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_CoreStorage FUSION                  121.0 GB   disk0s2

   3:                 Apple_Boot Boot OS X               134.2 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_CoreStorage FUSION                  999.9 GB   disk1s2


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


/dev/disk3 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            Macintosh HD           +1.1 TB     disk3

                                Logical Volume on disk0s2, disk1s2

                                28A728C6-466A-4263-8F19-581810A1A5CE

                                Unencrypted


----------



## macomaniac (20 Octobre 2016)

Hé ! Hé !

Pas de second *booter* sur le grand SSD > ce qui n'a pas empêché le *Volume Logique* d'avoir été formellement généré.

Il ne te reste plus qu'à rétro-cloner le contenu de *MAXTOR* dans *Macintosh HD* (la tâche déjà créée dans «CCC» doit toujours être valide, puisque les noms de volumes n'ont pas changé).

Comme «CCC» n'est pas capable de cloner la *Recovery HD* en-dessous d'un *CoreStorage* >

- le premier test interviendra si tu re-démarres avec "_alt_" : un seul volume *Macintosh HD* ? Combien de temps pour démarrer ?

- le 2è test consistera,  une fois démarré en mode *Recovery*, à lancer l'option : "_Ré-installer OS X_" > le volume *Macintosh HD* sera-t-il toujours grisé ? Ou choisissable ? S'il est choisissable > lancer la réinstallation du Système (quand tu auras le temps pour ce faire).

- le 3è test (si le 2è s'est bien déroulé) consistera à repasser une commande :

```
diskutil list
```
 afin de vérifier si une partition *Recovery HD 650 MB disk1s3* a bien été créée sur le grand SSD.​
=> tout pourrait se dérouler sans anicroches. Mais l'expérience montre qu'avec le *CoreStorage* : on ne sait jamais...


----------



## fl0rian67 (20 Octobre 2016)

Le rétro-clonage s'est bien déroulé.
Test 1 : Plus qu'un seul volume *Macintosh HD*, démarrage en 47 secondes .
Test 2 : Impossible de réinstaller macOS sur *Macintosh HD* en mode Recovery_.
_
Est-ce que tu as une solution pour le temps de démarrage et le mise en place d'un *Recovery HD* ?
Je me demande si le plus simple ne serait pas de séparer les SSD, d'installer macOS et Boot Camp sur le SSD d'*1 To* et de " laisser " le SSD de *120 Go* en secondaire, comme stockage, Time Machine ou autre ?
Par contre je ne sais pas quel est mon SSD le plus rapide.


----------



## macomaniac (21 Octobre 2016)

Tout était expérimental et non documenté dans cette tentative de création d'un Fusion Drive associant 2 SSD au lieu d'1 SSD et d'1 HDD.

La conclusion des tests semble être la suivante : l'architecture *CoreStorage* en mode associatif (Fusion Drive) n'a pas été conçue pour associer 2 disques de même type (2 SSD - mais l'association de 2 HDD conduirait à la même issue) ; mais 2 disques de nature hétérogène (1 SSD "moteur" et 1 HDD "remorqué").

S'il est possible formellement de combiner 2 SSD dans un dispositif *CoreStorage* Fusion Drive pour exporter un seul *Volume Logique* et s'il est possible d'y installer un Système OS X ; il y a des ombres au tableau : nécessité de supprimer un des booters pour n'avoir qu'un disque à l'affiche > ralentissements au démarrage > impossibilité de ré-installer l'OS à partir d'une session *Recovery* > impossibilité par là-même de faire créer une *Recovery HD* en queue de grand SSD > vraisemblablement impossibilité d'utiliser l'«Assistant BootCamp» pour repartitionner le *Volume Logique* et installer Windows.

Je pense que cet _iMac 27" Late_2013_ était équipé d'usine d'un Fusion Drive associant le SSD de 120 Go toujours en place et un HDD de 1 To > et que l'ancien propriétaire a remplacé ce HDD par un SSD 2,5 pouces. Même si le SSD format barrette bénéficie d'une forte vitesse de liaison > le branchement de l'actuel SSD 2,5 pouces est lui aussi doté d'une grande vitesse de liaison (6 Gigabits). Pour le vérifier va à : _Menu_  > _À propos de ce Mac_ > _Rapport Système..._ > _Matériel_ > _SATA_ > dans le champ de droite listant les disques : clique successivement sur les intitulés de disques et tu auras en-dessous l'indication de la vitesse de liaison.

Quelqu'un qui voudrait persévérer dans le mode *CoreStorage* associatif (Fusion Drive) pourrait évidemment tenter de faire du SSD 2,5 pouces de *1 To* le disque "moteur" et du SSD barrette de *120 Go* le disque "remorqué" (renverser les rôles en quelque sorte) > mais je pense que les mêmes problèmes surviendraient en ce qui concerne la possibilité de ré-installer > la génération d'une *Recovery HD* > la validation de ce dispositif par l'«Assistant BootCamp».

Le résumé de cette expérimentation me paraît être qu'il est inutile de persévérer dans cette voie. L'architecture logique sera toujours boîteuse quelque part. Il y aura toujours des ombres au tableau. Bref : je pense qu'il est préférable de refermer la piste du *CoreStorage* Fusion Drive qui manifestement n'a pas été conçu pour associer des disques de type égalitaire (2 SSD).

Je ne pense pas que tu aies à regretter tes expérimentations > car tu as atteint à travers elles une certitude « théorique », même si elle est négative : la non viabilité d'un dispositif *CoreStorage* Fusion Drive pour combiner 2 SSD.

--------------------​Je m'étais dit, ce matin, que l'architecture logique associative plus ancienne : l'*appleRAID* de type *concaténé* pouvait offrir une perspective intéressante, pour combiner 2 SSD afin d'exporter un seul volume. Je viens de créer ce dispositif pour associer les 2 partitions principales de 2 clés UBS et force est de constater qu'on va droit au-devant des mêmes problèmes qu'avec le *CoreStorage* Fusion Drive pour la raison suivante : *2* *booters Apple_Boot Boot OS X* s'installent juste en-dessous de chacune des partition-disques supportant le *RAID concaténé *(partitions montant un volume aussi vide que celui des *booters* du *CoreStorage* - ce qui montre que le *CoreStorage* a emprunté la logique du *booter vide* à l'*appleRAID* plus ancien).

À cause de la présence de cette paire de  *booters* > il y aura *2* affichages du même volume à l'écran obtenu avec "_alt_" > je ne suis pas sûr que le temps de démarrage ne sera pas multiplié par 2 > une *Recovery HD* ne pourra pas s'installer parce qu'elle doit coller la partition OS X et non être interceptée par un *booter* > l'«Assistant BootCamp» refusera logiquement de re-partitionner.

Donc je pense qu'il faut rejeter cette perspective expérimentale qui doit conduire aux mêmes impasses logiques que celle du *CoreStorage* Fusion Drive.

--------------------​On est donc conduit à maintenir la dissociation logique des 2 SSD. Mais il y un moyen de ruser qui serait le suivant.

Si tu n'avais pas besoin d'une partition géante pour «Windows» (disons s'il te paraissait suffisant qu'elle ait *60 Go* - du moins dans un 1er temps) et si parallèlement une partition-Logicielle OSX de *60 Go* également te paraissait suffisante (je dis : Logicielle = système + applications, à l'exclusion des données - cela dans un 1er temps encore) => alors voici une possibilité qui va ressembler furieusement à ton dispositif de départ :

*- a)* tu installes OS X dans le volume unique du SDD de *120 Go* (clonage possible). *Recovery HD* installée sous la partition *Macintosh HD* par «CCC».

*- b)* tu déportes une copie de ton dossier d'utilisateur dans le volume unique du SSD de *1 To*. Tu fais de ce dossier d'utilisateur copié sur le SSD *1 To* ton dossier de départ de session (un simple changement d'adresse suffit dans ta "carte d'identité" d'utilisateur : ce procédé est éprouvé et marche parfaitement bien). Tu supprimes l'original recelé dans le répertoire des Utilisateurs de l'OS du SSD dde *120 Go*. Tu n'as plus ainsi que le logiciel dans le volume OS X.

*- c)* tu lances l'«Assistant BootCamp» et tu lui fais créer une partition *BOOTCAMP* de *60 Go* sur le SSD de *120 Go*. Ça devrait passer sans problèmes.​
Dans ce dispositif :

- tu disposerais d'une partition de *60 Go* pour l'aspect logiciel d'OS X mais ton compte d'utilisateur déporté sur le 2è SSD bénéfierait d'une capacité théorique de stockage de données de *1 To*. Les applications installables dans le dossier personnel des Applications du compte d'utilisateur seraient installées sur le grand SSD.

- il serait envisageable grâce au logiciel (payant) Winclone de cloner le Système Windows de la partition *BOOTCAMP* dans un volume secondaire du SSD de *1 To* repartitionné > vérifier si tu peux booter commodément sur ce Windows déporté. S'il n'y a pas d'interférences logiques. Ce qui rendrait possible de supprimer la partition *BOOTCAMP* originale de *60 Go* du petit SSD et de dilater la partition OSX à *120 Go* pour le logiciel ce qui deviendrait super-confortable.​
=> ça paraît un peu compliqué à mettre en place mais je pense qu'ainsi tu bénéficierais de la super-vitesse du SDD barrette de *120 Go* pour l'OS (il doit avoir un débit de 700 Mo/s) et tu n'aurais pas de limitations de stockage de données, puisque ton dossier d'utilisateur résiderait sur le grand SSD de *1 To*. Et le système Windows serait clonable après coup dans un volume démarrable du grand SSD re-partitionné. Il faudrait juste vérifier que le boot alternatif OS X <=> Windows s'opère sans problème d'un disque à l'autre.

=> à toi de voir si cette perspective t'agrée.
​


----------



## fl0rian67 (21 Octobre 2016)

Salut ! J'ai actuellement 80 Go de logiciels sur macOS (et j'aimerais rajouter une petite marge de confort) ce qui laisserait très peu pour Windows dont je comptais faire une partition d'environ 250 Go.

Ton dispositif me paraît comme tu as dis, un peu compliqué, et encore une fois expérimental, non ?
Est-ce que ce que j'avais proposé précédemment est possible ? > tout installer sur le SSD *1 To* en " négligeant " le SSD *120 Go.*

Vitesses de liaison :
Apple SSD *120 Go* : 5.0 GT/s
Crucial SSD *1 To* : 6 Gigabits
C'est la même chose GT/s et Gigabits ?


----------



## macomaniac (21 Octobre 2016)

Salut.

C'est que tu es gourmand, toi, en logiciels et en taille de Windows.

Alors tu peux tout installer sur le SSD Crucial de *1 To* et effectivement considérer que le SSD Apple de 1*20 Go* est un peu comme une super carte SSD express. La vitesse de liaison de 6 Gigabits (= SATA III) pour ton Crucial peut permettre jusqu'à 750 Mo/s > ce qui est supérieur à la vitesse intrinsèque de ton Crucial qui doit être dans les 500 Mo/s. Des performances remarquables en somme.

Donc je pense que, démarré sur ton clone *MAXTOR* > tu peux passer la commande :

```
diskutil coreStorage deleteLVG 7D0B3277-1B6A-4A83-A18F-8AC19A619234
```
 en espérant ce coup-ci une plus grande complaisance du Crucial. Tu n'as qu'à dire ce qui s'est passé > tableau de la commande *diskutil list* à la clé.


----------



## fl0rian67 (21 Octobre 2016)

macomaniac a dit:


> ce qui est supérieur à la vitesse intrinsèque de ton Crucial qui doit être dans les 500 Mo/s.


Tu voulais plutôt dire supérieur au SSD Apple, non ?
Oui je suis un peu gourmand  je suis infographiste et j'ai donc une bonne petite bibliothèque d'applications.


----------



## fl0rian67 (21 Octobre 2016)

Fusion Drive défusionné : 
*
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 Untitled                121.0 GB   disk0s2


/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 Untitled                999.9 GB   disk1s2


/dev/disk3 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk3

   1:                        EFI EFI                     209.7 MB   disk3s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk3s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk3s3


----------



## macomaniac (21 Octobre 2016)

Ce que je voulais dire c'est que la liaison SATA III permet jusqu'à 750 Mo/s > soit davantage que le débit intrinsèque du SSD Crucial qui y est connecté - qui doit être de l'ordre de 450 à 500 Mo/s. Donc la vitesse du SSD n'est pas bridée par la liaison SATA III.

Le connecteur Apple est un PCie et les SSD Apple sont des SSD barrettes : ça doit aller plus vite qu'avec le Crucial mais le Crucial offre déjà de bonnes performances.



fl0rian67 a dit:


> je suis un peu gourmand  je suis infographiste



Il fallait le dire tout de suite. Moi je suis un homme du texte, pas de l'image > j'ai toujours des OS squelettiques et je n'utilise pas de logiciels qui traitent les images ou les vidéos. Mon volume actuel d'«El Capitan» a 47 Go d'espace occupé.

Bon revenons aux disques. Comme ils ont le même nom, autant que tu les renommes pour les différencier par les 2 commandes :

```
diskutil renameVolume /dev/disk0s2 Stockage
diskutil renameVolume /dev/disk1s2 Macintosh\ HD
```
 et il ne te reste plus qu'à rétro-cloner *MAXTOR* dans *Macintosh HD*. Ce coup-ci «CCC» devrait te proposer de créer la partition de secours *Recovery HD* et tu dis : OUI.


----------



## fl0rian67 (21 Octobre 2016)

Je viens de remarquer en renommant les disques et en ouvrant CCC, que le disk0 a toujours été le SSD de *120 Go* et le disk1 le SSD de 1 To. Or là je vois que _" Stockage "_ est le SSD *1 To* et _" Macintosh HD "_ le SSD *120 Go*. J'ai donc vérifié avec la commande _diskutil list_ pour remarquer que maintenant c'est inversé :

/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.9 GB   disk0s2


/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            121.0 GB   disk1s2


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3

On voulait bien nommer _" Stockage "_ le SSD *120 Go* et _" Macintosh HD "_ le SSD *1 To*, non ? 

J'ai aussi eu un moment de doute quand au choix d'installer l'OS sur le SSD *Crucial* à la place du SSD *Apple*, à cause de la vitesse.
Je me suis rappelé que j'avais le logiciel Blackmagic Disk Speed Test et j'ai donc comparé les vitesses en écriture/lecture des 2 :
Crucial *1 To* : Write : 470 Mo/s. Read : 505 Mo/s
Apple *120 Go* : Write : 320 Mo/s. Read : 725 Mo/s

Je comprends bien le terme de lecture, mais j'ai un peu plus de mal avec le terme d'écriture. Concrètement, l'écriture intervient dans quelle genre de tâches quotidiennes ?


----------



## fl0rian67 (21 Octobre 2016)

Je suis revenu sur ton premier post (#42) et je trouve que la solution *b)* n'est finalement pas si mal :

Second OS=> sauvegarder les données de «Stockage» > effacer entièrement le disque *disk1* (*1 To*) à partir de la session du volume *SSD* (*disk0s2*) > installer un OS dans le néo-volume *Stockage* vide > démarrer sur cet OS > lancer son «Assistant BootCamp» > installer Windows sur une partition créée en-dessous > effacer les fichiers de l'OS dans «Stockage» (sans reformater) en ayant re-démarré sur l'OS du volume *SSD* du *disk0* > se servir de ce volume pour du stockage de données. Une «Recovery HD» aura été créée en-dessous de «Stockage» (et avant la partition *BOOTCAMP*) > la laisser en place (*650 Mo*) > car sa suppression pourrait invalider le caractère démarrable de la partition *BOOTCAMP*.


----------



## macomaniac (21 Octobre 2016)

Il y  a inversion des noms en effet. Bizarre, bizarre.

Alors une petite édition triangulaire pour remettre les pendules à l'heure :


```
diskutil renameVolume /dev/disk0s2 Brol
diskutil renameVolume /dev/disk1s2 Stockage
diskutil renameVolume /dev/disk0s2 Macintosh\ HD
```

=> vérifie que ça colle ce coup-ci.

Tu écris quand tu édites un fichier résidant sur le disque et sauvegardes ton édition, ou si tu ajoutes un fichier par téléchargement, ou création + sauvegarde, ou encore copie à partir d'un autre disque, ou si tu supprimes des fichiers qui étaient inscrits sur le disque. Bref : écrire, c'est affecter ce qui est inscrit sur les blocs de la partition d'un disque, et que le système de fichiers gestionnaire te présente sous forme de fichiers résidant dans un espace de répertoire : un volume monté. Si tu lances le clonage des fichiers de *MAXTOR* dans *Macintosh HD* > «CCC» va écrire une copie des fichiers du 1er dans le second. Copier, c'est écrire. Effacer, c'est écrire. Sauvegarder, c'est écrire.

Les performances de ton Crucial sont très bonnes - n'hésite pas à installer l'OS sur ce disque.

Pour la gestion des 2 disques > j'aurais une contreproposition : tu clones *MAXTOR* dans le volume du Crucial (bien renommé *Macintosh HD* grâce aux commandes triangulaires ci-dessus) > et ensuite avec l'«Assistant BootCamp» tu crées une partition *BOOTCAMP* en queue du disque Crucial et tu y installes «Windows».

Ensuite > tu reformates le volume *Stockage* du SSD Apple de 120 Go en *FAT-32* > tu t'achètes le logiciel «Winclone» et tu clones le Windows du Crucial dans le volume de *120 Go *du SSD Apple (le logiciel reformate en *ntfs*). Puis tu supprimes la partition *BOOTCAMP* du Crucial et tu récupères cet espace à la partition *Macintosh HD*. Tu aurais ainsi 2 volumes, chacun occupant l'essentiel d'un disque : OS X sur Crucial (999 Go) et Windows sur Apple (120 Go).


----------



## fl0rian67 (21 Octobre 2016)

OK merci .
Démarrage de l'OS sur le SSD *1 To* en 47 secondes alors que les 2 disques sont séparés, autrement dit, même résultat qu'en mode Fusion Drive.

Concernant ta contreproposition, ça fait un peu juste 120 Go pour Windows, et Winclone c'est quand même 20, 40 ou 250$ selon la version que j'aimerais éviter de dépenser.

Bon, on aura presque tout essayé ! Je pense que le mieux est de :
- Clôner *Maxtor* + Recovery HD sur le SSD *120 Go*
- Effacer le SSD *1 To*
- Démarrer sur le Recovery HD
- Installer macOS 10.12 vierge sur le SSD *1 To*
- Installer Windows avec Boot Camp
- Transférer mes données du DDE vers le SSD de *1 To*

En gros c'est ce que tu avais proposé en solution *b)* au début. C'est le seul moyen d'avoir un démarrage en 17 secondes, de l'espace suffisant pour chaque OS, et un OS par disque (plus sécurisé si par exemple je chope un virus sur Windows).
Corrige moi si je me trompe.


----------



## macomaniac (21 Octobre 2016)

Oui : c'étais bien mon scénario *b)*. Une variante serait la suivante : une fois Windows installé sur une partition du bas du Crucial et la partition du haut effacée pour tes données > tu pourrais déporter dans le volume de cette partition ton dossier d'utilisateur total de l'OS du SSD Apple, puis effacer l'original > tu aurais plein de place pour le logiciel (120 Go) et tes données au lieu d'être dispersées dans le volume de stockage du Crucial seraient inhérentes à ton dossier d'utilisateur et réparties dans ses sous-dossiers.

Cette technique est parfaitement éprouvée et marche sans problème. Mais ce n'est qu'une variante (un peaufinage) tu scénario *b)*.

Tu n'as qu'à re-démarrer sur ton clone et poster le retour d'un *diskutil list* > histoire d'effacer le Crucial et arranger les noms de volumes.


----------



## fl0rian67 (21 Octobre 2016)

Le _" dossier d'utilisateur total "_, c'est-à-dire ?

J'ai déjà renommé les disques en remarquant qu'ils se sont de nouveau inversés. Je suppose qu'en nommant un disque _" Macintosh HD "_, il se place automatiquement en position 0. J'ai également effacé le SSD *Crucial* et là je suis en train de rétro-cloner *Maxtor* sur le SSD *Apple*. 


*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            121.0 GB   disk0s2


/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                999.9 GB   disk1s2


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *250.1 GB   disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS MAXTOR 250 Go           249.1 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


----------



## macomaniac (21 Octobre 2016)

Tout est en place - question disques.

Le dossier d'utilisateur, dit dossier de départ de session, est le dossier intitulé du nom court ou nom de compte de l'utilisateur, qui est localisé dans le répertoire-Système des *Utilisateurs* dans l'OS : s'il s'agit du dossier de départ de la session actuellement ouverte > il porte l'icône d'une petite maison blanche.

Ainsi, si tu vas voir à ce répertoire *Utilisateurs* du clone > tu trouveras dedans un dossier à ton nom court ou nom de compte portant l'icône d'une petite maison blanche - c'est le même nom que celui qui est inscrit dans l'invite de commande du «Terminal»  ou encore celui qui est inscrit en-dessous de l'icône d'une petite maison blanche dans la colonne de gauche des fenêtres du Finder.

C'est ce dossier de départ qui est recopiable à la fin dans le volume effacé du disque Crucial > avant d'être effacé du répertoire des *Utilisateurs*. Une simple modification d'adresse dans le fichier qui est ta "carte d'identité" d'utilisateur signifie au Système que ta session s'ouvre désormais à partir du dossier de départ cloné sur le disque Crucial. Un procédé commode pour alléger le volume d'un petit SSD.


----------



## fl0rian67 (22 Octobre 2016)

D'accord, merci pour l'explication. À vrai dire je n'utilise que le dossier _Téléchargements_ de mon dossier utilisateur, pour accueillir les fichiers téléchargés de Chrome. Tout le reste de mes données se trouve dans un dossier _Stockage_ sur le disque d'1 *To* avec images, musiques, dossiers pro, fichiers d'installations etc. (en fait tout sauf les applications).

Concernant l'étape _" effacer les fichiers de l'OS dans «Stockage» (sans reformater) en ayant re-démarré sur l'OS du volume *SSD* du *disk0*" _après avoir installé Windows, comment est-ce que je procède pour effacer ces fichiers ?


----------



## macomaniac (22 Octobre 2016)

Si j'avais suggéré de ne pas reformater > c'est pour ne pas affecter le statut formel de la partition. Car cela pourrait avoir un impact en retour sur la capacité de démarrage de la partition *BOOTCAMP*.

Mais si tu te contentes d'ouvrir le répertoire du volume dans une fenêtre du Finder > de sélectionner tous les éléments affichés > de les mettre à la corbeille > et de la vider => en fait de cette façon tu n'auras traité que les éléments visibles à l'affiche > mais tu n'auras pas éliminé ceux qui sont frappés d'invisibilité pour le Finder (ex. les répertoires-Système : *private*, *bin*, *sbin*, *usr*... qui portent le flag « *hidden* » ainsi que les fichiers dont l'intitulé commence par un *.*).

Donc, à supposer que le volume en question s'intitule rigoureusement *Stockage*, tu passes dans le «Terminal» de l'OS du volume Macintosh HD (SSD Apple 120 Go) la commande :

```
sudo rm -rf /Volumes/Stockage/*
```
 et cette commande de suppression récursive de tous les éléments inclus dans le volume *Stockage* devrait faire l'affaire [pour les centaines de milliers de fichiers impliqués > cela prend toujours... un certain temps].


----------



## fl0rian67 (22 Octobre 2016)

OK donc dans mon disque *Stockage* je supprime tout ce qu'il y a : les dossiers _Applications, Bibliothèque, Système _et_ Utilisateurs _(>12 Go au total).
Ça devrait également supprimer le *Boot* et le *Recovery HD*, non ? J'ai peur que ça casse ma partition Windows mais si c'est une technique éprouvée je ne devrais pas m'en faire.
Pour l'instant tout a fonctionné, Boot Camp est en train de créer la clé USB bootable.


----------



## macomaniac (22 Octobre 2016)

Non : il ne faut pas supprimer la *Recovery HD* du Crucial, car elle fait partie de la table de partition prise en compte lors de l'install de Windows. Mieux vaut ne rien déranger dans les partitions. Je ne sais pas quelle version de Windows tu installes.

La commande *rm* donnée, pour sa part, ne fait que supprimer les fichiers gérés en interne par le système de fichiers de la partition , sans rien toucher à la partition elle-même.

Si tu as fait l'installation formelle d'«El Capitan» il y a des chances qu'un format *CoreStorage* ait été greffé sur la partition *disk1s2* du Crucial. Tu n'as qu'à poster le tableau d'un *diskutil list* pour vérification.


----------



## fl0rian67 (22 Octobre 2016)

J'ai installé macOS Sierra et j'ai créé la clé USB Bootable sur Windows 10, mais lors de la sélection du pilote à installer sous Windows, j'ai ce message d'erreur :

_Aucun pilote de périphérique n'a été détecté. Vérifiez que le média d'installation contient les bons pilotes, puis cliques sur OK.
_
Mon iMac (27" late 2013) est pourtant bien compatible avec Windows 10, et j'ai vérifié en changeant de port USB.


----------



## fl0rian67 (22 Octobre 2016)

J'ai fermé la fenêtre d'installation en la rouvrant après avoir déplacé ma clé USB du clavier vers le port USB de l'iMac et ça a fonctionné.
J'ai entré ma licence Windows, OK, mais là si je ne me trompe pas, l'ordinateur ne détecte que le volume *Macintosh HD* (120 Go) au lieu du volume *Stockage* où la partition Boot Camp a été créé.

J'annule, j'efface le disque *Macintosh HD* et je le réinstalle après avoir installé Windows, non ?


----------



## fl0rian67 (22 Octobre 2016)

Encore une réponse à moi-même : au lieu d'effacer *Macintosh HD*, j'ai simplement sélectionné le disque *Stockage* comme disque de démarrage dans _Préférences Système > Disque de démarrage_.
J'ai redémarré sur la clé bootable et la partition a été détecté.

Cepdendant, encore un autre soucis :

_Windows ne peut pas être installé sur ce disque. Le disque sélectionné est du style de partition GPT._

J'ai donc fait quelques recherches sur le net avec un tuto qui apparemment fonctionnerait :

_Supprimez toute partition crée avec Boot Camp, 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 serait pas au bon format._

Sauf que j'ai déjà essayé cette technique en créant une partition en ExFAT, directement formaté en NTFS par Windows, en démarrant sur *EFI Boot*. Ça n'a pas marché, message d'erreur :

_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._

J'ai alors essayé la même opération en démarrant sur *Windows*, toujours impossible de cliquer sur _Suivant_, mais un autre message d'erreur :

_Nous n'avons pas pu créer de partition, ni localiser une partition déjà existante. Pour plus d'informations, voir les fichiers journaux d'installation._

Et c'est là que je sèche.


----------



## macomaniac (22 Octobre 2016)

Passe la commande :

```
sudo gpt show /dev/disk1
```
 et poste le tableau retourné.

À tous les coups tu as une table de partition secondaire *H*ybrid_*MBR* = *HMBR* sur le bloc *0* du disque 1 (Crucial) - table de partition qui devrait être détectée comme : « *suspicious MBR at sector 0* » par l'utilitaire *gpt*. Si c'est le cas > c'est de là que viennent tous tes ennuis.

Si tu veux un peu plus d'explications pour éclairer ces considérations lapidaires > reporte-toi à ce fil récent où j'ai un peu décortiqué les choses : ☞*impossible d'intaller Windows 10 sur la partition bootcamp*☜


----------



## fl0rian67 (22 Octobre 2016)

gpt show: /dev/disk1: Suspicious MBR at sector 0

      start        size  index  contents

          0           1         MBR

          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   486749576      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

  1953262984      262151         

  1953525135          32         Sec GPT table

  1953525167           1         Sec GPT header


----------



## macomaniac (22 Octobre 2016)

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* (*M*aster *B*oot *R*ecord) 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* (*G*UID *P*artition *T*able) 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* (*P*rotective_*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* (*E*FI_*S*ystem_*P*artition) > *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* (*H*ybrid_*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.​
--------------------​


----------



## fl0rian67 (22 Octobre 2016)

Effectivement _" l'informatique est l'inverse de la simplicité "_ 

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


----------



## macomaniac (22 Octobre 2016)

Je te propose dans un premier temps la méthode *a)
*
Tu passes la commande :

```
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 :

```
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*.


----------



## fl0rian67 (22 Octobre 2016)

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


----------



## macomaniac (22 Octobre 2016)

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).


----------



## fl0rian67 (22 Octobre 2016)

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.


----------



## fl0rian67 (22 Octobre 2016)

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._


----------



## macomaniac (23 Octobre 2016)

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.



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è...




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 *E*FI_*S*ystem_*P*artition de *209,7 Mo*. Celle-ci exactement :

```
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 (*EF**x00*) 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 :

```
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 :

```
diskutil info /Volumes/EFI
```
 on obtient régulièrement un tableau de paramètres dont voici le haut :

```
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 :

```
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 :

```
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 :

```
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 :

```
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 :

```
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 :

```
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...

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


----------



## fl0rian67 (23 Octobre 2016)

Hello ! Alors voici les 2 tableaux (à noter que disk0 : SSD *Crucial*, et disk1 : SSD *Apple* - eh oui ça s'est encore inversé) :


```
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
```


```
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"
```


----------



## macomaniac (23 Octobre 2016)

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 :

```
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 :

```
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 ?


----------



## fl0rian67 (23 Octobre 2016)

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 :


```
/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à.


----------



## macomaniac (23 Octobre 2016)

Erreur de saisie de ma part : il fallait lire disk0s*1* et pas disk0s*2* 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 :

```
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 :

```
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.


----------



## fl0rian67 (23 Octobre 2016)

Bon toujours pas. Honnêtement ça commence à vraiment me rendre fou ! Je crois que je vais abandonner.


----------



## macomaniac (23 Octobre 2016)

Donne le retour d'un :

```
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.]


----------



## fl0rian67 (23 Octobre 2016)

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._



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 :


```
/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.


----------



## macomaniac (23 Octobre 2016)

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* :

```
diskutil resizeVolume /dev/disk0s2 0b
```
 (le *0b* = *0*_*b*yte 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* :

```
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 :

```
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 *H*ybrid_*MBR*) avec affichage en dernier de l'invite de commande interactive :

```
Command (? for help):
```

Tu tapes simplement :

```
x
```
 (comme e*x*pert) et ↩︎ (tu valides) => le logiciel affiche la nouvelle invite de commande du mode expert :

```
Expert command (? for help):
```

Tu tapes :

```
n
```
 (comme *n*ew Protective MBR) et ↩︎ => *gdisk* te réaffiche sans commentaire l'invite de commande :

```
Expert command (? for help):
```
 (la modification est seulement en cache)

Tu tapes :

```
w
```
 (comme *w*rite) et ↩︎ => tu obtiens l'affichage :

```
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N):
```

Tu tapes :

```
y
```
 (comme *y*es) => *gdisk* te retourne :

```
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 :

```
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 *P*rotective_*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.


----------



## fl0rian67 (23 Octobre 2016)

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 :

```
gpt: unkwnown command: /dev/disk1
```
Je te colle l'ensemble des dernières opérations pour être sûr :

```
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
```


----------



## macomaniac (24 Octobre 2016)

*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 :

```
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* (*P*rotective_*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.


----------



## fl0rian67 (24 Octobre 2016)

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 .

Bon sinon voilà où ça en est après la dernière commande :

```
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
```


----------



## macomaniac (24 Octobre 2016)

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.


----------



## fl0rian67 (24 Octobre 2016)

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 (25 Octobre 2016)

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 :

```
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 :

```
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 :

```
diskutil partitionDisk /dev/disk0 gpt jhfs+ Macintosh\ HD 750g fat32 BOOTCAMP 0b
```

 créerait 
2 partitions
 principales (après l'
*ESP*
 = 
*E*FI *S*ystem *P*artition
 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*
.


----------



## fl0rian67 (25 Octobre 2016)

En tout cas j'en aurais appris des choses ! Je te remercie pour ton aide et t'envoie une bière toute fraîche en provenance d'Alsace


----------



## ninkasi67 (30 Octobre 2016)

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


----------



## macomaniac (30 Octobre 2016)

Salut *ninkasi
*
Quel est l'année de sortie de ton _MacBook Pro _? Quelle est la version d'OS X actuellement installée sur son disque ? Quelle est enfin la version de Windows que tu cherches à installer ?


----------



## ninkasi67 (30 Octobre 2016)

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 (30 Octobre 2016)

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* (*P*rotective_*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 :

```
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.


----------



## Deleted member 1099514 (30 Octobre 2016)

macomaniac a dit:


> 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* (*P*rotective_*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 :
> 
> ...


Hello @macomaniac 

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


----------



## ninkasi67 (30 Octobre 2016)

je crois que je vais abandonner windows sur Mac ....


----------



## ninkasi67 (30 Octobre 2016)

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 (30 Octobre 2016)

*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* (*P*rotective_*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 (10 Décembre 2016)

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


----------



## Fab'Fab (5 Décembre 2019)

Bonjour
Ca fonctionne avec Catalina et de l'USB-C/TB3 ?


----------



## Locke (5 Décembre 2019)

Fab'Fab a dit:


> 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.


----------



## Fab'Fab (5 Décembre 2019)

Oui, mais en passant par l'étape rétro clonage, c'est bon ?


----------



## Locke (5 Décembre 2019)

Fab'Fab a dit:


> Oui, mais en passant par l'étape rétro clonage, c'est bon ?


Oui comme je le mentionne en utilisant impérativement Winclone, puisque c'est ce que j'ai fait et que j'ai toujours mon boîtier Transcend Thunderbolt... https://www.amazon.fr/gp/product/B00NV9LSGW/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1 ...qui fonctionne depuis 2016.


----------



## nemrod (26 Juillet 2022)

Salut,

Est-ce que ça fonctionne avec un SSD en USB-C ? J'ai ce modèle : https://www.amazon.fr/gp/product/B08GTYFC37/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

Sinon, je suis sous Monterey & Windows 10.

Merci


----------



## Locke (26 Juillet 2022)

nemrod a dit:


> Salut,
> 
> Est-ce que ça fonctionne avec un SSD en USB-C ? J'ai ce modèle : https://www.amazon.fr/gp/product/B08GTYFC37/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1
> 
> ...


Tu es conscient que ce tutoriel date de 2014 et que Winclone n'est _(plus)_ pas gratuit ? Honnêtement je n'en sais rien, je ne plus tester quoi ce soit avec un iMac 24" M1. Attention, si tu as un problème, il te faudra réinstaller ta version de Windows en interne.


----------



## nemrod (26 Juillet 2022)

Oui, j'ai bien vu la date du premier message de même que celle du dernier. Je cherche comment supprimer la partition interne pour en avoir une sur un SSD USB-C, je suis prêt à risquer de perdre les données.


----------



## Locke (26 Juillet 2022)

nemrod a dit:


> Oui, j'ai bien vu la date du premier message de même que celle du dernier. Je cherche comment supprimer la partition interne pour en avoir une sur un SSD USB-C, je suis prêt à risquer de perdre les données.


Quel est le modèle exact de ton Mac dont on ignore tout, taille écran, année, que dis /A propos de ce Mac ? Il y a peut-être une solution différente qui est ici... https://forums.macg.co/threads/inst...-adaptateur-sans-assistant-boot-camp.1330007/ ...le problème est qu'avec mon iMac 24" M1, je ne sais pas si Virtual Box fonctionnera correctement sous macOS Monterey _(j'en doute beaucoup)_.


----------



## nemrod (26 Juillet 2022)

Voila pour mon Mac:




Merci pour le lien


----------



## Locke (26 Juillet 2022)

nemrod a dit:


> Voila pour mon Mac:


Je ne vais pas m'avancer vu que je ne peux pas vérifier, mais je pense que Virtual Box ne fonctionnera pas correctement. En fait ce sera la partie ou il faudra leurrer macOS Monterey pour lui faire croire que la partition Windows est en interne alors que l'on va utiliser un SSD externe et peu importe si le SSD est en USB 3.0 ou Thunderbolt.


----------



## nemrod (27 Juillet 2022)

Ok, merci


----------

