Rumpfungstrück!
Je suis partagé entre deux interprétations dominicales sans parvenir à me départager : la '
moins pessimiste' et la '
moins optimiste'
- 1° la '
moins pessimiste' dirait que : le Mac
boote, le
kernel et les
extensions se chargent, et lorsque le processus
launchd s'attaque à la tâche d'exécuter en mode
root les fondamentaux de l'OS consignés dans le répertoire '
Racine', il ne parvient pas à accéder aux ressources du dossier
etc. Parce que, dans le répertoire '
Racine', ce n'est jamais le dossier
etc qui est présent parmi les composants directs, mais c'est le super-dossier
private qui le comprend à titre de sous-dossier qui se trouve présent. Pour que le processus
launchd, qui possède l'adresse du répertoire '
Racine' :
/, parvienne aux 3 sous-dossiers contenus dans
private (càd.
etc,
var et
tmp), il faut qu'il trouve à côté du composant
private 3
liens_symboliques (
symlinks) qui le dirigent vers les sous-dossiers contenus =
⤻etc,
⤻var et
⤻tmp. C'est là la situation régulière.
À supposer, maintenant, que le lien symbolique :
⤻etc (puisque c'est là semble-t-il que le bât blesse l'onagre) soit
rompu de quelque façon qu'on voudra (= invalide), alors le processus
launchd se trouve incapable d'accéder au sous-dossier
etc de
private lorsqu'il a la tâche d'exécuter les fondamentaux du système. Il plante donc (-là sa tâche) et refile le mistigri à un bash du «
Terminal», en l'attente d'une commande qui lui indiquerait le chemin au sous-dossier
etc à partir du répertoire dans lequel il est loggé, càd. le répertoire '
Racine'
/.
Visuel du répertoire racine de «
Panther» :
et contenu de
etc (dans les ressources de «
Panther 10.3.9» émulé en ligne de commande par «
Qemu» dans l'environnement «
Mountain Lion» de mon
MacBook Pro) :
Serait-il alors judicieux, au prompt, de taper :
et ↩ + password (il ne s'agit-là que du lien symbolique rompu, le dossier étant inclus, lui, dans
private) puis :
Bloc de code:
sudo ln -s /private/etc /etc
et ↩ (étant donné que si le
symlink :
⤻etc existe (quoique rompu) dans le répertoire-racine, la 2è commande seule risque d'avorter sur un :
mais, une fois le
symlink éliminé, un
symlink valide vers
private/etc serait logé à bonne enseigne juste à la racine
/)?
♤
- 2° la
moins optimiste. Le processus
launchd initié par le
kernel à charge d'exécuter les fondamentaux de l'OS contenus dans le répertoire-racine
/ trouve bien un lien symbolique
⤻etc qui n'est pas brisé et donc a accès aux contenus du sous-dossier
etc de
private. Mais parmi les composants de ce sous-dossier, il tombe sur le fichier '
profile' qui, pour d'obscures raisons, n'a en rien les propriétés terminales d'un
fichier-exécutif. Et, donc, le
launchd planterait (-là sa tâche) en refilant le chien chaud au bash du «
Terminal» en signalant qu'il n'y a pas là un exécutable. Et comme le fichier '
profile' devrait avoir pour schéma basique :
Bloc de code:
# System-wide .profile for sh(1)
PATH="/bin:/sbin:/usr/bin:/usr/sbin"
export PATH
if [ "${BASH-no}" != "no" ]; then
[ -r /etc/bashrc ] && . /etc/bashrc
fi
si ce type d'exécutable n'est plus exécutable, justement - ça sent le roussi ♨ pour ainsi dire.
♧
<J'avoue ma
perplexité dominicale devant un '
is a directory' dont l'herméneutique me paraît obscure dans le contexte
. Le conseil le plus simple serait de re-démarrer sur le CD gris d'Install n°1 de «
Panther 10.3» pour tenter par l'«
Utilitaire de Disque» de réparer les permissions de l'OS installé sur le HDD. S'il ne s'agit que de réparer un lien symbolique, cela pourrait peut-être suffire. Encore faut-il que le CD se trouve... Si le fichier exécutable '
profile' a été dénaturé, ça sent par contre la ré-installation de l'OS
>
♡
