Bootcamp sur MacBook Pro avec Optibay

Aucun. Personnellement, sur mon MacBook Pro 17" Late_2011 j'ai désactivé le SIP et j'utilise «rEFInd» pour gérer les 14 Systèmes démarrables installés sur mon SSD de 1 To [NB. on peut réactiver le SIP après que l'adresse au boot_loader de «rEFInd» soit inscrite en NVRAM].
Ah ouais 14 systemes quand meme.. Quelles sont les demarches ?
 
Dernière édition par un modérateur:
- a) pour désactiver le SIP.

Re-démarre en pressant les 2 touches ⌘R > tu atteins (assez lentement) l'environnement de secours Recovery avec une fenêtre de 4 Utilitaires OS X > tu la négliges > barre de menus supérieure de l'écran > menu Utilitaires > sous-menu Terminal.

Dans la fenêtre ouverte tu saisis la commande :
Bloc de code:
csrutil disable
et ↩︎.

L'instruction de désactivation du SIP s'appliquera à la NVRAM au re-démarrage.

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

- b) pour installer «rEFInd».

En fait, il y a 2 choix. Car «rEFInd» installe ses exécutables sur la partition GUID n°1 du disque qui supporte le Système OS X à partir duquel on opère. Or tu as 2 disques (SSD & HDD) supportant chacun un même type d'OS X opérationnel. Donc tu as 2 partitions GUID n°1 dite ESP (EFI System Partition) susceptibles d'accueillir les exécutables de «rEFInd» : soit la disk0s1 du SSD > soit la disk1s1 du HDD.

Je suis forcé par le dispositif matériel et logique complexe de ton Mac > de m'engager moi-même dans des raisonnements eux-mêmes complexes. Donc ici la question est : à partir de quel OS installer «rEFInd» > ce qui revient à demander : sur laquelle des 2 partitions ESP lui faire installer ses binaires : la disk0s1 ou la disk1s1 ?

C'est peut-être du "chinois" > mais il faut bien "chinoiser" ici : si les exécutables de «rEFInd» sont installés sur la disk0s1 du SSD > le HDD va être vu comme un disque secondaire quoique matériellement interne ; si les exécutables de «rEFInd» sont installés sur la disk1s1 du HDD > le HDD a des chances d'être vu comme le disque principal et le SSD quoique en position logique principale (disk0 ou pemier device) a des chances d'être vu comme disque secondaire > la primauté du HDD en tant que disque support des binaires de «rEFInd» pourrait permettre alors la reconnaissance du volume BOOTCAMP comme bootable... [tu vois le topo ?]

Je te propose donc d'installer «rEFInd» sur la partition ESP disk1s1 du HDD > pour cela > tu dois re-démarrer depuis la Recovery (où tu as désactivé le SIP) avec "alt" et ouvrir une session dans le Volume Logique Mac OS X 2 du HDD.

Ce préalable accompli > tu télécharges ici ☞rEFInd☜ qui est un boot_manager créé et maintenu par Roderick Smith > tu obtiens un refind-bin-0.10.3.zip que tu désarchives en un dossier refind-bin-0.10.3. Je te conseille de conserver soigneusement ce dossier dans un endroit visible (par exemple l'espace racine de ton volume Mac OS X 2) afin de pouvoir réexécuter son programme d'installation si besoin était.

Cela fait > tu ouvres une fenêtre du «Terminal» dans laquelle tu tapes seulement :
Bloc de code:
sudo
et tu sautes un espace > puis tu fais un glisser-déposer direct dans la fenêtre de l'exécutable présent dans le dossier refind-bin-0.10.3 = refind-install > ce qui inscrit automatiquement le chemin au fichier et son nom > ce qui te donne une commande du type :
Bloc de code:
sudo /chemin_au_fichier/refind-install
et ↩︎ > 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 ↩︎.

L'exécutable va monter la partition ESP (EFI System Partition) disk1s1 du disque en un volume = EFI > dans lequel existe déjà un dossier EFI contenant un sous-dossier APPLE > à côté, l'installateur va créer 2 sous-dossiers refind et tools > le sous-dossier refind contenant (entre autres) le boot_loader refind_x64.efi de «rEFInd» > puis le volume EFI va être démonté > et un chemin de boot automatique de l'EFI inscrit en NVRAM à la rubrique efi-boot-device.

Ainsi > en cas de démarrage sans options > l'EFI (Programme Interne du Mac ici) va exécuter automatiquement le boot_loader refind_x64.efi sur la partition disk1s1 de l'ESP du HDD > ce qui va faire s'afficher l'écran gestionnaire de démarrage de «rEFInd». Une fois que tu as sélectionné un volume > tu peux éventuellement en pressant la touche F2 faire s'afficher la panneau des démarrages avec option sur ce volume > tu lances le démarrage par la touche "Entrée" comme à l'ordinaire.

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

=> une fois «rEFInd» installé depuis la session de ton volume Mac OS X 2 du HDD > re-démarre normalement (sans option - pas de touche "alt") > tu devrais obtenir l'écran gestionnaire de disques démarrables de «rEFInd» > est-ce que le volume BOOTCAMP est affiché (même sous un nom inhabituel) ? > si oui et si tu le choisis > peux-tu démarrer dessus ?
 
Dernière édition par un modérateur:
- a) pour désactiver le SIP.

Re-démarre en pressant les 2 touches ⌘R > tu atteins (assez lentement) l'environnement de secours Recovery avec une fenêtre de 4 Utilitaires OS X > tu la négliges > barre de menus supérieure de l'écran > menu Utilitaires > sous-menu Terminal.

Dans la fenêtre ouverte tu saisis la commande :
Bloc de code:
csrutil disable
et [emoji669]︎.

L'instruction de désactivation du SIP s'appliquera à la NVRAM au re-démarrage.

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

- b) pour installer «rEFInd».

En fait, il y a 2 choix. Car «rEFInd» installe ses exécutables sur la partition GUID n°1 du disque qui supporte le Système OS X à partir duquel on opère. Or tu as 2 disques (SSD & HDD) supportant chacun un même type d'OS X opérationnel. Donc tu as 2 partitions GUID n°1 dite ESP (EFI System Partition) susceptibles d'accueillir les exécutables de «rEFInd» : soit la disk0s1 du SSD > soit la disk1s1 du HDD.

Je suis forcé par le dispositif matériel et logique complexe de ton Mac > de m'engager moi-même dans des raisonnements eux-mêmes complexes. Donc ici la question est : à partir de quel OS installer «rEFInd» > ce qui revient à demander : sur laquelle des 2 partitions ESP lui faire installer ses binaires : la disk0s1 ou la disk1s1 ?

C'est peut-être du "chinois" > mais il faut bien "chinoiser" ici : si les exécutables de «rEFInd» sont installés sur la disk0s1 du SSD > le HDD va être vu comme un disque secondaire quoique matériellement interne ; si les exécutables de «rEFInd» sont installés sur la disk1s1 du HDD > le HDD a des chances d'être vu comme le disque principal et le SSD quoique en position logique principale (disk0 ou pemier device) a des chances d'être vu comme disque secondaire > la primauté du HDD en tant que disque support des binaires de «rEFInd» pourrait permettre alors la reconnaissance du volume BOOTCAMP comme bootable... [tu vois le topo ?]

Je te propose donc d'installer «rEFInd» sur la partition ESP disk1s1 du HDD > pour cela > tu dois re-démarrer depuis la Recovery (où tu as désactivé le SIP) avec "alt" et ouvrir une session dans le Volume Logique Mac OS X 2 du HDD.

Ce préalable accompli > tu télécharges ici ☞rEFInd☜ qui est un boot_manager créé et maintenu par Roderick Smith > tu obtiens un refind-bin-0.10.3.zip que tu désarchives en un dossier refind-bin-0.10.3. Je te conseille de conserver soigneusement ce dossier dans un endroit visible (par exemple l'espace racine de ton volume Mac OS X 2) afin de pouvoir réexécuter son programme d'installation si besoin était.

Cela fait > tu ouvres une fenêtre du «Terminal» dans laquelle tu tapes seulement :
Bloc de code:
sudo
et tu sautes un espace > puis tu fais un glisser-déposer direct dans la fenêtre de l'exécutable présent dans le dossier refind-bin-0.10.3 = refind-install > ce qui inscrit automatiquement le chemin au fichier et son nom > ce qui te donne une commande du type :
Bloc de code:
sudo /chemin_au_fichier/refind-install
et [emoji669]︎ > 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 [emoji669]︎.

L'exécutable va monter la partition ESP (EFI System Partition) disk1s1 du disque en un volume = EFI > dans lequel existe déjà un dossier EFI contenant un sous-dossier APPLE > à côté, l'installateur va créer 2 sous-dossiers refind et tools > le sous-dossier refind contenant (entre autres) le boot_loader refind_x64.efi de «rEFInd» > puis le volume EFI va être démonté > et un chemin de boot automatique de l'EFI inscrit en NVRAM à la rubrique efi-boot-device.

Ainsi > en cas de démarrage sans options > l'EFI (Programme Interne du Mac ici) va exécuter automatiquement le boot_loader refind_x64.efi sur la partition disk1s1 de l'ESP du HDD > ce qui va faire s'afficher l'écran gestionnaire de démarrage de «rEFInd». Une fois que tu as sélectionné un volume > tu peux éventuellement en pressant la touche F2 faire s'afficher la panneau des démarrages avec option sur ce volume > tu lances le démarrage par la touche "Entrée" comme à l'ordinaire.

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

=> une fois «rEFInd» installé depuis la session de ton volume Mac OS X 2 du HDD > re-démarre normalement (sans option - pas de touche "alt") > tu devrais obtenir l'écran gestionnaire de disques démarrables de «rEFInd» > est-ce que le volume BOOTCAMP est affiché (même sous un nom inhabituel) ? > si oui et si tu le choisis > peux-tu démarrer dessus ?

Tout d'abord merci beaucoup pour ce super tuto, j'obtient en effet l'écran pour choisir au démarrage du mac mais bootcamp ne boot toujours pas (tiret blanc qui clignote..)
Faut-il que j'installe rEFInd sur Macintosh HD sur le SSD ?
 
Tu peux essayer cette alternative afin d'épuiser le champ de possibilité offert par «rEFInd».
Est-ce que tu penses que ca en vaut la peine ? Faut-il desinstaller rEFInd puisque je vais installer sur Macintosh HD ?
 
Ce n'est pas la peine de désinstaller. Tu démarres sur Macintosh HD > et tu tapes dans son «Terminal» :
Bloc de code:
sudo
seulement > tu sautes un espace > tu vas chercher dans le volume alternatif monté Mac OS X 2 le dossier refind-bin-0.10.3 et tu fais un glisser-déposer du fichier refind-install que tu y trouves dans la fenêtre du «Terminal» > tu exécutes la commande.

Les binaires de «rEFInd» vont être installés sur la partition disk0s1 du SSD et le chemin de démarrage en NVRAM édité en conséquence (ainsi les binaires subsistant sur la partition disk1s1 du HDD seront désormais inactifs et ne gêneront en rien).
 
Ce n'est pas la peine de désinstaller. Tu démarres sur Macintosh HD > et tu tapes dans son «Terminal» :
Bloc de code:
sudo
seulement > tu sautes un espace > tu vas chercher dans le volume alternatif monté Mac OS X 2 le dossier refind-bin-0.10.3 et tu fais un glisser-déposer du fichier refind-install que tu y trouves dans la fenêtre du «Terminal» > tu exécutes la commande.

Les binaires de «rEFInd» vont être installés sur la partition disk0s1 du SSD et le chemin de démarrage en NVRAM édité en conséquence (ainsi les binaires subsistant sur la partition disk1s1 du HDD seront désormais inactifs et ne gêneront en rien).
Bon ca ne marche toujours pas :( ! Pourtant c'etait tellement logique que j'etais sur que ca allait marcher m'enfin bon ... Un moyen de desinstaller rEFInd ?
 
Dernière édition:
Pour "désinstaller" «rEFInd», il suffit de désactiver l'exécution automatique de son boot_loader par l'EFI au démarrage. Ce qui revient à effacer l'adresse à ce boot_loader inscrite en NVRAM (qui est une petite mémoire non volatile de la Carte-Mère visitée en phase de pré-démarrage par l'EFI afin d'y charger les instructions inscrites).

Une méthode facile pour cela : dans ta session de l'OS du volume Macintosh HD de ton SSD > tu vas à : Menu  > Préférences Système > Disque de démarrage > tu sélectionnes le volume Macintosh HD affiché dans le champ rectangulaire > tu presses le bouton "Redémarrer" => tu vas pouvoir vérifier que ton Mac re-démarre automatiquement sur l'OS «El Capitan» de ton SSD, sans affichage de l'écran gestionnaire de boot de «rEFInd». Simplement, parce qu'en NVRAM une adresse au volume de cet OS a été substituée à celle qui pointait au boot_loader : refind_x64.efi de «rEFInd».

--------------------
Pourtant c'etait tellement logique que j'etais sur que ca allait marcher

J'étais moins confiant que toi, de mon côté, dans le succès du procédé «rEFInd» - mais autant vérifier expérimentalement n'est-ce pas ? si un boot_manager alternatif de celui, natif, de l'EFI du Mac ne pouvait pas faire l'affaire...

Pour que je me représente avec exactitude la situation qui est la tienne : le volume BOOTCAMP est-il affiché à l'écran obtenu avec "alt" ou à celui de «rEFInd», mais non démarrable si tu le choisis ? Ou bien le volume BOOTCAMP n'est-il pas affiché du tout  sur aucun de ces écrans gestionnaires de démarrage, et par suite non choisissable comme disque de démarrage ?
 
Pour "désinstaller" «rEFInd», il suffit de désactiver l'exécution automatique de son boot_loader par l'EFI au démarrage. Ce qui revient à effacer l'adresse à ce boot_loader inscrite en NVRAM (qui est une petite mémoire non volatile de la Carte-Mère visitée en phase de pré-démarrage par l'EFI afin d'y charger les instructions inscrites).

Une méthode facile pour cela : dans ta session de l'OS du volume Macintosh HD de ton SSD > tu vas à : Menu  > Préférences Système > Disque de démarrage > tu sélectionnes le volume Macintosh HD affiché dans le champ rectangulaire > tu presses le bouton "Redémarrer" => tu vas pouvoir vérifier que ton Mac re-démarre automatiquement sur l'OS «El Capitan» de ton SSD, sans affichage de l'écran gestionnaire de boot de «rEFInd». Simplement, parce qu'en NVRAM une adresse au volume de cet OS a été substituée à celle qui pointait au boot_loader : refind_x64.efi de «rEFInd».

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


J'étais moins confiant que toi, de mon côté, dans le succès du procédé «rEFInd» - mais autant vérifier expérimentalement n'est-ce pas ? si un boot_manager alternatif de celui, natif, de l'EFI du Mac ne pouvait pas faire l'affaire...

Pour que je me représente avec exactitude la situation qui est la tienne : le volume BOOTCAMP est-il affiché à l'écran obtenu avec "alt" ou à celui de «rEFInd», mais non démarrable si tu le choisis ? Ou bien le volume BOOTCAMP n'est-il pas affiché du tout  sur aucun de ces écrans gestionnaires de démarrage, et par suite non choisissable comme disque de démarrage ?

Oui le volume est bien présent quand je démarre le Mac (avec ou sans rEFInd). Un nouveau problème est tout de même survenue lors de cette opération, je n'ai plus de son sur mon Mac avec les hauts parleurs, j'ai du son avec les écouteur et le prise jack du mac fait ressortir une lumière rouge. HELP!
 
Salut nerdyiman

Si le volume BOOTCAMP est affiché à l'écran du gestionnaire de boot de l'EFI comme à celui de «rEFInd» > c'est que le boot_loader .efi de démarrage du Système Windows est repéré au scan des volumes par les deux boot_managers.

Qu'il ne soit pas exécutable par l'EFI comme démarreur de Windows si tu choisis ce volume comme disque de démarrage lorsque tes 2 disques (SSD et HDD) coexistent ; alors que le volume BOOTCAMP démarre, par contre, si le HDD est seul en place, le SSD ayant été ôté (si j'ai bien suivi tes péripéties) > voilà qui pose un problème théorique assez pointu.

Mon inexpertise radicale dans le Système Windows me handicape fort ici > alors je ne me hasarde qu'en mode conjecturel aléatoire.

2 tables de partitions coexistent sur le disque-Système d'un Mac : la GPT (GUID Partition Table) principale sur les blocs 1-32 d'en-tête du disque ; et une MBR (Master Boot Record) secondaire sur le bloc initial 0. Cette section de blocs : 0 > 32 constitue le secteur de boot ou carte d'amorçage du disque pour l'EFI.

- Lorsqu'aucun Système Windows n'est installé sur le disque du Mac > la MBR du bloc 0 est du type : PMBR (Protective_MBR) > elle ne représente en mode MBR l'espace du disque que comme constitué d'une "mono-partition" in-partitionnable > mappage "d'un seul tenant" qui "protège" la table GPT principale contre des initiatives indues de la part d'installateurs de logiciels Windows.

- Lorsqu'un Système Windows s'installe sur le disque du Mac > la MBR du bloc 0 est convertie au statut : HMBR (Hybrid_MBR) > elle représente en mode MBR l'espace du disque comme constitué d'au plus 3 partitions qui sont les échos exacts de partitions pré-définies dans la GPT principale > ce qui permet à un installateur de Windows de "voir" la partition-cible où installer cet OS. Mais, je le conjecture aussi, lorsqu'on choisit de démarrer la partition BOOTCAMP, la table HMBR doit servir à l'EFI dans cette occurrence de carte d'amorçage pour son exécution du boot_loader de Windows (en lieu et place de la GPT qui lui sert de carte d'amorçage en cas de démarrage d'un boot.efi d'OS X) > je conjecture donc ici une capacité de bascule entre les cartes d'amorçage utilisées par l'EFI au démarrage.​

=> j'admets le caractère aventureux de ces conjectures > qui me permettent de me figurer ainsi le nœud du problème lorsque tu as en place tes 2 disques internes : SSD et HDD =>

- sur ton SSD, la MBR du bloc 0 est forcément un PMBR (Protective_MBR monopartitionnée), car aucun Système Windows n'est installé sur ce disque > c'est uniquement sur le bloc 0 du HDD que réside la HMBR (Hybrid_MBR) tri-partitionnée qui peut servir de carte d'amorçage du boot du volume BOOTCAMP par l'EFI.

- en cas de coexistence interne de tes 2 disques (SSD et HDD) > je suppose que la présence de la PMBR sur le bloc 0 du SSD invalide la capacité de bascule sur la HMBR du bloc 0 du HDD pour l'EFI = verrouillage de la carte d'amorçage du HDD sur la GPT principale > ce qui ferait que l'EFI n'aurait pas accès sur ce disque à la bonne carte d'amorçage (HMBR) quand tu tentes de démarrer sur BOOTCAMP.​

=> cette "occultation" de la carte d'amorçage HMBR du HDD par la prééminence de la PMBR du SSD constitue, je l'admets, une création de mon imagination logique > ce afin de tenter de "concevoir" la raison de ton échec à booter Windows du volume BOOTCAMP. Si cette conjecture assez "fantastique" correspond néanmoins un tantinet à l'état des choses logiques > alors tu ne pourras jamais booter le Windows de ton HDD sans modifier la configuration logique de tes 2 disques.

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

La solution que j'aperçois à ton problème est celle qui est utilisée dans les iMac qui comportent 2 disques internes (un SSD et un HDD) exactement comme ton MacBook Pro. Les 2 partitions majeures des 2 disques sont associées logiquement dans un dispositif CoreStorage dit : Fusion Drive, lequel est capable d'exporter un Volume Logique unique apparaissant d'un seul tenant pour l'utilisateur.

Dans une telle configuration, une partition BOOTCAMP est parfaitement installable toujours exclusivement sur le HDD, exactement à la place qu'elle occupe actuellement chez toi (disk1s4) et, dans cette configuration d'association logique des disques pour exporter un volume unique Macintosh HD > le Système Windows du volume BOOTCAMP est parfaitement démarrable par l'EFI de la Carte-Mère (qui, dans ce dispositif, doit pouvoir basculer au boot sur la carte d'amorçage HMBR du bloc 0 du HDD).

L'inconvénient pour mettre en place un Fusion Drive associatif des 2 partitions majeures disk0s2 & disk1s2 > c'est qu'il faut entièrement les reformater au préalable > ce qui fait qu'aucun OS pré-installé sur l'une ou l'autre ne peut être conservé. Pour mettre en place un Fusion Drive > il conviendrait donc que tu clones au préalable le contenu de ton volume Macintosh HD sur un DDE > ce qui te donnerait un Système démarrable en externe préservant toutes tes données > sur lequel tu pourrais démarrer pour reformater tes partitions > générer ton Fusion Drive > et alors re-cloner à rebours ton clone dans le Volume Logique du Fusion Drive sur lequel tu pourrais re-démarrer.

Dans cette nouvelle configuration > le volume Macintosh HD d'un seul tenant d'OS X aurait une taille de 239,8 Go (SSD - pas de Recovery HD sur ce disque) + 250,2 Go (HDD - Recovery HD sur ce disque) = 490 Go > ce qui te donnerait un espace quasiment doublé, sans aucune perte de réactivité grâce au SSD sur lequel serait installé d'entrée le Système et les applications.

Dans cette configuration, ta partition BOOTCAMP serait a priori démarrable - sinon celle déjà en place (à voir...) > du moins une dans laquelle tu ré-installerais Windows...

=> qu'est-ce que tu penses de ce scénario global ? Il peut te paraître complexe à mettre en œuvre > mais reconnais que tu as des exigences complexes au départ (booter OS X vs Windows) > sur la base d'une configuration matérielle complexe (2 disques internes : SSD & HDD). En résumé : tu as transformé ton MacBook Pro en une espèce d'iMac portable > autant pousser l'assimilation jusqu'au bout et adapter à ton iMacBook Pro la solution logique qui fonctionne avec les iMac...

[Je ne vois pas trop le lien du problème du son avec tout ça > mais il se réglerait du même coup - j'imagine...]

--------------------​
 
Salut nerdyiman

Si le volume BOOTCAMP est affiché à l'écran du gestionnaire de boot de l'EFI comme à celui de «rEFInd» > c'est que le boot_loader .efi de démarrage du Système Windows est repéré au scan des volumes par les deux boot_managers.

Qu'il ne soit pas exécutable par l'EFI comme démarreur de Windows si tu choisis ce volume comme disque de démarrage lorsque tes 2 disques (SSD et HDD) coexistent ; alors que le volume BOOTCAMP démarre, par contre, si le HDD est seul en place, le SSD ayant été ôté (si j'ai bien suivi tes péripéties) > voilà qui pose un problème théorique assez pointu.

Mon inexpertise radicale dans le Système Windows me handicape fort ici > alors je ne me hasarde qu'en mode conjecturel aléatoire.

2 tables de partitions coexistent sur le disque-Système d'un Mac : la GPT (GUID Partition Table) principale sur les blocs 1-32 d'en-tête du disque ; et une MBR (Master Boot Record) secondaire sur le bloc initial 0. Cette section de blocs : 0 > 32 constitue le secteur de boot ou carte d'amorçage du disque pour l'EFI.

- Lorsqu'aucun Système Windows n'est installé sur le disque du Mac > la MBR du bloc 0 est du type : PMBR (Protective_MBR) > elle ne représente en mode MBR l'espace du disque que comme constitué d'une "mono-partition" in-partitionnable > mappage "d'un seul tenant" qui "protège" la table GPT principale contre des initiatives indues de la part d'installateurs de logiciels Windows.

- Lorsqu'un Système Windows s'installe sur le disque du Mac > la MBR du bloc 0 est convertie au statut : HMBR (Hybrid_MBR) > elle représente en mode MBR l'espace du disque comme constitué d'au plus 3 partitions qui sont les échos exacts de partitions pré-définies dans la GPT principale > ce qui permet à un installateur de Windows de "voir" la partition-cible où installer cet OS. Mais, je le conjecture aussi, lorsqu'on choisit de démarrer la partition BOOTCAMP, la table HMBR doit servir à l'EFI dans cette occurrence de carte d'amorçage pour son exécution du boot_loader de Windows (en lieu et place de la GPT qui lui sert de carte d'amorçage en cas de démarrage d'un boot.efi d'OS X) > je conjecture donc ici une capacité de bascule entre les cartes d'amorçage utilisées par l'EFI au démarrage.​

=> j'admets le caractère aventureux de ces conjectures > qui me permettent de me figurer ainsi le nœud du problème lorsque tu as en place tes 2 disques internes : SSD et HDD =>

- sur ton SSD, la MBR du bloc 0 est forcément un PMBR (Protective_MBR monopartitionnée), car aucun Système Windows n'est installé sur ce disque > c'est uniquement sur le bloc 0 du HDD que réside la HMBR (Hybrid_MBR) tri-partitionnée qui peut servir de carte d'amorçage du boot du volume BOOTCAMP par l'EFI.

- en cas de coexistence interne de tes 2 disques (SSD et HDD) > je suppose que la présence de la PMBR sur le bloc 0 du SSD invalide la capacité de bascule sur la HMBR du bloc 0 du HDD pour l'EFI = verrouillage de la carte d'amorçage du HDD sur la GPT principale > ce qui ferait que l'EFI n'aurait pas accès sur ce disque à la bonne carte d'amorçage (HMBR) quand tu tentes de démarrer sur BOOTCAMP.​

=> cette "occultation" de la carte d'amorçage HMBR du HDD par la prééminence de la PMBR du SSD constitue, je l'admets, une création de mon imagination logique > ce afin de tenter de "concevoir" la raison de ton échec à booter Windows du volume BOOTCAMP. Si cette conjecture assez "fantastique" correspond néanmoins un tantinet à l'état des choses logiques > alors tu ne pourras jamais booter le Windows de ton HDD sans modifier la configuration logique de tes 2 disques.

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

La solution que j'aperçois à ton problème est celle qui est utilisée dans les iMac qui comportent 2 disques internes (un SSD et un HDD) exactement comme ton MacBook Pro. Les 2 partitions majeures des 2 disques sont associées logiquement dans un dispositif CoreStorage dit : Fusion Drive, lequel est capable d'exporter un Volume Logique unique apparaissant d'un seul tenant pour l'utilisateur.

Dans une telle configuration, une partition BOOTCAMP est parfaitement installable toujours exclusivement sur le HDD, exactement à la place qu'elle occupe actuellement chez toi (disk1s4) et, dans cette configuration d'association logique des disques pour exporter un volume unique Macintosh HD > le Système Windows du volume BOOTCAMP est parfaitement démarrable par l'EFI de la Carte-Mère (qui, dans ce dispositif, doit pouvoir basculer au boot sur la carte d'amorçage HMBR du bloc 0 du HDD).

L'inconvénient pour mettre en place un Fusion Drive associatif des 2 partitions majeures disk0s2 & disk1s2 > c'est qu'il faut entièrement les reformater au préalable > ce qui fait qu'aucun OS pré-installé sur l'une ou l'autre ne peut être conservé. Pour mettre en place un Fusion Drive > il conviendrait donc que tu clones au préalable le contenu de ton volume Macintosh HD sur un DDE > ce qui te donnerait un Système démarrable en externe préservant toutes tes données > sur lequel tu pourrais démarrer pour reformater tes partitions > générer ton Fusion Drive > et alors re-cloner à rebours ton clone dans le Volume Logique du Fusion Drive sur lequel tu pourrais re-démarrer.

Dans cette nouvelle configuration > le volume Macintosh HD d'un seul tenant d'OS X aurait une taille de 239,8 Go (SSD - pas de Recovery HD sur ce disque) + 250,2 Go (HDD - Recovery HD sur ce disque) = 490 Go > ce qui te donnerait un espace quasiment doublé, sans aucune perte de réactivité grâce au SSD sur lequel serait installé d'entrée le Système et les applications.

Dans cette configuration, ta partition BOOTCAMP serait a priori démarrable - sinon celle déjà en place (à voir...) > du moins une dans laquelle tu ré-installerais Windows...

=> qu'est-ce que tu penses de ce scénario global ? Il peut te paraître complexe à mettre en œuvre > mais reconnais que tu as des exigences complexes au départ (booter OS X vs Windows) > sur la base d'une configuration matérielle complexe (2 disques internes : SSD & HDD). En résumé : tu as transformé ton MacBook Pro en une espèce d'iMac portable > autant pousser l'assimilation jusqu'au bout et adapter à ton iMacBook Pro la solution logique qui fonctionne avec les iMac...

[Je ne vois pas trop le lien du problème du son avec tout ça > mais il se réglerait du même coup - j'imagine...]

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

Je suis juste épaté par tes compétence et ta capacité a pouvoir résoudre et comprendre ce genre de problème si complexe !
J'aimerai voir si possible avant d'engager n'importe quelle opération un tuto afin d'estimer l'ampleur de la démarche.
Ce que je n'arrive pas a comprendre c'est que beaucoup de gens passent par cette configuration mais n'ont pourtant pas tout ces problèmes.
Quant au son j'ai penser au rEFInd, le problème est apparemment survenu après l'installation de cet outil, je pourrais peut-être résoudre cela en le desinstallant.
 
Pour désactiver «rEFInd» > depuis ta session dans le volume Macintosh HD (SSD) > va comme tu l'avais déjà fait auparavant à : Menu  > Préférences Système > Disque de démarrage => sélectionne le volume Macintosh HD affiché > presse la bouton "Re-démarrer".

Cette manipulation graphique a inscrit en NVRAM, à la rubrique efi-boot-device, une adresse de démarrage automatique sur la partition disk0s2 de ton SSD. Ce faisant, l'ancienne adresse qui pointait au boot_loader refind_x64.efi sur la partition ESP disk0s1 du SSD a été effacée. En conséquence : les binaires de «rEFInd» sont complètement inactifs au démarrage de ton Mac (fichiers dormants).

=> vérifie si cette désactivation a une incidence ou pas sur ton problème de son.

[NB. Si tu tiens absolument non seulement à une désactivation de «rEFInd» au démarrage > mais aussi à une désinstallation (effacement) de ses binaires > tu n'auras qu'à re-demander > je te dirais comment faire. Je persiste à ne pas voir de lien logique entre «rEFInd» et un problème de son...].

--------------------
Pour ce qui est de la manœuvre Fusion Drive : l'essentiel pour toi est de disposer d'un DDE USB capable de recueillir dans son volume les données (Système + perso) de ton volume Macintosh HD. Ce volume ne fait que 239 Go de capacité, ce qui n'est pas énorme. Pour savoir combien tu as de données dedans > passe dans le «Terminal» la commande :
Bloc de code:
df -H
qui va scanner les volumes montés et afficher en retour leur taille avec la quantité d'espace occupé vs espace libre. Tu n'as qu'à poster ce tableau ici.

Si la quantité de données restait modérée (dans les 150 Go) > il se pourrait que tu aies déjà un DDE avec un volume recelant des données, mais possédant un espace libre suffisant (disons 200 Go) > alors un repartitionnement non destructeur du volume initial non plus que de ses données > libérerait un 2è volume vide d'une capacité suffisante pour recueillir le clone de ton volume Macintosh HD.

Si j'insiste sur ce point > c'est que c'est le seul ustensile matériel dont tu aies besoin. Une fois en possession d'un tel DDE, dont le disque doit avoir une table de partition GPT (GUID) et le volume une format JHFS+ (Mac OS étendu journalisé) pour qu'il soit amorçable en mode "boot" par ton Mac > réaliser le clone (= image-miroir démarrable d'un Système avec ses données) sera l'enfance de l'art grâce au logiciel «Carbon Copy Cloner» que tu peux utiliser 1 mois gratuitement en mode démo (sans limitations fonctionnelles).

Une fois ton clone fait (en gros c'est une opération de recopie avec quelques raffinements autour) > tu pourras démarrer sur lui en mode externe et tu te trouveras dans un double de ton environnement habituel du SSD. Il sera facile dans le «Terminal» du clone de manipuler logiquement les 2 disques internes de ton Mac pour réaliser le Fusion Drive. Ça prend 2 minutes à tout casser.

Ensuite, clonage à l'envers du clone (= "source") sur le volume logique vide exporté par le Fusion Drive (= "destination"). Tu n'auras plus qu'à re-démarrer enfin sur ce "clone du clone" toujours démarrable et équivalent à ton OS original.

=> ce descriptif que je viens de faire n'est pas exactement un tuto formel : c'est plutôt l'esquisse du sens général de la manœuvre. Rien de périlleux : si tu démarres sur ton clone, c'est que tu as là un Système bootable copie conforme de l'original, avec toutes tes données en double dedans. D'après ce clone > tu peux toujours opérer une recopie conforme et démarrable sur tout volume d'accueil offert par les disques internes de ton Mac. Donc rien à craindre a priori.

--------------------
Avant le sujet que tu as ouvert > je n'avais jamais rencontré de cas de figure de Mac avec 2 disques non solidarisés > sur le HDD secondaire duquel il aurait été question d'installer Windows. Non, mais le cas d'iMac avec 2 disques solidarisés par un Fusion Drive > avec donc un BOOTCAMP a priori démarrable sur le HDD grâce à cette configuration logique.

Je n'ai aucune expérience de Windows que je n'ai jamais utilisé comme OS. Je suis donc contraint de me pressurer les méninges d'un point de vue spéculatif > pour essayer de construire une représentation expliquant pourquoi BOOTCAMP boote si le HDD est solitaire et ne boote plus s'il est flanqué du SSD. Je suis absolument certain de l'existence d'une MBR sur le bloc 0 d'un disque Mac > je sais aussi que cette MBR est susceptible de revêtir les 2 formes : "Protective" et "Hybride" > mais l'idée d'une bascule entre cartes d'amorçage de la part de l'EFI selon la nature de l'OS à booter est une pure « idée spéculative » de ma part pour tenter d'expliquer la variation des phénomènes.

--------------------
Je me suis même demandé si l'existence d'un format CoreStorage sur la partition-Système disk1s2 du HDD ne pouvait pas poser un problème. Je te propose de passer la commande :
Bloc de code:
diskutil cs list
qui va te retourner le tableau du dispositif interne complexe de ce CoreStorage > peux-tu le poster ici ? Au cas où il serait noté "réversible" > opérer cette réversion (non destructive de l'OS) pour revenir à un système de fichiers jhfs+ simple > permettrait de vérifier s'il y a une incidence sur la capacité de démarrer de ton BOOTCAMP...
 
Dernière édition par un modérateur: