# Refit ne semble pas fonctionner



## AppleSpirit (6 Novembre 2015)

Bonjour,

J'ai installé refit sur mon macbook air 2012 mais au démarrage du mac je ne vois nulle par le logiciel refit se mettre en marche et me demander quel os choisir. Que faire ? Pour l'instant je suis obligé de presser la touche alt au démarrage pour avoir le choix entre osx et windows seulement, mais là non plus je ne vois nulle part le mot refit apparaître et donc impossible de démarrer mon Lubuntu qui est également installé.

Est-ce que vous pouvez m'aider ?


----------



## Deleted member 1099514 (7 Novembre 2015)

Salut

Déjà maintenant c'est rEFInd qu'il faut installer
Tu as quelle version d'osx? Si c'est El Capitan, il faudrait peut être avant d'installer rEFInd, démarrer en mode Recovery et désactiver le SIP depuis le terminal (menu utilitaires/terminal) :
*csrutil disable*
Puis redémarrer et réinstaller rEFInd.

@+


----------



## AppleSpirit (7 Novembre 2015)

J'ai d'abord installé rEFInd et ça n'a pas fonctionné. J'ai ensuite installé REFIT par dessus et ça a marché en procédant de la manière ci-dessous : 



```
macbook-air-de-air:~ air$ cd /efi
macbook-air-de-air:efi air$ ls
rEFIt License.rtf    refit
rEFIt ReadMe.rtf    tools
macbook-air-de-air:efi air$ /efi/refit/enable-always.sh
+ sudo bless --folder /efi/refit --file /efi/refit/refit.efi --labelfile /efi/refit/refit.vollabel --setBoot
macbook-air-de-air:efi air$
  [Restauré 7 nov. 2015 01:22:03]
Last login: Sat Nov  7 01:21:58 on console
Restored session: Sam 7 nov 2015 01:06:03 CET
macbook-air-de-air:efi air$
```

Maintenant, est-ce que quelqu'un peut m'expliquer comment procéder pour désinstaller complètement rEFInd ?


----------



## macomaniac (7 Novembre 2015)

Salut *AppleSpirit*.



AppleSpirit a dit:


> J'ai d'abord installé rEFInd et ça n'a pas fonctionné



Qu'est-ce que tu appelles « installer » «rEFInd» ? Si tu t'es contenté de télécharger depuis ce lien : ☞*SourceForge : rEFInd*☜ un refind-bin-0.9.2.zip et de localiser le dossier dézippé refind-bin-0.9.2 quelque part dans ton OS (espace-racine ou dossier de compte) - ça ne suffit absolument pas. Tu dois exécuter dans le «Terminal» le fichier shell d'installation recelé dans ce dossier et intitulé : install.sh. La commande dans le «Terminal» est simplement :


```
sudo /chemin_au_dossier/refind-bin-0.9.2/install.sh
```
 (en fait, tu fait sudo, un espace et glisser-déposer du fichier install.sh).

--------------------​
L'intéressant est alors de bien comprendre ce qui va s'ensuivre, et qui consiste en la réelle « installation » de «rEFInd» (compréhension qui permet, _ipso facto_, de saisir comment « désintaller » réellement «rEFInd» à rebours.

a) L'exécutable install.sh commence par monter en volume la partition graphiquement invisible /dev/disk0s*1* du disque du Mac : cette partition, la n°1 par défaut de la Table de Partition GUID, est l'ESP : EFI System Partition, qui précède la partition de l'OS (/dev/disk0s*2*) et qui constitue le secteur d'initialisation du boot logique sur le disque pour le  Programme Interne du Mac : l'EFI (terme homonyme, mais qui n'est pas ici une partition mais un logiciel) = Extensible Firmware Interface : le micro-logiciel de démarrage recelé dans une puce de la Carte-Mère.

- b) Sur la partition EFI (ESP) /dev/disk0s*1* du disque, se trouvent par défaut des ressources Apple : exécutable BOOTLOG et arborescence  EFI/APPLE/CACHES, EXTENSIONS, FIRMWARE recelant des binaires Apple. Une fois l'ESP montée en volume, l'install.sh copie dans le dossier EFI, à côté du sous-dossier APPLE, 2 dossiers : refind & tools contenant les propres binaires de «rEFInd». Le binaire cardinal est, dans le dossier refind, le refind_x64.efi qui est un boot_loader exécutable par le Programme Interne du Mac.

- c) Enfin, l'exécutable install.sh adresse une commande à la NVRAM qui inscrit comme chemin de boot automatique pour l'EFI ceci :


```
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</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
```
 => ce qui est à noter est que mon xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx est en fait l'UUID de 32 caractères alpha-numériques de l'ESP (= la partition /dev/disk0s*1* du disque) et que le Path pointe bien dessus à l'adresse : \EFI\refind\refind_x64.efi, càd. au boot_loader : refind_x64.efi que j'ai cité.​--> voilà en quoi consiste l'« installation » de «rEFInd». Au démarrage suivant, le Programme Interne du Mac (EFI) exécute la vérification du _hardware_ conclue par le gong ("_Chime_"), puis visite la NVRAM (mémoire statique de la Carte-Mère) pour y lire les arguments de boot qui y sont inscrits => la mention : efi-boot-device suivie de l'adresse à un boot_loader force l'EFI à suivre automatiquement le chemin donné pour exécuter ce ficher booter. Dans le cas où l'adresse est celle au fichier refind_x64.efi sur l'ESP, alors l'EFI exécute ce boot_loader à la place du boot_loader par défaut qui existe, sur la partition /dev/disk0s*2* de l'OS, at: /System/Library/CoreServices/boot.efi. À l'exécution du boot_loader alternatif de «rEFInd», l'EFI quitte, et se lance l'« application rEFInd » avec ses ressources graphiques : affichage de l'écran de choix d'un disque de démarrage, avec ses sous-menus par la touche F2. En cas de choix de tel volume affiché de démarrage, c'est l'« application rEFInd» qui, en substitution du Programme Interne du Mac, va exécuter le boot_loader propre au Système résidant sur la partition en question.

--------------------​
Comment tu as accès à l'ESP pour vérification ? Par la commande dans le «Terminal» :


```
diskutil mount /dev/disk0s1
```
 qui monte le système de fichiers de la partition /dev/disk0s*1* en un volume EFI que tu peux ouvrir pour vérifier son contenu. Attention ! Du doigté ! Ne pas benner les ressources Apple ! Si tu veux complètement « désinstaller » «rEFInd», il suffit de benner les 2 dossiers spécifiques : refind & tools. Mais pourquoi le faire ? Ils ne sont réellement actifs en tant que ressources qu'aussi longtemps qu'un chemin en NVRAM préfacé par le label : efi-boot-device existe qui pointe, via l'UUID de l'ESP, à l'adresse : \EFI\refind\refind_x64.efi, càd. au boot_loader de «rEFInd».

Suppose que tu fasses un reset_NVRAM : l'adresse en question est effacée, et les binaires de «rEFInd», qui continuent d'exister sur l'ESP, deviennent aussi inertes pour le Mac qu'un poster contre le mur de ton Bureau. Suppose encore que, dans ta session, tu ailles à : _Menu /Préférences Système/Disque de démarrage_ et que tu choisisses le volume Macintosh HD de ton OS comme disque de démarrage => _illico_ l'adresse de boot en NVRAM qui pointait au boot_loader refind_x64.efi est effacée, et c'est celle qui pointe at: /System/Library/CoreServices/boot.efi sur la partition /dev/disk0s*2* de l'OS qui se trouve inscrite comme efi-boot-device. Idem, si tu passes une commande sudo bless --folder avec l'option --setBoot sur un dossier alternatif recelant un boot_loader .efi => l'adresse en NVRAM pour l'efi-boot-device ne pointe plus au boot_loader : refind\refind_x64.efi, sur l'ESP. Pour « réactiver » «reFInd», il  faut ré-exécuter l'install.sh dans le «Terminal» afin de réécrire en NVRAM l'adresse au boot_loader refind_x64.efi sur l'ESP.

Comment je sais quelle est l'adresse de boot en NVRAM ? Via la commande :


```
nvram -p
```
 dans la «Terminal» => scruter ce qui suit le label : efi-boot-device (tâche un tantinet ingrate, je l'admets 
	

	
	
		
		

		
			





).

--------------------​
*NB.* Sous «El Capitan», il semble que le SIP (System Integrity Protection), qui inscrit en NVRAM 6 kernel_flags destinés à verrouiller le Système de l'OS, bloque la capacité de l'install.sh de «rEFInd» à modifier l'adresse de boot après le label : efi-boot-device. Je m'en suis aperçu en exécutant l'install.sh, puis en faisant un nvram -p pour vérifier l'adresse de boot qui pointait, inchangée, au boot_loader boot.efi de l'OS. Il faut désactiver le SIP au préalable pour que l'install.sh de «rEFInd» puisse écrire en NVRAM l'adresse alternative au boot_loader : refind_x64.efi sur l'ESP (car la neutralisation des kernel_flags libère la possibilité de changer l'adresse de boot de l'EFI).

Pour ce faire, démarrer avec *⌘R* sur la «Recovery HD», aller chercher un «Terminal» à la barre de menus supérieure de l'écran, menu : _Utilitaires_ et passer la commande :


```
csrutil disable
```
 avant de re-démarrer sur l'OS. Exécuter l'install.sh de «rEFInd» (avec sudo) à ce moment et vérifier ensuite par nvram -p que l'adresse qui suit le label efi-boot-device pointe bien sur le boot_loader : refind_x64.efi de l'ESP => le prochain (re)démarrage sans option conduira à l'affichage de l'écran gestionnaire de disque de «reFInd».

--> Si tu es sous «El Capitan» et si tu as exécuté l'install.sh sans déactivation du SIP au préalable,  telle serait la raision de l'inactivation de «rEFInd» ; sinon, ce serait parce que tu n'as pas exécuté l'install.sh dans le «Terminal».

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


----------



## AppleSpirit (7 Novembre 2015)

Je me suis bien positionné dans le dossier où est installé refind via le terminal et j'ai bien tapé sudo avant de transposer avec ma souris le shell install.sh vers le terminal. Par contre maintenant pour désinstaller ce refind j'ai l'impression qu'il va me falloir une semaine de recherches vu la complexité apparente de la chose. J'imagine qu'en déposant des choses dans la corbeille ou en tapant une commande dans le terminal il n'est pas possible de le désinstaller ? En effet, en ce moment j'ai un problème c'est que j'ai à la fois refit et refind qui sont installés et que quand je démarre ma machine, les deux utilitaires interviennent en même temps et me proposent au total près de 4 linux, un osx et un windows à choix...


----------



## macomaniac (7 Novembre 2015)

Depuis ta session dans l'OS, va à : _Menu /Préférences Système/Disque de démarrage_ et sélectionne le volume Macintosh HD de ton OS comme disque de démarrage (cette sélection efface les préférences de boot antérieures en NVRAM et instaure comme PATH automatique pour l'EFI le chemin au boot_loader : boot.efi de l'OS. Re-démarre alors ton Mac sans option, ce qui te permettra de vérifier par un boot automatique sur OS X que tes 2 gestionnaires de disques sont « désactivés » (tu n'as pas besoin de supprimer leurs dossiers : faute d'adresse en NVRAM au boot_loader .efi qu'ils contiennent, ils sont inertes).

Ensuite, il te suffit d'exécuter dans le «Terminal» le fichiers install.sh de «rEFInd» *ou* de reprendre ton installation de «rEFIt» (l'un *ou *l'autre, mais pas les 2). Ainsi, un seul des 2 gestionnaires de disque sera réactivé, l'autre n'ayant que des ressources inertes. Si tu choisis de réactiver «rEFInd» et que tu sois sous «El Capitan», veille à désactiver le SIP avant comme conseillé dans le dernier § de mon précédent message.

[PS. Pour exécuter un fichier shell avec sudo, tu n'as nullement besoin de te logger par cd dans le fichier parent au préalable. Tu tapes sudo, tu sautes un espace et tu fais un glisser-déposer direct du fichier shell dans la fenêtre du «Terminal», ce qui renseigne automatiquement le chemin absolu au fichier et son nom.]


----------



## AppleSpirit (7 Novembre 2015)

Je viens de faire l'opération décrite dans son entier. J'ai simplement réactivé refit après le reboot. Toutefois le problème n'est pas résolu car refind continue à être présent lors du boot.


----------



## macomaniac (7 Novembre 2015)

AppleSpirit a dit:


> le problème n'est pas résolu car refind continue à être présent lors du boot.



«rEFInd» n'est présent que si tu débouches sur l'écran "gestionnaire de disque" de «rEFInd», avec la mention «rEFInd» en en-tête. Si ce n'est pas le cas, «rEFInd» n'est pas présent. Comment le pourrait-il ? En sélectionnant le volume Macintosh HD comme disque de démarrage, tu as ramené au default l'adresse suivant le label efi-boot-device en NVRAM ; puis, en réactivant «rEFIt», tu as remplacé l'adresse default en NVRAM par celle qui pointe au boot_loader du seul «rEFIt» - ce, sans que l'adresse au boot_loader de «rEFInd» sur l'ESP n'ait jamais été ré-inscrite en NVRAM.

C'est un point de logique : l'EFI ne peut pas exécuter _simultanément_ ni _successivement_ *2* boot_loaders au démarrage, mais *1* seul. Il ne peut y avoir en NVRAM qu'une seule adresse de boot correspondant au label efi-boot-device. Si c'est celle qui pointe au boot_loader de «rEFIt», alors aucun PATH au boot_loader de «rEFInd» ne peut être inscrit en concomitance après le label efi-boot-device. Pour le confirmer, peux tu passer la commande informative :


```
nvram -p
```
 qui affiche le tableau des arguments de boot en NVRAM, te caler sur la ligne qui commence par la mention : efi-boot-device et faire un copier-coller ici de l'ensemble du chemin (étalé sur plusieurs lignes) qui se termine à : </string></dict></array>%00 ? Il devrait être facile de vérifier qu'aucun PATH pointant sur le boot_loader de «rEFInd» n'est mentionné, et par conséquent que «rEFInd» est inactif.

☞ tu vois à quoi mène cette argumentation ? Si tu as un affichage de tes disques redondant (c'est-à-dire chaque volume en double), ce doit être dû à un cafouillage de «rEFIt_» _uniquement (c'est un gestionnaire de disque qui n'est plus développé et qui n'est pas insusceptible de bourdes d'affichage)...


----------



## AppleSpirit (7 Novembre 2015)

```
Last login: Sat Nov  7 23:53:55 on console
macbook-air-de-air:~ air$ nvram -p
backlight-level    9%02
boot-gamma    %10%06%00%00%f2%9c%00%00%00%00%00%00n%00%00%00%00%00%00%00%07%00%04%04%db%05%0b%0b%b2%0e%1e%1e%95$66m>WWO`ww%09%80%a1%a1%87%a8%07%00%04%04%db%05%0b%0b%b2%0e%1e%1e%95$66m>WWO`ww%09%80%a1%a1%87%a8%07%00%04%04%db%05%0b%0b%b2%0e%1e%1e%95$66m>WWO`ww%09%80%a1%a1%87%a8
BootCampHD    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%7f%ff%04%00
bluetoothInternalControllerInfo    %1f%82%ac%05%00%13%18%1d%00%88e<%e09
prev-lang:kbd    fr:18
SystemAudioVolumeDB    %80
efi-apple-recovery    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>8F7A3BCF-DC9E-4261-B332-BD5DB66A982B</string></dict></dict><key>BLLastBSDName</key><string>disk0s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\APPLE\FIRMWARE\MBA51_00EF_B04_LOCKED.scap</string></dict></array>%00
bluetoothActiveControllerInfo    %1f%82%ac%05%00%00%00%13%18%1d%00%88e<%e09
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>F0A8554E-D6B9-4137-A2DB-D2ED1DF8FEB8</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
efi-boot-device-data    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%d05%c5%03%00%00%00%00NU%a8%f0%b9%d67A%a2%db%d2%ed%1d%f8%fe%b8%02%02%7f%ff%04%00
fmm-computer-name    MacBook Air de air
SystemAudioVolume    %80
LocationServicesEnabled    %01
macbook-air-de-air:~ air$
```


----------



## AppleSpirit (8 Novembre 2015)




----------



## macomaniac (8 Novembre 2015)

Prose dominicale (avec « culs de lampe »)
On va y arriver 
	

	
	
		
		

		
		
	


	


Ta 2è capture montre qu'au démarrage s'affiche seulement l'écran gestionnaire de disque de «rEFIt», non celui de «rEFInd». Si, à partir de là je regarde quel chemin de boot correspond au label efi-boot-device en NVRAM, voici ce est mentionné :


```
<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key>
<dict><key>UUID</key><string>F0A8554E-D6B9-4137-A2DB-D2ED1DF8FEB8</string>
</dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
```

[je me suis permis de casser la ligne continue d'adresse en 3 segments pour éviter le tapis roulant d'affichage horizontal] => l'UUID de la partition de boot : F0A8554E-D6B9-4137-A2DB-D2ED1DF8FEB8 est forcément l'identifiant universel de celle de ton OS, puisque le nom de device associé dans la chaîne qui suit est disk0s*2* : secteur *2* du disque 0, par défaut la partition où est installé OS X. Nulle part n'est mentionnée une UUID de l'ESP (EFI System Partition) correspondant au device disk0s*1* : secteur *1* du disque 0, ni un PATH au boot_loader de «rEFInd» qui y réside, qui serait :


```
<key>Path</key><string>\EFI\refind\refind_x64.efi</string></dict></array>%00
```
 => on en conclut donc que l'EFI n'active pas «rEFInd», mais «rEFIt».

♤​
Le type de chemin de boot que tu as en NVRAM ressemble à s'y méprendre au chemin de boot qui constitue le default lorsque le volume OS X est choisi comme disque de démarrage automatique : mention de l'UUID de la partition disk0s*2* comme valeur pour l'efi-boot-device.

Or, avec une telle adresse de boot en NVRAM, l'EFI n'exécute pas néanmoins le boot_loader régulier d'OS X (at: /System/Library/CoreServices/*boot.efi*), mais le boot_loader de «rEFIt» (at: /efi/refit/*refit.efi* - restitué d'après les commandes d'installation de ton message #3). Pourquoi ?

Parce que tu as passé une commande de "blessing" (de type : sudo bless --folder) qui "bénit" non pas le dossier des CoreServices de la Bibliothèque-Système qui recèle le boot_loader : *boot.efi* d'OS X ; mais "bénit" le dossier refit du répertoire efi situé à la racine de l'OS qui recèle le boot_loader : *refit.efi* de «rEFIt». Une commande de "blessing" n'affecte nullement la NVRAM, en effet, mais le "header" (en-tête) du système de fichiers du volume désigné comme cible. C'est donc sur le "header" du système de fichiers de la partition /dev/disk0s*2* de l'OS que se trouve fixé (par la commande sudo bless folder) le PATH au dossier recelant le boot_loader exécutable par l'EFI : le /efi/refit/*refit.efi*.

Voici donc comment se reconstruit la séquence de boot : l'EFI lit en NVRAM l'adresse de boot mentionné au label : efi-boot-device = UUID de la partition disk0s*2* de l'OS => l'EFI va donc au device mentionné (la partition de l'OS) et tombe, sur le "header" du système de fichiers contenu dans cette partition, sur le PATH instauré par la commande de "blessing" : /efi/refit/*refit.efi* => l'EFI suit donc ce chemin balisé et exécute le boot_loader : *refit.efi* de «rEFIt». Chemin logique déterministe, unilatéral, sans bifurcation ni ambiguïté, construit en 2 segments : le segment NVRAM = adresse au device par l'UUID de la partition disk0s*2* => le segment filesystem = adresse au boot_loader par le PATH fixé sur le "header" : /efi/refit/*refit.efi**.*

♧​Passe-moi la longueur de ces analyses dominicales, mais les problèmes logiques me passionnent jusque dans le plus petit détail.

Je conçois mieux, dans le contexte déterministe de boot que je viens de reconstruire, le problème graphique que tu rencontres : le démarrage se fait exclusivement sur «rEFIt» (comme démontré ci-dessus), et pourtant l'écran "gestionnaire de disque" de «rEFIt» se trouve perturbé par «rEFInd» alors même que ce "gestionnaire de disque" alternatif n'est pas  « activé » ! Comment cela se peut-il ?

C'est que «rEFInd» n'est pas activé (au sens où aucune adresse à son boot_loader sur la partition /dev/disk0s*1* de l'ESP ne figure en NVRAM au label : efi-boot-device), mais néanmoins «rEFInd» est installé (au sens où l'exécution antérieure du script shell : install.sh a créé sur la partition /dev/disk0s*1* de l'ESP ses 2 dossiers de boot potentiels : refind & tools, le 1er dossier recelant le boot_loader *refind_x64.efi*). Par ailleurs, pour peu que sur les conseils de _Roderick Smith_, le développeur de «rEFInd», tu aies créé à la racine de ton OS un répertoire (alternatif de celui de «rEFIt») intitulé EFI, avec un sous-dossier refind recelant  les ressources téléchargées de «rEFInd», alors tu y a là le boot_loader original : *refind_x64.efi* également.

Il y a tout lieu de penser que, lorsque le boot_loader *refit.efi* de «rEFIt» se trouve exécuté par l'EFI au démarrage, un processus de scan des volumes démarrables est lancé et que se trouvent identifiés par «rEFIt» comme volumes démarrables (et par suite affichés) tous ceux qui supportent un boot_loader, càd. un fichier terminé par l'extension *.efi* => ce qui donnerait une reconnaissance de l'ESP (/dev/disk0s*1*) comme volume démarrable (car recelant le *refind_x64.efi* at: EFI/EFI/refind/*refind_x64.efi*) ; une reconnaissance de Macintosh HD (/dev/disk0s*2*) comme volume démarrable (car recelant encore le *refind_x64.efi* at: /EFI/refind/*refind_x64.efi*) ; et une reconnaissance redondante de Macintosh HD (/dev/disk0s*2* _itou_) comme volume démarrable (car recelant le *boot.efi* règlementaire at: /System/Library/CoreServices/*boot.efi*).

=> je conçois mieux ton problème pratique : _abondance de biens nuit !_ --> la présence de dossiers de ressources de «rEFInd» (sur l'ESP comme à la racine de l'OS) perturbe «rEFIt» lors du scan des volumes démarrables (pauvre petit 
	

	
	
		
		

		
		
	


	




) et le conduit à afficher autant de volumes démarrables que de boot_loaders *.efi* trouvés.

♡​Si donc tu ne veux garder que «rEFIt» sans redondance causée par les dossiers de ressources de «rEFInd» recelant chacun un boot_loader *refind_x64.efi*, alors il faut que :

- a) tu supprimes _a la mano_ ces dossiers de ressources de «rEFInd». Pour ce qui est de l'ESP, tu n'as qu'à monter en volume cette partition par la commande :


```
diskutil mount /dev/disk0s1
```
 qui va faire s'afficher sur ton Bureau de session l'icône d'un volume EFI. Tu entres dans le répertoire de ce volume, tu entres dans le sous-répertoire éponyme EFI qu'il contient (ne pas supprimer : dossier Apple natif), et là tu tombes sur 3 sous-dossiers : APPLE (ne pas supprimer : dossier Apple natif) et refind & tools : ces 2 dossiers ont été créés par l'install.sh de «reFInd» => tu les mets à la corbeille et tu la vides en t'authentifiant (le dossier refind recèle le boot_loader activable *refind_x64.efi*).

- b) que tu bennes le dossier de ressources de «rEFInd» issu du téléchargement depuis le site «SourceForge» et situé quelque part à la racine de ton OS --> cela fait, j'ose espérer qu'au redémarrage, l'écran "gestionnaire de disque" de «reFIt» s'en trouvera apuré.

♢​Je trouve quand même dommage (et mon avis va dans le même sens que celui donné au tout début par *Jean* ) de préférer «rEFIt» (qui n'est plus développé) à «rEFInd» (toujours développé et plus raffiné). Le fait que «rEFIt» n'installe pas de ressources de démarrage sur une partition indépendante (celle de l'ESP : /dev/disk0s*1*), mais sur le volume même de l'OS /dev/disk0s*2* (avec recours au blessing) : ce me semble un procédé logique beaucoup plus susceptible d'interférences que celui de «rEFInd».

Si tu voulais donc ne passer que par «rEFInd», il faudrait que :

- a) tu bennes le dossier de ressources de «rEFIt» (pour éviter que son boot_loader *refit.efi* ne soit scanné par «rEFInd» - vérifier sur l'ESP /dev/disk0s*1* s'il n'y aurait pas de dossiers de boot de «rEFIt» installés à l'exécution de son fichier shell : j'ai un doute résiduel sur ce point quand même...) ;

- b) que tu rectifies le blessing du système de fichiers de l'OS en le restaurant au default par la commande :


```
sudo bless --folder /Volumes/"nom_du_volume_d'osx"/System/Library/CoreServices
```
 (en pratique : tu tapes sudo bless --folder, tu sautes un espace et tu fais un glisser-déposer du dossier CoreServices contenu dans : Système/Bibliothèque) ;

- c) que tu ré-exécutes l'install.sh de «rEFInd» par une commande de type :

```
sudo /chemin_au_fichier/install.sh
```
 (en pratique sudo + un espace + glisser-déposer du fichier install.sh dans la fenêtre du «Terminal».​--> il n'y a pas de raison que ça ne marche pas (à part le SIP si tu es sous «El Capitan» => passer alors au préalable la commande csrutil disable dans le «Terminal» de la «Recovery HD» afin de libérer la NVRAM pour l'édition du PATH au label : efi-boot-device) : personnellement, j'utilise toujours «rEFInd» sans problème d'une version d'OS X à une autre (actuellement avec «El Capitan»). De temps à autre, il faut seulement que je ré-exécute l'install.sh si une manœuvre expérimentale de ma part a fait sauter le PATH en NVRAM à l'efi-boot-device (pointant sur l'ESP /dev/disk0s*1* au boot_loader *refind_x64.efi* de «rEFInd»)...

❈​


----------



## AppleSpirit (11 Novembre 2015)

Bonjour,

Merci beaucoup pour toutes ces information fortement détaillées. C'est vraiment gentil d'avoir pris le temps de me répondre avec autant d'implication.

J'ai toutefois, depuis hier, un problème nouveau qui s'est déclenché et c'est peut-être lié au processus de sélection initial de l'os. En effet, lorsque je démarre le mac, il se met à ventiler fortement et l'écran reste tout noir. J'ai beau attendre, même 5 minutes plus tard, rien ne s'est passé.

Est-ce qu'il existe une quelconque procédure permettant de le débloquer ?

Merci pour votre aide.


----------



## AppleSpirit (11 Novembre 2015)

Je viens de réinitialiser le smc et le mac a finalement démarré. Mais je me demande si ce ne sont pas toutes ces manipulations entre refit et refind qui ont déclenché le problème...


----------



## AppleSpirit (11 Novembre 2015)

macomaniac a dit:


> Prose dominicale (avec « culs de lampe »)
> On va y arriver
> 
> 
> ...



Merci infiniment, j'ai pu désinstaller refind grâce à ces explications.


----------



## macomaniac (12 Novembre 2015)

AppleSpirit a dit:


> C'est vraiment gentil d'avoir pris le temps de me répondre avec autant d'implication.



Hé ! Il n'y a pas de quoi : tu m'as fourni sur un plateau un cas intrigant comme je les aime, et j'ai pris plaisir à en scruter les arcanes.

Bien que connaissant a priori le mécanisme logique du démarrage sur un gestionnaire de disque comme «rEFInd» {EFI => adresse en NVRAM => exécution primaire du boot_loader sur l'EFI System Partition disk0s1 => exécution secondaire du boot_loader de l'OS choisi} - il m'a fallu quelque temps avant de saisir la nature exacte du problème qui te tracassait : à savoir, que «rEFIt», seul lancé au démarrage, trouvait moyen de scanner le boot_loader concurrent de «rEFInd» lui-même non lancé, ce qui conduisait à des redondances d'affichage des Volumes reconnus démarrables.

=> tu parais avoir réglé ce problème, en gardant le seul «rEFIt» et en supprimant les ressources perturbatrices de «rEFInd».

--------------------​En ce qui concerne l'incident secondaire que tu mentionnes :



AppleSpirit a dit:


> J'ai toutefois, depuis hier, un problème nouveau qui s'est déclenché et c'est peut-être lié au processus de sélection initial de l'os. En effet, lorsque je démarre le mac, il se met à ventiler fortement et l'écran reste tout noir. J'ai beau attendre, même 5 minutes plus tard, rien ne s'est passé. Est-ce qu'il existe une quelconque procédure permettant de le débloquer ?
> 
> Je viens de réinitialiser le smc et le mac a finalement démarré. Mais je me demande si ce ne sont pas toutes ces manipulations entre refit et refind qui ont déclenché le problème...



--> logiquement parlant, le fait que le Mac démarre sur «rEFIt» plutôt que sur OS X (par exemple) n'implique rien d'extraordinaire : il n'y a même pas modification en NVRAM de l'adresse de l'efi-boot-device, qui, dans les 2 cas de figure, reste l'UUID de la partition /dev/disk0s2 de ton OS. C'est seulement l'adresse au dossier recelant le boot_loader à exécuter sur cette partition qui est changée, par la procédure de blessing ("bénédiction"), sur le header ("en-tête") du système de fichiers de cette partition, de :  /System/Library/CoreServices/*boot.efi* (default) à : /efi/refit/*refit.efi*. À moins que le boot_loader de «rEFIt» ne comporte un code problématique à exécuter pour l'EFI, je ne vois pas en quoi l'acte : *EFI* => *refit.efi* à la place de : *EFI* => *boot.efi* conduirait intrinsèquement à un affolement des ventilateurs et à un écran noir.

L'écran noir est régulier aussi longtemps que l'EFI n'a pas exécuté un boot_loader, soit pendant le PRE_BOOT : _check-up_ du _hardware_ (= POST) => gong de validation ("_Chime_") => chargement des arguments de boot en NVRAM.

Au moment où l'EFI a chargé d'après les instructions de la NVRAM l'adresse à un boot_loader à exécuter sur une partition du disque, il y a prise en charge des ressources de la Carte-Graphique afin d'allumer l'écran avec un fond d'écran gris-bleuté uni, puis exécution du boot_loader (*boot.efi* ou *refit.efi* ou *refind_x64.efi*) qui dispose donc d'une ressource graphique d'écran activée pour opérer son affichage propre : le logo  s'il s'agit du boot_loader par défaut *boot.efi* d'OS X ou la page de choix d'un disque de démarrage s'il s'agit du boot_loader d'un gestionnaire de disque tiers.

Il semble que chez toi (conjecture de ma part seulement) l'EFI ne parvenait pas à déclencher l'allumage de l'écran par la Carte-Graphique, ce qui fait que tu gardais un écran noir avec moulinage des ventilateurs. Tu parais avoir réglé ce problème par un reset_SMC.

Je t'invite, néanmoins, à garder à l'esprit cet incident, qui pourrait bien être une signal d'alerte pointant vers une Carte-Graphique (puce de la Carte-Mère) donnant des signes de faiblesse. Certes, tu as un _MacBook Air_2012_ et pas un _MacBook Pro_2011_ dont la Carte-Graphique a été reconnue par Apple sujette à défaillance. Mais à ta place je me défierais : j'ai personnellement un _MacBook Pro 15 Early_2011_ (dans lequel j'ai remplacé le HDD par un SSD) qui, récemment, alors qu'il était simplement en veille le couvercle rabattu, m'a fait ce genre d'incident : fort bruit de ventilateurs (avec un échauffement anormal du coin supérieur gauche de la coque) et écran noir au réveil. La Carte-Graphique venait de rendre l'âme (mais j'ai eu la bonne fortune d'obtenir le remplacement par une Carte-Mère neuve dans un AppleStore, ce modèle de Mac faisant partie d'un programme de restauration gratuite décidé par Apple). Donc : gare...

[J'ajoute une sous-conjecture, au cas où ton OS actuel serait «El Capitan» : mes ennuis ont suivi d'assez près la mise-à-jour de mon ci-devant OS «Yosemite 10.10.5» à l'OS «El Capitan 10.11». L'hypothèse n'est pas à exclure que cet OS (qui a bénéficié d'une « réception_critique » enthousiaste, avant même qu'il n'ait fait ses preuves, sur la simple annonce de sa mission de "consolidation" de l'OS antérieur) ne sollicite puissamment la Carte-Graphique des Macs, d'une manière dangereuse pour des modèles déjà un peu anciens qui ont des "heures de vol" derrière eux. Donc je le redis : gare...]

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


----------



## AppleSpirit (20 Novembre 2015)

mon MacBook air ne démarre plus, l'écran reste noir et le ventilateur tourne à fond. Est-ce que ces manipulations avec refit et refind peuvent avoir causé le problème ou est-ce que ça n'a aucun rapport ? Je précise que le reset smc et nvram ne résolvent pas le problème.


----------



## macomaniac (20 Novembre 2015)

Tu as un problème de Carte Graphique / Carte Mère - à tous les coups.

Sans rapport (à mon avis) avec tes installations / désinstallations de «rEFIt» / «rEFInd» - lesquelles n'ont fait qu'inscrire en NVRAM des chemins successifs de boot à tel ou tel dossier sur une partition du disque recelant le boot_loader alternatif du gestionnaire de disque à exécuter au démarrage par l'EFI. Rien de plus que ce que fait pour sa part le choix d'un _Disque de démarrage_ dans les _Préférences Système_ de façon on ne peut plus régulière : inscription en NVRAM d'un chemin de boot au boot_loader réglementaire d'OS X.

Le même ennui m'est arrivé avec mon _MacBook Pro Early_2011_ il y a un mois : la Carte Graphique avait lâché (mais ça peut aussi être un problème de processeur). Dans mon cas, j'étais couvert par le programme de restauration gratuit d'Apple pour les _MacBook Pro_ de cette année-là reconnus nantis de composants défectueux. Ce n'est certainement pas «rEFInd» que j'utilise au quotidien depuis des années que j'ai incriminé. Non, je soupçonne fortement au contraire (sans preuve définitive) «El Capitan 10.11» de solliciter puissamment les ressources graphiques de la Carte-Mère et d'avoir précipité la fin de la mienne.

Je te conseille de prendre rendez-vous au _Genius Bar_ de l'AppleStore le plus proche de chez toi (s'il y en a un) : un _Genius_ procèdera à la vérification des composants de la Carte-Mère avec feuille de diagnostic et devis éventuel en sortie. Le devis pour une Carte Mère neuve va chercher dans les 400€ (si tu n'es pas - ou plus - couvert par l'AppleCare). C'est à ce moment-là seulement que tu décides si tu signes la feuille de devis en acceptant les frais éventuels de remplacement de la Logic_Board ou non.


----------

