# Dualboot SSD/HDD



## mandracore (2 Avril 2016)

Bonjours,
Possédant un Macbook Pro mi 2012 je souhaite lui faire une petite upgrade, je m'explique :
Je vais retirer le lecteur CD et le remplacer par un SSD. Je voudrais par la suite installer CentOS ou Qubes ou encore Windows je ne me suis pas encore fixé sur l'OS à installer. Enfin bref je me demandais si, à l'aide de REfind il était possible de détecter le SSD et booter dessus ?
Comme ça j'aurais OSX El Capitan installé sur le HDD de base et un autre OS sur le SSD.
Quelqu'un l'a t-il déjà fait ?


----------



## macomaniac (2 Avril 2016)

Bonjour *mandracore
*
Personnellement, je mettrais plutôt le SSD à la place du HDD, et je déporterais le HDD à la place du Super-Drive > cela fait, tu peux très bien créer un Fusion Drive associant les 2 disques dans un CoreStorage qui exporterait un Volume Logique unique > installer alors «El Capitan» dans ce volume > ce qui donnera une «Recovery HD» sur une partition créée hors CoreStorage sur le HDD.

À partir de là, l'«Assistant BootCamp» accepterait de re-partitionner le Volume Logique «El Capitan» pour produire une nouvelle partition, toujours sur le HDD, en-dessous de la «Recovery HD» > possibilité d'installer Windows sur cette partition (si tout se passe bien).

Un démarrage avec "alt" permettrait alors de choisir un des 2 OS. Sinon, «rEFInd», en effet, afficherait automatiquement les 2 volumes à son écran de gestion des disques de démarrage.

C'est un scénario comme un autre. Pour le tien, mauvaise idée (à mon sens du moins) de vouloir installer «El Capitan» sur le HDD : ça va ramer, c'est sûr. 10.11 est un OS qu'il vaut mieux avoir installé sur un SSD. Ou un Fusion Drive : le Système serait installé a priori sur la partition du SSD, et les données qui excèderaient cet espace seraient reportées sur le secteur du HDD sans ralentissement sensible à l'usage. Pour ce qui est d'un OS secondaire, une autre partition du HDD serait mieux indiquée alors, plutôt que le SSD - non ?


----------



## mandracore (2 Avril 2016)

Alors, je m'explique: je ne veux pas passer par bootcamp et compagnie, celui -ci ne sert uniquement qu'à partitionner son disque dur afin de créer une partition de type MBR qui servirai pour windows. Je ne souhaite pas non plus créer un fusion drive et encore moins utiliser un système de volumes logiques connectés. De plus OSX el capitan est déjà installé sur mon HDD et fonctionne parfaitement.
Je me disais :
Dans la mesure ou le SSD contiendra une partition de type MBR est ce que REfind va la détecter vu que ce n'est pas sur l'emplacement "conventionnel" ?


----------



## macomaniac (2 Avril 2016)

«rEFInd» n'est absolument pas susceptible : il détecte tout volume recélant un boot_loader de type .efi comme démarrable et l'affiche en conséquence à son écran gestionnaire, en proposant de l'exécuter comme lanceur de cet OS - ce, où que soit installé l'OS en question (disque interne A ou B, ou toute espèce de disque externe attaché au Mac).

La difficulté consiste plutôt à installer le Système en question. Pour ce qui est de Windows, «Winclone» doit pouvoir faire un clonage, à condition de disposer de l'image-archive d'un Windows pré-installé.


----------



## mandracore (2 Avril 2016)

L'installation d'OS type centOS ou Qubes est relativement facile -> DDE bootable avec REfind. L'installateur demande sur quel DD ou SSD installer. J'ai déjà réalisé cette manip avec des macbook pro et imac de ce côté la il n'y a pas de problèmes.


----------



## macomaniac (3 Avril 2016)

Comme je suis familier de «rEFInd» que j'utilise au quotidien, tu apprécieras peut-être le partage de quelques informations (tant pis si certaines recoupent ce que tu sais déjà) :

*- a)* pour installer «rEFInd», il suffit de télécharger le dernier dossier de ses binaires ici : ☞*refind-bin-0.12.2.zip*☜ ; puis de saisir *sudo* dans une fenêtre du «Terminal», sauter un espace et glisser-déposer de l'exécutable *refind-install* présent dans le dossier refind-bin-0.10.2, puis validation avec frappe du mot-de-passe admin à l'aveugle.

*- b)* en quoi consiste exactement cette installation ? En 2 choses :

*- b1)* une installation des binaires de «rEFInd» sur l'*ESP* (*E*FI *S*ystem *P*artition) qui est l'en-tête d'une *GPT* (*G*UID *P*artition *T*able) régulière = /dev/disk0*s1*. Voici une capture figurant ces binaires de «rEFInd» sur l'*ESP* de mon SSD :





​- b2) une inscription en NVRAM, à la rubrique *efi-boot-device* qui renseigne pour l'EFI l'adresse du boot_loader à exécuter automatiquement :
*efi-boot-device*    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>*UUID*</key><string>
*B51A6E00-4320-4AFB-86FB-E71F18E6F7FB*</string></dict></dict><key>IOEFIShortForm</key><true/><key>BLLastBSDName</key><string>*disk0s1*</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>*Path*</key><string>*\EFI\refind\refind_x64.efi*</string></dict></array>%00
​=> en conséquence, l'EFI en visitant la NVRAM va enregistrer l'instruction de boot automatique, aller à la partition disk0*s1* (= *ESP*) ciblée par son UUID universel, et suivre dans son volume «EFI» le chemin de boot : /EFI/refind/*refind_x64.efi* pour exécuter ce dernier boot_loader.

- c) naguère, «rEFInd» était incompatible avec un format CoreStorage (non-chiffré ou chiffré) sur la partition de l'OS (/dev/disk0*s2*) => dès qu'un CoreStorage était en place, le gestionnaire de boot de «rEFInd» n'était plus utilisable. Mais _Roderick Smith_ remet toujours en chantier son logiciel. J'ai donc pu constater que, désormais, «rEFInd» gère sans aucune difficulté l'existence d'un CoreStorage non-chiffré (comme l'installateur d'«El Capitan» se complaît à le greffer à l'installation sur la partition de l'OS), comme d'un CoreStorage chiffré (issue de l'activation de «FileVault»). Chapeau, Mr _Smith_ !

- d) l'inscription d'un chemin privilégié au boot_loader *refind_x64.efi* de l'*ESP* en NVRAM conditionnant l'exécution automatique de ce démarreur par l'EFI et donc l'affichage automatique de l'écran du gestionnaire «rEFInd», il est évident que toute altération d'adresse en NVRAM équivaut _ipso facto _à une désactivation de «rEFInd» (non à sa désintallation, puisque les binaires restent en place, intouchés, sur l'*ESP* - mais désormais inadressables). Cette altération d'adresse intervient dès qu'on choisit un disque de démarrage dans le panneau éponyme des _Préférences Système _de l'OS (ou dans la tableau de bord   de la «Recovery HD». Mais aussi dès qu'on procède à une installation-Système (mise-à-niveau, restauration), parce que l'installateur, afin de pouvoir re-démarrer sur le volume-Système, instruit en NVRAM une adresse de boot automatique pour l'EFI qui efface celle de «rEFInd». Enfin, si on efface la NVRAM, ce qui efface l'adresse au boot_loader de «rEFInd» à la rubrique *efi-boot-device*.

Il s'ensuit 2 conséquences : 1° ne pas hésiter à faire un *nvram -p* dans le «Terminal» pour scruter l'adresse mentionnée à l'*efi-boot-device* => si l'on ne lit pas un <key>*Path*</key><string>*\EFI\refind\refind_x64.efi*</string></dict></array>%00 à la fin, c'est que «rEFInd» est désactivé et doit être réactivé ; 2° toujours garder le dossier des binaires refind-bin-0.10.2 dans un endroit accessible de l'OS, de manière à pouvoir à volonté ré-exécuter son installateur *refind-install* (en cas de binaires pré-installés, l'installateur sait les échapper pour se cantonner à restaurer l'adresse de boot en NVRAM).​


----------

