Soit un iMac sous MacOs X 10.6.8
J'ai remarqué que depuis le 28 juillet dernier, la console comporte une série de lignes d'erreur qui se répète régulièrement:
31/08/13 17:10:50 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:50 com.apple.kextd[10] Rescanning kernel extensions.
31/08/13 17:10:50 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:51 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:51 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:51 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:51 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:54 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:54 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:55 com.apple.kextd[10] Can't create kext cache under / - owner not root.
31/08/13 17:10:55 com.apple.kextd[10] Can't create kext cache under / - owner not root.
Je n'ai pas souvenir d'avoir installé quelque chose de nouveau fin juillet car je laisse ce vieux Mac tranquille et n'y installe plus rien (sauf peut-être une mise à jour de sécurité Apple)
A priori ça ne l'empêche pas de fonctionner normalement, mais j'aimerais pouvoir identifier l'extension que kextd n'arrive pas à mettre en cache (faute d'avoir les droits suffisants)...
Quelqu'un aurait une idée pour l'identifier?
Ou chercher?
LCVMT remy 
!
[
Trad. : Laisse Ce Vieux Mac Tranquille, comme diraient les Américains dans leur 'language' (sic) fertile en acronymes]. Ainsi, il se moquera bien dans son sommeil sans rêves de toute 'consolation' . Qu'as-tu besoin d'aller fourrer le long nez de la curiosité dans les obscurs arcanes du 'launcher process' au grand dam de la 'Docte_Ignorance' qui apporte seule la paix de l'âme? Car je subodorerais là une nouvelle variante du désormais notoire : «Paradoxe_de_Rémy», à savoir : 'Plus la Kext se CACHE_(à root), moins ça CACHE au démarrage'. Résultat : comme avec la version 'Plus il y a de RAM, plus ça RAME au démarrage' - tu te retrouves à perdre bien un pincée de secondes au boot! ]
Bon, assez ri.
macomaniac - au rapport!
♤
Si la commande sur ton
iMac qui fait tourner «
Snow» :
ne te donne pas :
je trouve que la situation n'est pas saine du tout! Car la situation régulière
drwxr-xr-x signifie que le répertoire (
directory) global = l'espace entier de l'OS ouvert à partir du point de montage (
/) est en
rwx = lecture/écriture/exécution pour son propriétaire =
root, et seulement en
r-x = lecture_&_exécution sans écriture pour le groupe =
wheel, lequel est strictement le '
Groupe_Système' habilité à la gestion des fichiers-système, dont le seul et unique membre est
root et personne d'autre ; enfin, en
r-x = lecture_&_exécution sans écriture pour tous les autres =
Others, càd. par exemple les admins, ici.
Ça, c'est la situation qui assure au Système sa stabilité. En substituant, comme droits attachés au répertoire global ouvert à partir du point de montage :
c'est furieux, comme situation! Je peux te dire : je n'aimerais pas me ballader dans un tel espace
. Ça
craint un max! Car cela veut dire que le
d(irectoire de départ total ouvert à partir du point de montage, donc l'espace OS au niveau le plus global) a 3 catégories d'
Accédants qui possèdent à
égalité des
droits absolus =
rwx (lecture/écriture/exécution) :
root, le propriétaire comme il se doit, mais aussi le groupe
admin (sic! c'est-à-dire tous les usagers qui ont un compte-admin) et la 'totale' maintenant :
tous les autres (qui se balladent dans l'espace de l'OS avec pour seul viatique un compte standard et peut-être bien même d'invité) possèdent des droits
égaux à root!
Rontudju! - comme dirait
De_Mesmaecker - qui m'a fichu un
garçon de Bureau pareil capable des
gaffes les plus monstrueuses?
♧
La solution qui paraît en avoir '
consolé' plus d'un qui puisent leur lait à la
vache_(
qui_rit = 'Google'), à savoir la commande :
ne dit rien des
permissions qui vont être les privilèges des
admins, sans compter des
autres [
comme si le groupe des admins avait à supplanter, en bonne 'république_des_élites', la tyrannie de l'instance wheel qui ressemble au triumvirat Romain réduit au seul César en guise de root - ce qu'appelait de ses vœux Cicéron, lequel préférait les intérêts oligarchiques des Sénateurs admins de la propriété foncière et tremblait devant le monopole du pouvoir suprême entre les mains d'un qui restait le Tribun du Peuple soucieux d'équilibre social].
En érigeant un groupe
admin, ainsi que tous les
autres, au rang des privilèges de
root sur l'espace du répertoire global de l'OS à partir du point de montage - c'est sûr qu'on
noie le poisson, si je puis dire, d'une
Kext récalcitrante à la propriété de
root dans un espace où
tout le monde est roi . C'est-à-dire où la plus complète
anarchie du libéralisme (le renard libre dans le poulailler libre) peut désormais s'exercer sans obstacle [la 'nature humaine' étant ce qu'elle est]...
♡
Quant à moi, je préfèrerais ô combien! - comme d'ailleurs,
remy, tu le revendiques dans ton premier message : «
pouvoir identifier l'extension que kextd n'arrive pas à mettre en cache (faute d'avoir les droits suffisants)», afin de pouvoir la replacer sous l'autorité légitime de
root.
Car les messages de ta
Console signalent qu'en cours de
boot le
Lanceur_Système =
launchd, démarré par le
Noyau =
kernel sous l'autorité de
root, n'arrive pas à lancer le
launch agent : '
com.apple.kextd' = fichier de configuration de mise_en_cache des
Extensions-du_Noyau =
Kexts. Et donc le Système se lance sans cache d'extensions qui aurait accéléré son
boot.
♢
Par voie de conséquence, tu aurais peut-être bien intérêt à passer la commande suivante :
Bloc de code:
ls -al /System/Library/Extensions
qui va te sortir une liste de toutes tes extensions installées précédées de leurs
permissions et de leurs
accédants. Si tu en repères, une ou l'autre, qui ne soit pas strictement conforme à :
alors il y a des chances que tu tiennes la rebelle à l'autorité
root au lancement de la mise en cache. À condition, bien entendu, que les droits sur
/, càd. le répertoire global à partir du point de montage, ne soient pas :
mais soient conformément à la règle :
Si ce n'était pas le dernier cas, un :
rétablirait la situation légitime sur le répertoire de départ
/.
Mais encore, quelqu'un qui voudrait carrément replier les
Extensions_du_Noyau à la régulation de
root et du groupe
wheel, pourrait bien passer la commande :
Bloc de code:
sudo chown -R root:wheel /System/Library/Extensions
de manière non seulement à attacher au dossier '
Extensions' les privilèges d'accès des
Accédants : propriétaire =
root et groupe =
wheel, mais par l'ajout de la fonction récursive
-R attacher dans le
sub-espace du dossier ces privilèges à chaque
Kext en particulier, de manière à les placer sur un pied d'égalité par rapport à
root. Il conviendrait pour finir de régler les
permissions de chaque
Accédant de manière légitime (càd. conforme à l'équilibre du Système), en passant la commande :
Bloc de code:
sudo chmod -R 755 /System/Library/Extensions
Interprétation : commande de modification des permissions '
chmod', avec effet récursif
-R étendant ces permissions à chaque
Kext contenue élémentairement dans le dossier
Extensions. Version numérique des permissions, par usage des équivalences :
r=4 ;
w=2 ;
x=1. Donc, comme je veux
rwx (pour
root) +
r-x (pour
wheel) et
r-x (pour
autres), cela me donne [
4+2+1] (pour
root)_[
4+0+1] (pour
wheel]_[
4+0+1] (pour
autres) =
755.
♗
).
