Bonjour, sur mon mac au démarrage j'appuie bien sur la touche option, mais je ne vois que mon disque dur interne, impossible de trouver les disques dur externe... Merci beaucoup d'avoir pris le temps de lire ma question et/ou d'y répondre ^^ Bonne journée
Probleme detection de disque dur externe
- Créateur du sujet Yhugs
- Date de début
M
Membre supprimé 1060554
Invité
Je m'avise que jcfaggia 
vient de répondre à la question avec une concision qui décidément me fait défaut. Je poste nonobstant cette prose qui tire « en longitude »...
Salut Yhugs.
Un disque est un support physique porteur de partitions, qui sont des sectorisations logiques de son espace. Chaque partition contient un système de fichiers, dans lequel sont stockées des données, et qui monte en volume au démarrage. Il existe 2 grands types de volumes (systèmes de fichiers montés d'une partition) : « démarrable » vs « de stockage ». Un volume « démarrable » contient un Système (comme OS X) ; un volume « de stockage » contient des données mais pas de Système.
Lorsqu'on démarre le Mac avec la touche "alt" pressée, un programme auxiliaire de l'EFI (le Programme Interne du Mac ou Firmware recelé dans une puce de la Carte-Mère) se trouve déclenché : le DiskManager, qui est un "gestionnaire de disque" natif => ce programme scanne tous les volumes montés des disques attachés au Mac (en interne et en externe) au démarrage, avec un seul critère discriminant : la présence ou l'absence d'un fichier boot_loader, qui est le fichier "démarreur" (logiciellement parlant) d'un OS que l'EFI peut exécuter. En gros : un boot_loader est une « application primaire de l'EFI » capable de booter un Système démarrable présent dans un volume monté (pour OS X : le boot_loader est le fichier boot.efi qui charge le kernel (micro-noyau) et lui injecte les kexts ou pilotes du hardware).
Les volumes reconnus contenir un fichier boot_loader au scan (un boot.efi pour OS X) sont identifiés par le DiskManager comme relevant de la catégorie des : « démarrables » et donc affichés à l'écran de choix du disque de démarrage / les volumes reconnus ne pas contenir un fichier boot_loader au scan (un boot.efi pour OS X) sont identifiés par le DiskManager comme relevant de la catégorie des : « supports de stockage » et donc non-affichés à l'écran de choix du disque de démarrage.
☞ Tout volume d'un DDE, d'une clé USB ou d'une Carte mémoire (externes) comme tout volume d'une partition du HDD ou SSD du Mac (interne) qui, au scan du DiskManager, ne révèle pas la présence d'un boot_loader est donc identifié comme un « support de stockage » simple, sans Système démarrable, et par conséquent non-affiché à l'écran de choix du disque de démarrage.
Cette question mérite d'être posée, parce qu'en ce qui concerne le fichier boot_loader d'OS X, il se trouve enfoui dans les profondeurs de l'arborescence logique de l'OS at: /Volumes/"Macintosh HD"/System/Library/CoreServices/boot.efi => le "gestionnaire de disque" DiskManager va-t-il pousser le scan des volumes montés jusqu'à descendre de haut en bas l'arborescence des systèmes de fichiers concernés afin de vérifier « exhaustivement » si oui ou non existe quelque part un boot_loader ?
Ce type de procédure de vérification aurait très bien pu être implémentée dans la programmation du DiskManager par les ingénieurs de la , mais ils s'en sont bien gardés, à cause d'une objection majeure : le Temps requis par une telle procédure, qui se trouverait multiplié par autant de volumes que montés. Lorsque, par exemple, je lance un logiciel de scan de la taille des fichiers/dossiers d'un volume comme «Disk Inventory X», il faut largement plus d'une minute au programme pour inventorier toute l'arborescence du système de fichiers concerné d'un seul volume. J'ai 6 volumes démarrables de 6 versions d'OS X différentes sur des partitions de mon SSD interne de 1 To + 5 volumes de «Recovery HD» corrélatives démarrables, soit 11 volumes démarrables. Et je peux avoir attaché à mon Mac en externe 4 DDE recelant ensemble 10 volumes démarrables. Ce qui m'amène à 21 volumes démarrables : si je démarre avec "alt" dans de telles conditions, vais-je avoir à attendre plus d'un quart d'heure que le DiskManager ait scanné exhaustivement de haut en bas l'arborescence de chaque volume monté (et, en plus de mes 21 volumes démarrables, j'aurais une poignées additionnelle de volume « de stockage » simple dans le lot) ?
Ce serait irréaliste en pratique. Par suite, le DiskManager ne scanne que les headers ("en tête") des systèmes de fichiers, et additionnellement le seul espace-racine consécutif des volumes, sans aucunement suivre l'arborescence logique en-dessous. Comment alors un Système intrinsèquement démarrable comme OS X, dont le boot_loader : boot.efi réside au 3è degré inférieur par rapport à la racine du volume, va-t-il pourvoir être détecté au scan du DiskManager comme « démarrable » et pas relégué au rang de « support de stockage » ? Tu vois le problème ?
Il est résolu depuis les origine d'OS X par la technique du blessing ("bénédiction") : il s'agit de l'inscription (par une commande), sur le header d'un système de fichiers « démarrable », de l'adresse au dossier recelant le boot_loader => ainsi, au scan d'un tel volume, le DiskManager suit directement ce chemin depuis le header et vérifie la présence d'un boot_loader, ce qui prend un temps infime. À la fin de l'installation de toute version d'OS X, l'installateur procède au blessing du volume concerné, càd. à l'inscription de l'adresse au boot_loader : boot.efi sur le header du système de fichiers. Idem pour la «Recovery HD» corollaire. Idem pour les logiciels de clonage, qui terminent toute opération de clonage sur un DDE par un blessing du volume.
Quid si (par exception) j'ai l'image d'un système démarrable (= clone) sur le volume d'un DDE sans que le blessing ait opéré (parce qu'au lieu de passer par le logiciel de clonage «Carbon Copy CLoner» - par exemple - qui opère toujours un (re)blessing in fine, j'ai utilisé dans le «Terminal» un programme de recopie UNIX, comme cp, ditto, rsync ou asr avec l'option archive sans opérer de blessing du volume en sortie) ? Eh bien ! le Volume ne pourra pas être démarré, car il ne sera pas repéré comme « démarrable » par le DiskManager lors du scan initié par "alt" et, par suite, non affiché à l'écran de choix des disques de démarrage (alors qu'il recèle un Système intrinsèquement démarrable) => il faut alors, pour corriger cette lacune, procéder à une commande manuelle de blessing spécifique de ce volume dans le «Terminal» (par l'invocation ad-hoc du programme bless) de type :
et le chemin au boot_loader : boot.efi recelé dans le répertoire des CoreServices sera inscrit sur le header du système de fichiers et pourra être suivi par le DiskManager au scan initié par "alt".
Quid si (par plaisanterie) j'ai une copie du boot_loader : boot.efi dans un simple volume « de stockage », que je me suis amusé à bénir en manuel dans le «Terminal» ? Ce volume sera infailliblement assimilé à un volume « démarrable » par le DiskManager, alors même que c'est un faux volume démarrable, car il n'y a pas de Système derrière le boot.efi => le DiskManager a été leurré par le petit plaisantin macomaniac...
vient de répondre à la question avec une concision qui décidément me fait défaut. Je poste nonobstant cette prose qui tire « en longitude »...
Salut Yhugs.
Réponse au 1er degré
Un disque est un support physique porteur de partitions, qui sont des sectorisations logiques de son espace. Chaque partition contient un système de fichiers, dans lequel sont stockées des données, et qui monte en volume au démarrage. Il existe 2 grands types de volumes (systèmes de fichiers montés d'une partition) : « démarrable » vs « de stockage ». Un volume « démarrable » contient un Système (comme OS X) ; un volume « de stockage » contient des données mais pas de Système.
Lorsqu'on démarre le Mac avec la touche "alt" pressée, un programme auxiliaire de l'EFI (le Programme Interne du Mac ou Firmware recelé dans une puce de la Carte-Mère) se trouve déclenché : le DiskManager, qui est un "gestionnaire de disque" natif => ce programme scanne tous les volumes montés des disques attachés au Mac (en interne et en externe) au démarrage, avec un seul critère discriminant : la présence ou l'absence d'un fichier boot_loader, qui est le fichier "démarreur" (logiciellement parlant) d'un OS que l'EFI peut exécuter. En gros : un boot_loader est une « application primaire de l'EFI » capable de booter un Système démarrable présent dans un volume monté (pour OS X : le boot_loader est le fichier boot.efi qui charge le kernel (micro-noyau) et lui injecte les kexts ou pilotes du hardware).
Les volumes reconnus contenir un fichier boot_loader au scan (un boot.efi pour OS X) sont identifiés par le DiskManager comme relevant de la catégorie des : « démarrables » et donc affichés à l'écran de choix du disque de démarrage / les volumes reconnus ne pas contenir un fichier boot_loader au scan (un boot.efi pour OS X) sont identifiés par le DiskManager comme relevant de la catégorie des : « supports de stockage » et donc non-affichés à l'écran de choix du disque de démarrage.
☞ Tout volume d'un DDE, d'une clé USB ou d'une Carte mémoire (externes) comme tout volume d'une partition du HDD ou SSD du Mac (interne) qui, au scan du DiskManager, ne révèle pas la présence d'un boot_loader est donc identifié comme un « support de stockage » simple, sans Système démarrable, et par conséquent non-affiché à l'écran de choix du disque de démarrage.
♤
Réponse au 2è degré
Comment s'y prend le "gestionnaire de disque" de l'EFI : le DiskManager pour repérer, par scannage des volumes montés au démarrage, la présence ou l'absence d'un boot_loader (boot.efi pour OS X) ?Réponse au 2è degré
Cette question mérite d'être posée, parce qu'en ce qui concerne le fichier boot_loader d'OS X, il se trouve enfoui dans les profondeurs de l'arborescence logique de l'OS at: /Volumes/"Macintosh HD"/System/Library/CoreServices/boot.efi => le "gestionnaire de disque" DiskManager va-t-il pousser le scan des volumes montés jusqu'à descendre de haut en bas l'arborescence des systèmes de fichiers concernés afin de vérifier « exhaustivement » si oui ou non existe quelque part un boot_loader ?
Ce type de procédure de vérification aurait très bien pu être implémentée dans la programmation du DiskManager par les ingénieurs de la , mais ils s'en sont bien gardés, à cause d'une objection majeure : le Temps requis par une telle procédure, qui se trouverait multiplié par autant de volumes que montés. Lorsque, par exemple, je lance un logiciel de scan de la taille des fichiers/dossiers d'un volume comme «Disk Inventory X», il faut largement plus d'une minute au programme pour inventorier toute l'arborescence du système de fichiers concerné d'un seul volume. J'ai 6 volumes démarrables de 6 versions d'OS X différentes sur des partitions de mon SSD interne de 1 To + 5 volumes de «Recovery HD» corrélatives démarrables, soit 11 volumes démarrables. Et je peux avoir attaché à mon Mac en externe 4 DDE recelant ensemble 10 volumes démarrables. Ce qui m'amène à 21 volumes démarrables : si je démarre avec "alt" dans de telles conditions, vais-je avoir à attendre plus d'un quart d'heure que le DiskManager ait scanné exhaustivement de haut en bas l'arborescence de chaque volume monté (et, en plus de mes 21 volumes démarrables, j'aurais une poignées additionnelle de volume « de stockage » simple dans le lot) ?
Ce serait irréaliste en pratique. Par suite, le DiskManager ne scanne que les headers ("en tête") des systèmes de fichiers, et additionnellement le seul espace-racine consécutif des volumes, sans aucunement suivre l'arborescence logique en-dessous. Comment alors un Système intrinsèquement démarrable comme OS X, dont le boot_loader : boot.efi réside au 3è degré inférieur par rapport à la racine du volume, va-t-il pourvoir être détecté au scan du DiskManager comme « démarrable » et pas relégué au rang de « support de stockage » ? Tu vois le problème ?
Il est résolu depuis les origine d'OS X par la technique du blessing ("bénédiction") : il s'agit de l'inscription (par une commande), sur le header d'un système de fichiers « démarrable », de l'adresse au dossier recelant le boot_loader => ainsi, au scan d'un tel volume, le DiskManager suit directement ce chemin depuis le header et vérifie la présence d'un boot_loader, ce qui prend un temps infime. À la fin de l'installation de toute version d'OS X, l'installateur procède au blessing du volume concerné, càd. à l'inscription de l'adresse au boot_loader : boot.efi sur le header du système de fichiers. Idem pour la «Recovery HD» corollaire. Idem pour les logiciels de clonage, qui terminent toute opération de clonage sur un DDE par un blessing du volume.
Quid si (par exception) j'ai l'image d'un système démarrable (= clone) sur le volume d'un DDE sans que le blessing ait opéré (parce qu'au lieu de passer par le logiciel de clonage «Carbon Copy CLoner» - par exemple - qui opère toujours un (re)blessing in fine, j'ai utilisé dans le «Terminal» un programme de recopie UNIX, comme cp, ditto, rsync ou asr avec l'option archive sans opérer de blessing du volume en sortie) ? Eh bien ! le Volume ne pourra pas être démarré, car il ne sera pas repéré comme « démarrable » par le DiskManager lors du scan initié par "alt" et, par suite, non affiché à l'écran de choix des disques de démarrage (alors qu'il recèle un Système intrinsèquement démarrable) => il faut alors, pour corriger cette lacune, procéder à une commande manuelle de blessing spécifique de ce volume dans le «Terminal» (par l'invocation ad-hoc du programme bless) de type :
Bloc de code:
sudo bless --folder /Volumes/"Macintosh HD"/System/Library/CoreServicesQuid si (par plaisanterie) j'ai une copie du boot_loader : boot.efi dans un simple volume « de stockage », que je me suis amusé à bénir en manuel dans le «Terminal» ? Ce volume sera infailliblement assimilé à un volume « démarrable » par le DiskManager, alors même que c'est un faux volume démarrable, car il n'y a pas de Système derrière le boot.efi => le DiskManager a été leurré par le petit plaisantin macomaniac...
♧
Dernière édition par un modérateur:
D'accord merci a vous deux pour vos réponses (macomaniac j'ai mis du temps a lire ton texte ^^) ma clé contient une installation de windows et il faut que je boot dessus pour l'installer sur la parti bootcamp, je ne sais pas vraiment comment faire, faut il que je partitionne mon disque et la clé s'affiche ou c'est plus complexe que cela ?
M
Membre supprimé 1060554
Invité
Essaye avec le gestionnaire de boot : «rEFInd». Tu télécharges le dossier de ressources : ☞refind.bin-0.10.0.zip☜ (clique sur le lien) et tu sauvegardes le dossier décompressé refind.bin-0.10.0 quelque part où tu sauras le retrouver en cas de besoin (à la racine de ton dossier de compte d'utilisateur, ou dans tes documents ... à ta guise).
Voici maintenant comment installer le gestionnaire => tu vas à : Applications/Utilitaires et tu lances le «Terminal». Dans la fenêtre qui s'ouvre, tu tapes :
tout court et tu sautes un espace. Puis, en dehors de cette fenêtre, tu vas via le Finder à ton dossier refind.bin-0.10.0 où qu'il soit et tu l'ouvres => tu avises le fichier : refind-install (icône rectangulaire anthracite avec un exec dans l'angle supérieur gauche) --> au pointeur, tu en fais carrément un glisser-déposer dans la fenêtre du «Terminal», ce qui renseigne automatiquement le chemin au fichier et son nom. Tu obtiens donc une commande analogue à :
--> 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 ↩︎ --> le fichier d'install refind-install se trouve exécuté en droits root (je te passe le détail de l'installation - si tu en étais curieux, tu peux aller lire de mes proses dans ce fil assez récent : ☞Refit ne semble pas fonctionner☜).
NB. si tu es sous «El Capitan» et si tu voyais s'afficher un message d'échec de l'installation de «rEFInd» dans le «Terminal», ce serait dû au SIP (System Integrity Protection) qui inscrit dans la mémoire NVRAM un argument de boot susceptible de verrouiller l'adresse de démarrage pré-inscrite pour l'EFI. Dans ce cas, tu re-démarres par ⌘R sur la partition de récupération «Recovery HD», tu vas à la barre de menus supérieure de l'écran, menu Utilitaires et tu lances le «Terminal» (encore un !). Dans la fenêtre tu saisis la commande :
et ↩︎ --> au re-démarrage sur l'OS, le SIP est désactivé et l'adresse de boot en NVRAM éditable --> repasse dans le «Terminal» la commande d'installation de «rEFInd» comme décrit précédemment. Pour réactiver le SIP => commande :
dans le «Terminal» de la «Recovery HD» exclusivement.
☞ une fois «rEFInd» installé, re-démarre sans option : tu vas obtenir automatiquement l'écran de choix du disque de démarrage spécifique du gestionnaire de boot «rEFInd» : est-ce que le volume démarrable de ta clé d'install de «Windows» ne serait pas affiché par hasard ? Il est possible qu'il le soit sous 2 icônes distinctes : une du type Win-quelque chose, une autre du type EFI Boot => essaye avec chaque...
[NB. Choisir, à : Menu /Préférences Système/Disque de démarrage le volume de l'OS (par exemple) comme disque de démarrage automatique => édite l'adresse de boot pour l'EFI en NVRAM (mémoire statique de la Carte Mère visitée par l'EFI au démarrage) en effaçant l'ancienne adresse dirigeant l'EFI vers l'exécution du boot_loader propre à «rEFInd» => «rEFInd» se trouve par là désactivé. Pour le réactiver : repasser dans le «Terminal» la commande d'installation sudo ... refind-install (c'est pourquoi il faut pouvoir retrouver facilement le dossier des ressources d'install de «rEFInd» en cas de besoin).]
Voici maintenant comment installer le gestionnaire => tu vas à : Applications/Utilitaires et tu lances le «Terminal». Dans la fenêtre qui s'ouvre, tu tapes :
Bloc de code:
sudo
Bloc de code:
sudo /chemin_au_dossier/refind.bin-0.10.0/refind-install--------------------
NB. si tu es sous «El Capitan» et si tu voyais s'afficher un message d'échec de l'installation de «rEFInd» dans le «Terminal», ce serait dû au SIP (System Integrity Protection) qui inscrit dans la mémoire NVRAM un argument de boot susceptible de verrouiller l'adresse de démarrage pré-inscrite pour l'EFI. Dans ce cas, tu re-démarres par ⌘R sur la partition de récupération «Recovery HD», tu vas à la barre de menus supérieure de l'écran, menu Utilitaires et tu lances le «Terminal» (encore un !). Dans la fenêtre tu saisis la commande :
Bloc de code:
csrutil disable
Bloc de code:
csrutil enable--------------------
☞ une fois «rEFInd» installé, re-démarre sans option : tu vas obtenir automatiquement l'écran de choix du disque de démarrage spécifique du gestionnaire de boot «rEFInd» : est-ce que le volume démarrable de ta clé d'install de «Windows» ne serait pas affiché par hasard ? Il est possible qu'il le soit sous 2 icônes distinctes : une du type Win-quelque chose, une autre du type EFI Boot => essaye avec chaque...
[NB. Choisir, à : Menu /Préférences Système/Disque de démarrage le volume de l'OS (par exemple) comme disque de démarrage automatique => édite l'adresse de boot pour l'EFI en NVRAM (mémoire statique de la Carte Mère visitée par l'EFI au démarrage) en effaçant l'ancienne adresse dirigeant l'EFI vers l'exécution du boot_loader propre à «rEFInd» => «rEFInd» se trouve par là désactivé. Pour le réactiver : repasser dans le «Terminal» la commande d'installation sudo ... refind-install (c'est pourquoi il faut pouvoir retrouver facilement le dossier des ressources d'install de «rEFInd» en cas de besoin).]
Dernière édition par un modérateur:
Là, c'est une autre question. Au départ, il s'agissait de disque dur externe et maintenant c'est une clé usb, en plus avec Windows.
A ma connaissance, il faut faire l'installation de Windows a travers Bootcamp ou autre, avec un DVD ou autre support contenant un programme d'installation Windows valide avec sa clé. Une fois l'installation faite tu pourras démarrer sur Windows ou OS X.
D'autres que moi ont une pratique de ces manips, je les laisse préciser les détails.
Bon dimanche.
JCF
