Claude &
Jean
Tu fais :
sudo find / -iname "*diskwarior*" -exec ls -l {} +
Il faut deux «
r » à "
diskwarrior" --> sans quoi la commande ne peut rien trouver.
----------
Je me livre ici à un exercice spéculatif
Le safe boot fonctionne, c'est donc un truc qui se charge dès le début et avant l'User.
Le
Safe Boot > outre vider les caches-Système > met en
quarantaine d'injection dans le
kernel les
extensions de tierce partie. On serait donc tenté de chercher les applications tierces qui injectent des extensions dans le
kernel au démarrage.
Soit ! mais comment alors raccorder ce constat (un démarrage en
Safe Boot permet le re-démarrage ou l'extinction) --> avec cet autre constat :
La plupart des applis quittent correctement, mais il reste toujours le fond d'écran et le Dock.
--> ici ce qui proscrit le re-démarrage ou l'extinction n'apparaît pas une extension du noyau tierce (tâche d'éjection incombant au
kernel après la fermeture de la session) > mais un processus résilient appartenant à l'
utilisateur.
Conjecture renforcée par le constat :
Impossible ... même de quitter la session en cours.
il y a donc bien ici
impossibilité de fermer la session pour se logger (par exemple) dans la session de l'utilisateur
toto.
Et enfin > comment raccorder encore le 1er constat (démarrage en
Safe Boot --> résolution du problème) avec ce dernier constat :
création d'une nouvelle session toute neuve (admin, toto et toto) pareil
--> parce qu'il est clair que la session neuve
toto n'implique
aucun agent de lancement pour l'utilisateur ni
aucune application se lançant en ouverture de session. Et pourtant il semble que --> cette session vide refuse aussi de se fermer de manière à permettre le déloggement > le re-démarrage > ou l'extinction (si j'interpréte bien le : "pareil").
En contemplant mentalement ce tableau --> je contemple un paradoxe que je ne parviens pas à réduire logiquement :
- le Safe Boot mettant en quarantaine les extensions de tierce partie permet le re-démarrage ou l'extinction > parce que le kernel > après la fermeture de la session d'utilisateur > ne bloquerait pas à l'éjection des kexts en question
- en cas de démarrage normal > c'est la session d'utilisateur qui refuse de se fermer > avant même qu'il n'incombe au kernel la tâche d'éjecter les extensions et de couper.
En quoi la mise-en-quarantaine d'extensions au démarrage a-t-elle donc un effet sur la fermeture de la session d'utilisateur > vu que ce n'est
pas pendant la session encore ouverte que les extensions sont
éjectées du
kernel ?
Dois-je imaginer le scénario suivant : il y aurait une application = x requérant l'injection d'une (ou plusieurs) extension(s) au démarrage > qui ferait partie des applications se lançant en ouverture de session et/ou dont un agent se lancerait avec la session ? --> alors > la non-injection des extensions correspondantes --> empêcherait l'agent ou l'application de se lancer en ouverture de session --> ce qui fait qu'aucun processus en relevant ne bloquerait la fermeture de session. Par contre > dès lors que l'extension correspondante serait injectée au démarrage > alors des processus de l'application démarreraient avec la session et empêcheraient sa fermeture > proscrivant donc le déloggement > le re-démarrage ou l'extinction.
Ce scénario (de l'imagination) a un point faible crucial : comment, dans ces conditions, expliquer la non-fermeture de la session
toto pour laquelle aucune préférence relative à cette application n'est définie ? --> la session devrait se fermer sans aucun problème.
La seule chose que j'envisage comme issue possible à ces paradoxes logiques est la suivante : lors d'un démarrage en
Safe Boot > il n'y a pas que les extentions de tierce partie qui sont mises en quarantaine d'injection dans le
kernel > mais aussi une série de
kexts Apple dispensables. Il y aurait donc une
kext Apple injectée en démarrage normal qui aurait une incidence sur la possibilité de fermer une session quelconque d'utilisateur de manière à permettre le déloggement > le re-démarrage ou l'extinction. Je ne peux pas dire laquelle.
S'il en était ainsi > il faudrait alors conjecturer qu'il y a un problème avec la mise-à-niveau du
mini à «
El Capitan». Installation comportant une erreur ?
