C'est bien la question que je me pose et que
Locke se pose aussi : disons les 2 qui ont pratiqué le vidage du contenu des répertoires
/System/Library/LaunchAgents (
206 fichiers
.plist) &
/System/Library/LaunchDaemons (
261 fichiers
.plist) et expérimenté un blocage du chargement de l'OS en cours de démarrage.
Si on parle bien des même répertoires (ceux de la
Bibliothèque_Système : /System/library et pas ceux de la
Bibliothèque Générale : /Library, comme il est hors de question de suspecter ta bonne foi - je trouve personnellement que c'est un fort joli problème.
En ce qui te concerne, tu as dû effectuer la 'purge' des fichiers
.plist en question et...
réussir à démarrer (en constatant un allègement de tes soucis de
kernel_task éventuellement) --> tu as extrapolé hardiment de ce cas positif unique une loi, ce qui explique ta préconisation dans ce fil sous forme de précepte "général".
En ce qui me concerne, j'ai installé «
Yosemite» en
Clean Install ce matin sur le volume vacant d'un DDE thunderbolt et j'ai : 1° vidé le contenu des 2 répertoires cités de la
Bibliothèque_Système en conservant les "enveloppes" vides : les dossiers ; 2° supprimé le contenu et le contenant en déplaçant donc lesdits dossiers --> dans les 2 cas, l'indicateur de progression a fini par se figer à moins de la moitié de la barre de chargement du premier écran affiché (j'ai attendu 21 minutes !! chaque fois et j'ai jeté l'éponge). J'en suis donc personnellemnet à 4 échecs de chargement de l'OS dans ces conditions (1 sur un clone de mon OS, 1 sur l'OS de mon SSD, et 2 sur un OS de DDE en
Clean Install) + l'échec de
Locke --> ça porte le total à 5 fois. En regard, il y a ton cas qui, dans ces conditions, au lieu d'apparaître comme
exemplaire d'une loi, paraît davantage comme une
exception à la règle.
Et j'avoue que la raison qui fait que ça ait pu marcher pour toi me déconcerte. Pour la raison que j'avais tenté de brosser : le processus
launchd a (entre autres) mission de prendre en charge les
daemons axés système. Or il ne peut pas se contenter de "charger" ces programmes (recelés par exemple dans
/usr) comme sont "chargés" les autres programmes UNIX qui sont les exécutables pouvant être invoqués en ligne de commande dans le «
Terminal». Non! Car un
daemon, c'est un programme qui
doit être lancé et ce conformément à des spécifications (il y en a qui ne sont pas lancés automatiquement au démarrage, mais
on demand = en cours de fonctionnement-Système, parce que l'état des choses est modifié, par exemple un disque attaché au Mac ; mais il y en a plein qui, eux, sont lancés automatiquement au démarrage, càd.
on launch) --> eh bien! le processus qui a la charge de ces
daemons =
launchd, il lui faut absolument (son commis d'office à cette fin en fait :
launchctl)
savoir quoi faire duquel quand comment (si j'ose dire
) et ce me semble à ça que servent les fichiers
.plist des dossiers cités : à instruire
launchd sur les modalités variables du
lancement des
daemons dont les programmes sont
chargés (par exemple, il y a un argument :
wait, ou bien un argument
on demand, ou encore un argument
keep alive dans les fichiers des
.plist concis mais abstrus qui paraissent orchestrer une "interaction").
Du moins, c'est ainsi que je me représente les choses. Dans cette optique, le vidage des dossiers de
.plist (préférences de
lancement) doit complètement
dérouter le processus
launchd. J'ai vérifié qu'aucun fichier
.plist ne se trouve recréé comme une espèce de préférence de lancement par défaut spécifiée à chaque
daemon. Est-ce que ça plante, alors, parce que le processus
launchd se bloque, ou bien parce que les
daemons qui devraient être lancés à toute force ne le sont pas? Toujours est-il que le démarrage se bloque. Ce matin, vers les 15' d'attente, le disque de mon DDE thunderbolt a carrément cessé de tourner! Comment attendre une complétion de démarrage dans ces conditions?
bompi a évoqué un "effet de cache" qui pourrait (très provisoirement) suppléer les carences en fichiers
.plist des répertoires évoqués. C'est effectivement une idée qui m'avait traversé l'esprit. Après tout, dans la phase
kernel qui précède, c'est bien un cache qui se trouve chargé par le
Boot_Loader : boot.efi et pas le
kernel original, à savoir le
kernelcache --> pourquoi pas alors une mise en cache des instructions de lancement des
daemons qui serait utilisée par
launchd (au lieu de la prise en compte des fichiers de
.plist originaux un à un)? Oui, mais alors, comment se fait-il que ni chez moi ni chez
Locke, pas plus dans un Système "rodé" que dans un Système "clean" - cet "effet de cache" n'ait joué?
Il y a quelque chose qui m'échappe
peut-être faut-il Tintin pour réussir à démarrer cf. message #17 --> c'est dit : la prochaine fois, j'essaye avec «Tintin au pays des soviets» ouvert à la page 62-63 en guise de cache...
