Salut
Breizh.
Je pense que j'ai la solution à ton souhait de customisation de l'écran de
boot : avoir une pomme blanche sur un fond noir.
Tu as à ta disposition une petite application dont voici la page de présentation sur
GitHub par son développeur
w0lfschild : ☞
DarkBoot☜ ; et voici la page directe de téléchargement : ☞
Dark Boot.app☜ (version 3.3.1). C'est une application
self-contained qui s'installe par simple déplacement dans le répertoire des
Applications et se lance à partir de lui.
Je l'ai personnellement expérimentée sur mon
MacBook Pro Early_2011 supportant «
Yosemite 10.10.4» et j'ai pu constater qu'elle marche (écran noir et pomme blanche à volonté) sans occasionner de plantage au
boot (ce qui était la préoccupation majeure). Il te suffit, l'application lancée, d'opter dans son menu :
Boot Color pour l'option
black + "
Apply" et au re-démarrage tu auras la customisation voulue. Pour revenir à l'écran classique, choisir l'option
default + "
Apply" (éventuellement, ré-itérer les re-démarrages).
--------------------
Ayant tous deux conversé naguère (dans un fil que tu avais créé concernant un problème de
CoreStorage), tu dois te souvenir que j'aime bien expliciter ce qui peut l'être sans craindre les effets de
longitude sur le discours... Voici donc quelques gloses sur le sujet.
Pour customiser le choix des couleurs de l'écran de
boot, il faut se risquer à affecter un fichier absolument critique pour le démarrage du Mac --> le
boot-loader : boot.efi (localisé at:
/System/Library/CoreStorage) qui peut être considéré comme une "application de l'
EFI" (aka le
Programme Interne du Mac ou
Firmware recelé dans une puce de la Carte-Mère). Ladite
EFI au démarrage, après vérification du
hardware, exécute le
boot_loader : boot.efi comme fichier démarreur du Système Logique du disque et lui passe la main pour charger le bloc-cache solidarisant le
kernel et les extensions du noyau : le
kernelcache. C'est, en effet, dans les paramètres du
boot_loader : boot.efi que résident les arguments de préférence pour un affichage graphique de l'écran de
boot. Autant dire qu'une corruption de ce fichier démarreur équivaut à une impossibilité de charger l'OS.
J'étais donc - comment dire ? - d'humeur
a priori "soupçonneuse" en ce qui concerne le
patch que le logiciel «
Dark Boot.app» était susceptible d'opérer sur le fichier
boot.efi. J'ai heureusement pu vérifier qu'il n'impacte ce fichier que de manière assez mineure, en interpolant l'identifiant des Macs trop anciens pour supporter le
Dark Boot dans la liste des machines supportées a priori par ce mode -
patch assez classique dans l'esprit qui passe "comme une lettre à la boîte"...
Le développeur ne s'est quand même pas risqué à proposer un logiciel affectant le code direct du
boot.efi de l'OS sans procéder à une opération de "back-up" parallèle. Je t'invite, pour contempler
de visu cette opération, à ouvrir graphiquement le répertoire :
/System/Library/CoreService et à avoir sous les yeux le fichier verrouillé (le seul et unique de l'OS) :
boot.efi avant de lancer le logiciel «
Darl Boot.app». Tu vas apercevoir du "mouvement" local : un fichier intitulé
boot_stock.efi se trouve créé à côté du fichier
boot.efi des
CoreServices. Voici pour capturer le sens de la manip : le logiciel «
Dark Boot.app» commence par créer une copie de sauvegarde du
boot.efi original sous l'intitulé modifié de
boot_stock.efi, puis, après déverrouillage du
boot.efi originel, il opère le patch de l'identifiant de la bécane et la modification de la préférence de mode_couleur au
boot, après quoi il re-verrouille le fichier. Le Mac re-démarrera donc avec exécution par l'
EFI du fichier
boot.efi patché (en cas de ré-application à rebours de l'option de couleur :
default, alors il y a déverrouillage du
boot.efi patché et déplacement à sa place de l'originel sauvegardé
boot_stock.efi qui disparaît en tant que tel puis re-verrouillage du
boot.efi restauré).
Le logiciel affiche dans sa GUI un petit laïus explicatif sur le mode d'emploi suivi d'un procédé de récupération en cas de plantage au
boot. Voici ce dernier topo :
Bloc de code:
How to restore (if your can't boot):
● Boot into your recovery partition (boot holding command+r)
● Open Terminal
● Type in:
cd /System/Library/CoreServices
sudo mv ./boot.efi ./boot.efi.bak
sudo mv ./boot_stock.efi ./boot.efi
sudo chmod 644 ./boot.efi
sudo chown root:wheel ./boot.efi
sudo chflags uchg ./boot.efi
sudo reboot
☞ voilà un petit morceau d'anthologie : qu'un développeur assez culotté pour s'attaquer au patch du
boot_loader : boot.efi soit capable de pareilles bourdes logiques - il y avait de quoi (quand j'ai testé l'application) carrément
flipper... Mais apparemment c'est quelqu'un qui est plus à l'aise dans la ligne de code que dans la ligne de commande... Autant son
patch du
boot.efi est fiable - autant son topo de récupération dans le «
Terminal» de la «
Recovery HD» aligne ânerie sur ânerie (et je reste poli). Si les intervenants de «
MacGé» s'avéraient aussi mêle-tout que ce gars-là - ça
craindrait carrément...
Bon voici le croquignolet.
- Lorsqu'on démarre sur la «
Recovery HD», il est évident qu'on démarre sur un Système (image abrégée de celle de l'OS) dont le point de montage en tant que Système démarré est l'immédiatement adressable
/ --> une commande
cd logeant l'opérateur à l'adresse :
/System/Library/CoreServices le loge donc dans les
CoreServices du Système de la «Recovery HD» et à aucun moment dans les
CoreServices de l'OS dont le système de fichiers non-démarré n'est adressable qu'indirectement at:
/Volumes/Macintosh\ HD/ Or c'est bien le fichier
boot.efi des
CoreServices de l'OS qu'on veut restaurer - pas celui du Système
de la «Recovery HD» - lequel de surcroît est inéditable, car le Système de fichiers de la «
Recovery HD» ne monte qu'en
lecture seule (
read_only). Il faut donc se logger ainsi :
Bloc de code:
cd /Volumes/Macintosh\ HD/System/Library/CoreServices
- dans le «
Terminal» de la «
Recovery HD», l'invite de commande est
-bash-3.2#, le sigle
# révélant qu'on est dans un
shell en droit
root automatique. L'argument préfixe
sudo non seulement est redondant (car
root n'a pas à se demander par
sudo la permission à lui-même d'opérer en tant que
root), mais invalide carrément la commande, car
sudo par définition est une référence introuvable dans un
shell root --> les 2 commandes
mv ne passent donc qu'à condition d'enlever le
sudo --> alors la première renomme correctement le fichier
boot.efi patché à un intitulé de sauvegarde :
boot.efi.bak et renomme la copie du fichier originel
boot_stock.efi à son intitulé primitif
boot.efi.
- les 2 commandes
chmod et
chown, outre la persistance du préfixe
sudo invalide, sont parfaitement futiles, car la copie de sauvegarde
boot_stock.efi opérée par le logiciel en droit
root a gardé et ses propriétaires (
root:wheel) et ses permissions (
644) intègres. Par transitivité de l'implication, le renommage par la commande antérieure dans le
shell de
root du fichier
boot_stock.efi à l'intitulé primitif :
boot.efi préserve, bien entendu, les droits primitifs intacts.
- la commande
chflags uchg de re-verrouillage du fichier
boot_stock.efi renommé
boot.efi est valide à condition encore d'ôter le préfixe
sudo. Idem pour la dernière commande :
sudo reboot : préfixe
sudo invalide.
--------------------
