# Pomme Blanche fond Noir



## MacControle (11 Novembre 2014)

Bonjour,

j'ai remarqué que sur les macbook pro rétina lors du démarrage la pomme était blanche sur un fond noir, tandis ce que sur mon macbook (2012) la pomme est noir sur fond blanc.

Connaissez-vous un moyen pour modifier ces paramètre et avoir le même démarrage que sur les MacBook Pro rétina ?

Merci d'avance


----------



## RubenF (12 Novembre 2014)

Je pense que c'est un mystère aussi inéluctable que la Pomme noir sur fond Blanc des iPhones 5/5s/6/6+ Blanc et la Pomme blanche sur fond noir des iPhones EDGE/3G/3GS4/4S - 5/5C/5S/6/6+ Noirs..


----------



## corsinou (20 Novembre 2014)

Préférence Système / Général / cocher la case  Utiliser une barre des menus et un dock foncé
Voilà


----------



## RubenF (22 Novembre 2014)

Ca change aussi l'interface du Cold Boot ?


----------



## Pahra (12 Décembre 2014)

J'ai le même problème avec mon iMac 27 acheté tout récemment. J'ai installé le système sur un SSD en Thunderbolt, je ne sais pas si ça à voir quelque chose. Idem les icones de volume et luminosité sont noirs. Autrement la transparence est pareille. 

Le système installé d'origine sur le disque interne m'offrait un écran de démarrage blanc avec pomme noire pourtant. 

Corsinou, ta manip ne concerne que l'interface même du Finder et n'a pas d'incidence sur l'écran de boot du Mac. Enfin c'est ce qu'il me semble...


----------



## SebR2611 (5 Mars 2015)

En fait c'est simple, c'est suivant la couleur du contour de l'appareil. Sur un iMac récent (à partir de fin 2009) qui n'a plus de contour aluminium, mais dont la vitre avec bords noirs vont jusqu'au bord, l'écran de démarrage est noir pomme blanche. Sur un MacBook Air, qui n'a pas de bords noirs, le contour est en aluminium, donc démarrage fond blanc pomme noire. Sur iPhone/iPad c'est pareil, les modèle avec façade blanche (modèle doré et alu) démarre avec un fond blanc et une pomme noire, les modèle gris sidéral avec façade noire démarre avec un fond noir et pomme blanche.

C'est Apple dans toute sa splendeur, le souci du détail, jusqu'aux plus petits !


----------



## Breizh44 (6 Juillet 2015)

je relance ce sujet. 
après mise à jour 10.10.4, sur un macbook pro 2011 j'ai toujours la pomme grise sur fond gris.
moyen d'avoir la pomme blanche sur fond noir?


----------



## macomaniac (8 Juillet 2015)

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 :


```
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 : 
	
	



```
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.​
--------------------​


----------



## Breizh44 (8 Juillet 2015)

merci mais ça n'a pas fonctionné.
la partition à disparu et était inmontable.
j'en ai profité pour réinstaller la couche os et régler un problème efi latent.

ça doit être parce que j'ai mis un ssd et activé trimforce je suppose.

je laisse tomber, ce n'est pas vital et c'est ma machine de boulot. inutile de la planter et me faire chier à la réparer une seconde fois.


----------



## macomaniac (9 Juillet 2015)

Mince alors - je ne pensais pas du tout que tu pourrais avoir un problème en utilisant «DarkBoot.app». Je me suis amusé à alterner les options d'écran de démarrage : pomme blanche sur fond noir vs pomme anthracite sur fond gris en utilisant ce logiciel, et je n'ai rencontré aucun problème de re-démarrage. Chaque fois l'EFI exécute bien le boot.efi patché vs restauré, lequel remplit impeccablement sa fonction de chargement du kernelcache (noyau + bloc d'extensions) --> bref, l'OS démarre.

Ça ne peut pas être une question de type de disque ou d'activation du _Trim_ : sur mon _MacBook Pro Early_2011_, j'ai remplacé aussi le HDD par un SSD et, «Yosemite 10.10.4» installé, j'ai désactivé le _Trim_ via «Trim Enabler» pour le ré-activer par l'intermédaire de la commande Apple trimforce enable et je n'ai rencontré aucun problème. La commande trimforce se contente de copier une nouvelle extension du noyau, de la localisation en réserve de l'original (at: /System/Library/Filesystems/AppleDataSetManagement.kext), dans le répertoire /System/Library/Extensions - ce qui lui permet d'être chargée au démarrage. La séquence de démarrage est donc : EFI > boot.efi > kernelcache (incluant la néo_kext Apple) --> si le problème s'était situé au niveau extensions (kernelcache), ton Mac aurait quand même commencé de démarrer logiquement (affichage du logo  qui signale l'activation du boot.efi).



Breizh44 a dit:


> la partition à disparu et était inmontable



Tu veux dire que ton Mac ne démarrait plus automatiquement sur l'OS et que tu n'avais même plus le volume «Yosemite» à l'écran d'affichage du disque de démarrage (touche "alt") ? Ou, plus radicalement, en démarrant sur la partition de récupération «Recovery HD» (⌘R), que, dans l'«Utilitaire de Disque», tu n'avais plus du tout la partition Macintosh HD affichée - ce qui bien entendu ne permettait pas de la monter en volume afin de restaurer via le «Terminal» le boot.efi originel sauvegardé dans les CoreServices sous le nom de : boot_stock.efi ?

Si c'est le dernier cas de figure, une simple modification au niveau du fichier /System/Library/CoreServices/boot.efi ne peut pas, intrinsèquement, résilier le système de fichiers d'une partition, ni son montage en volume - si le disque est en bon état et si le système de fichiers de la partition est valide. Que l'OS ne démarre pas, c'est un point ; que sa partition disparaisse de l'affiche, c'est le signe d'erreurs graves dans la structure du système de fichiers que l'édition d'un seul fichier (le boot.efi) ne peut pas causer. À tout le moins, ça peut être la goutte d'eau qui fait déborder le vase des... erreurs logiques.

☞ ça me paraît très énigmatique - ce plantage.

--------------------
​Au cas où d'autres "customisateurs" rencontreraient un problème de re-démarrage (sans que l'accessibilité du volume de leur OS ne soit compromise), je voudrais éditer le tissu d'erreurs du sieur *w0lfchild *en indiquant les commandes à passer dans le «Terminal» de la «Recovery HD» afin de restaurer le fichier boot_loader : boot.efi en charge du lancement logiciel de l'OS --> en cas de plantage du démarrage suite à l'option : black dans le logiciel, dans l'environnement de la «Recovery HD» (atteint par ⌘R au départ), aller à la barre de menus supérieure de l'écran - menu _Utilitaires_ et lancer le «Terminal» :

- a) Pour agir sur le système de fichiers de l'OS, il faut l'adresser indirectement par l'intermédiaire du répertoire des Volumes. Par défaut, le nom du volume de l'OS est Macintosh HD mais il peut avoir été customisé, justement, dans son intitulé. Pour vérifier le nom de ce volume, commencer donc par saisir dans la fenêtre du «Terminal» la commande (attention : le "l" de "ls" est la minuscule de la lettre L, pas le chiffre 1) :


```
ls /Volumes
```
 et ↩︎ (presser la touche "Entrée" du clavier pour activer la commande) --> la liste des volumes montés s'affiche et il est donc possible de vérifier le nom exact du volume qui supporte OSX. Si l'intitulé diffère du Macintosh HD des commandes suivantes, substituer exactement ce nom tel quel entre "" comme "Macintosh HD", à la place exacte de ce dernier dans les commandes.

- b) enchaîner avec la commande :


```
chflags nouchg /Volumes/"Macintosh HD"/System/Library/CoreServices/boot.efi
```
 et ↩︎ --> il s'agit d'une commande de déverrouillage du fichier patché boot.efi, sans laquelle il est intouchable (l'oubli de cette commande libératrice préalable est encore une ânerie du *fils_du_loup*).

- c) poursuivre (attention aux *2* *espaces critiques*) avec : 
	
	



```
mv /Volumes/"Macintosh HD"/System/Library/CoreServices/boot_stock.efi /Volumes/"Macintosh HD"/System/Library/CoreServices/boot.efi
```
 et ↩︎ --> il s'agit du remplacement du fichier boot.efi patché par le fichier copie de l'originel boot_stock.efi renommé en boot.efi [NB. Il est possible de faire des copier-coller de bouts de commandes déjà saisies dans la fenêtre du «Terminal» pour s'éviter l'_aria_ de retaper littéralement des segments à rallonges...].

- d) finir par : 
	
	



```
chflags uchg /Volumes/"Macintosh HD"/System/Library/CoreServices/boot.efi
```
 et ↩︎ --> par quoi le fichier originel restauré se trouve re-verrouillé.​
☞ l'OS doit re-démarrer avec l'exécution par l'EFI du boot_loader : boot.efi originel restauré (copier les lignes de commandes sur un bout de papier _okazou_ il faudrait rattraper le coup. Mais, je le redis, je n'ai rencontré aucune problème sur mon Mac supportant «Yosemite 10.10.4»).


----------



## Breizh44 (9 Juillet 2015)

simplement que la partition était invisible avec le démarrage de choix de volume (alt).
a la limite, si je savais ou modifier à la main je préfèrerai. je ne suis pas fan de passer par l'app d'un autre quand j'ai la capacité pour opérer par moi même.

c'est dans boot-efi soit même qu'est la référence d'ordinateur à changer ou autre part?


----------



## macomaniac (9 Juillet 2015)

(erreur de saisie)


----------



## macomaniac (9 Juillet 2015)

Tu avais peut-être perdu le blessing du volume de ton «Yosemite» qui lui permet, justement, d'être détecté comme volume démarrable. Dans ce cas, avant de redémarrer l'OS «Yosemite», passer dans son «Terminal» la commande : 
	
	



```
sudo bless --folder /System/Library/CoreServices
```
 ou, depuis le «Terminal» de la «Recovery HD» : 
	
	



```
bless --folder /Volumes/"Macintosh HD"/System/Library/CoreServices
```

[le blessing fixe sur le header (en-tête) du système de fichiers de la partition l'adresse au répertoire CoreServices recelant le boot_loader boot.efi --> le diskmanager (programme auxiliaire de l'EFI) sollicité par un démarrage avec "alt" est ainsi capable de lire le Système de fichiers de cette partition comme démarrable (en y identifiant la présence  d'un boot.efi) et d'afficher le volume à l'écran de choix du disque de démarrage.]

--------------------​Pour une édition manuelle du boot.efi (at: /System/Library/CoreServices/boot.efi - fichier à déverrouiller par une commande : sudo chflags nouchg /System/Library/CoreServices/boot.efi ; à reverrouiller par : sudo chflags uchg /System/Library/CoreServices/boot.efi), je t'ai trouvé ce pas-à-pas du site «MacRumors» : ☞*Guide: Black boot screen + white Apple logo on "unsupported" Macs (boot.efi hack)*☜ (c'est la version _à la mimine_ de l'opération effectuée par «Dark Boot.app»).

--------------------
​☞ sinon (_bis repetita placent_) j'ai répété via «Dark Boot.app» l'option black et vice-versa default, à la fois dans mon OS «Yosemite» et alternativement dans «El Capitan» (installé sur un volume parallèle de mon SSD) : aucun problème --> les OS démarrent comme des fleurs. Je note qu'il faut attendre le *2è* re-démarrage pour que pomme blanche + écran noir s'affichent : à croire qu'en ce qui concerne le boot_loader boot.efi, là aussi (comme pour kernel + kexts mis en cache dans le kernelcache) il y a une mise en cache : l'EFI doit exécuter couramment le cache du boot_loader et pas l'original, l'édition du cache demandant une récidive du démarrage (cet effet de cache rend d'autant plus mystérieux ton plantage, qui en fait n'en était pas, puisque le démarrage se serait effectué sur le cache du boot.efi gardant les paramètres non édités de l'original et que ton OS devait être parfaitement chargeable, à condition de re-bénir le dossier CoreServices).


----------

