[Xorg] souris et clavier dysfonctionnels après mise à jour

[LunchTime]

Bonjour à toutes et à tous,

Je rencontre un problème qui a été soulevé de nombreuses fois, ici et ailleurs sur le net, mais, après plus de 24 h de tentatives et de recherches je reste bloqué.

Après une upgrade complète (pacman -Syu) tout allait bien, jusqu'au premier reboot.
Il m'est possible de me loguer correctement (dans le terminal -- le clavier fonctionne donc bien)
puis de lancer startx
Xfce (ou LXDE, que j'ai installé pour tester) se lance, mais la souris et le clavier ne répondent plus. Seul le bouton d'allumage de l'ordinateur a un effet et permet de l'éteindre.

Au cours de mes diverses recherches de solutions, j'ai noté que si, avant de lancer X, je désinstalle / réinstalle un environnement de bureau (ça marche avec xfce, lxde, lxqt) ce dernier se charge correctement et la souris et le clavier fonctionnement. Après reboot, ils ne fonctionnement plus à nouveau.
NB: j'avais les drivers libinput installé, j'ai ajouté evdev (après avoir vu que quelqu'un avait résolu un problème similaire comme ça) mais sans succès pour ce qui me concerne.

Voici quelques logs :

journalctl -b : https://pastebin.com/pgR9LJJ7
.local/xorg.0.log : https://pastebin.com/b7BTJpnN
/var/log/pacman.log : https://pastebin.com/EuY11Ms8

Merci par avance pour toute aide ou suggestion !

[benjarobin]

Bonjour,
Peux tu avec ton utilisateur (pas en root) donner la sortie de :

Code : Tout sélectionner

ls -l  /dev/input/event*
id

Edit: Mauvaise piste, l’utilisateur n'a pas accès normalement à ces fichiers. Il faut des droits particuliers. La question que je me pose, c'est comment cela fonctionne quand on lance Xorg en tant qu'utilisateur ? => Edit : Via systemd-logind quand lancé via startx

Note : Si tu utilise un gestionnaire de connexion, comme lightdm, tu ne devrais plus avoir de problème (en théorie).

Il nous faudrait le log complet du système, donc la sortie de journalctl -b en root, car si tu lances en tant que simple utilisateur, tu n'as pas grand chose...

Edit 2: Je pense que tu as un souci avec systemd-logind, on verra plus clairement le problème une fois que l'on aura le log système

[LunchTime]

Merci pour ta réponse, voici la sortie demandée :

Code : Tout sélectionner

crw-rw---- 1 root input 13, 64  4 févr. 19:14 /dev/input/event0
crw-rw---- 1 root input 13, 65  4 févr. 19:14 /dev/input/event1
crw-rw---- 1 root input 13, 74  4 févr. 19:14 /dev/input/event10
crw-rw---- 1 root input 13, 75  4 févr. 19:14 /dev/input/event11
crw-rw---- 1 root input 13, 76  4 févr. 19:14 /dev/input/event12
crw-rw---- 1 root input 13, 77  4 févr. 19:14 /dev/input/event13
crw-rw---- 1 root input 13, 78  4 févr. 19:14 /dev/input/event14
crw-rw---- 1 root input 13, 66  4 févr. 19:14 /dev/input/event2
crw-rw---- 1 root input 13, 67  4 févr. 19:14 /dev/input/event3
crw-rw---- 1 root input 13, 68  4 févr. 19:14 /dev/input/event4
crw-rw---- 1 root input 13, 69  4 févr. 19:14 /dev/input/event5
crw-rw---- 1 root input 13, 70  4 févr. 19:14 /dev/input/event6
crw-rw---- 1 root input 13, 71  4 févr. 19:14 /dev/input/event7
crw-rw---- 1 root input 13, 72  4 févr. 19:14 /dev/input/event8
crw-rw---- 1 root input 13, 73  4 févr. 19:14 /dev/input/event9

et

Code : Tout sélectionner

uid=1000(seb) gid=100(users) groupes=100(users),12(mail),93(optical)

[benjarobin]

Voir les éditions de mon premier message.
Mais ton problème vient de là :

Code : Tout sélectionner

(EE) systemd-logind: failed to get session: PID 567 does not belong to any known session

[LunchTime]

Ah, une piste =)

Voici le log de journalctl -b en root
https://drop.chapril.org/download/ffb8b ... fHLxnLE_Kg
(le fichier est gros, il ne passait pas sur pastebin)

[benjarobin]

Question : Pourquoi tous les composants de systemd affichent les logs de debug ? Qu'est ce que tu as modifié pour avoir ces messages de debug ?
Je continue d'analyser tes logs (mais si tu peux fournir les logs, sans le debug, je suis preneur)...

Edit : Tu n'aurais pas modifier LogLevel dans /etc/systemd/system.conf et/ou /etc/systemd/user.conf (Voir https://www.freedesktop.org/software/sy ... #LogColor= et aussi https://www.freedesktop.org/software/sy ... gLevelMax= )

Voilà la raison de ton problème :

Code : Tout sélectionner

févr. 04 19:14:20 sp systemd-logind[382]: New session 2 of user seb.
févr. 04 19:14:20 sp systemd[1]: home-seb.mount: Directory /home/seb to mount over is not empty, mounting anyway.
févr. 04 19:14:20 sp systemd[1]: Mounting /home/seb...
févr. 04 19:14:21 sp kernel: Key type trusted registered
févr. 04 19:14:21 sp kernel: Key type encrypted registered
févr. 04 19:14:21 sp mount.ecryptfs[459]: Could not open library handle
févr. 04 19:14:21 sp mount[459]: Passphrase: Error attempting to evaluate mount options: [-1] Operation not permitted
févr. 04 19:14:21 sp mount[459]: Check your system logs for details on why this happened.
févr. 04 19:14:21 sp mount[459]: Try updating your ecryptfs-utils package, and/or
févr. 04 19:14:21 sp mount[459]: submit a bug report on https://bugs.launchpad.net/ecryptfs
févr. 04 19:14:21 sp systemd[1]: home-seb.mount: Mount process exited, code=exited, status=255/EXCEPTION
févr. 04 19:14:21 sp systemd[1]: home-seb.mount: Failed with result 'exit-code'.
févr. 04 19:14:21 sp systemd[1]: Failed to mount /home/seb.
févr. 04 19:14:21 sp systemd[1]: Dependency failed for Session 2 of User seb.
févr. 04 19:14:21 sp systemd[1]: session-2.scope: Job session-2.scope/start failed with result 'dependency'.
févr. 04 19:14:21 sp login[434]: pam_systemd(login:session): Failed to create session: Job 810 for unit 'session-2.scope' failed with 'dependency'

Bien sûr c'était à la fin des logs...

Donc apparemment tu as une partition chiffrée que tu essayes de monter par dessus un dossier non vide, mais ceci échoue.
Sans plus d'information de comment cette partition chifrée est montée, difficile d'aider plus

[LunchTime]

Excellent, vraiment, merci beaucoup de prendre le temps =)

Concernant les logs, si, en effet, j'ai modifié LogLevel ... dans un fichier de conf (mais aucun de ceux que tu listes, j'essaie de retrouver où afin de produire les logs allégés)

Ce serait donc au niveau du montage de cette partition cryptée que le problème se poserait.
Cette partition, cryptée avec ecryptfs, contient le home.
Elle est déclarée dans /etc/fstab

Code : Tout sélectionner

/home/seb/.Private/    /home/seb    ecrytpfs rw,user,notauto,exec   .....

Le répertoire
/home/seb
contient un fichier .profile, tel que :

Code : Tout sélectionner

ecryptfs-add-passphrase
mount -i   /home/seb
cd /home/seb

J'avais bricolé ça il y a ... dix ans (!), c'est probablement du bricolage, mais ça a tenu jusqu'à cette récente mise à jour.

Je dois ajouter que, depuis deux ans (à vue de nez)
la séquence :
* login
* startx
ne fonctionnait plus. Il me fallait faire :
* login
* logout
* login
* startx
pour que X se lance.

(C'est peut être sans rapport, mais je le précise au cas où... oui, bricolage =)

[benjarobin]

Hum, je ne pense pas que cela soit la bonne façon de faire... Tu ne devrais pas avoir de ligne dans le fstab (ou tout du moins pas pour chiffrer tout le dossier du home de ton utilisateur).
Je te conseil de sauvegarder ton home quelque part (chiffré ou non chiffré), puis de refaire un nouveau home tel que décrit dans le Wiki : https://wiki.archlinux.org/title/ECrypt ... _directory
Pour que cette méthode fonctionne, il faut juste que le mot de passe de ta session soit le même que la passphrase pour déchiffrer.

Note : Tu devrais envisager de migrer vers https://wiki.archlinux.org/title/Systemd-homed
Note 2: Tu es sûr de ton contenu de ton fstab, car il y a une faute de frappe dans ecryptfs

[LunchTime]

Ca a l'air d'être ça !
J'ai créé, pour tester un autre home (disons "seb2") :
si je me m'y logue just après le boot, X se lance correctement.
Par contre, si je me logue premièrement sur "seb", monte ma partition cryptée, logout, puis logue sur "seb2", alors
dans ce cas X ne démarre même plus.

Il semble donc bien que le noeud du problème soit lié au montage de cette partition, et qu'il me faille réviser la manière dont elle est gérée (et me tourner vers systemd-homed, donc).

Merci d'avoir pris le temps pour dénouer tout cela.

PS : concernant le fstab, j'avais copié à la main d'un écran à l'autre, d'où la faute de frappe

[benjarobin]

Tu n'es pas obligé de migrer vers homed, mais c'est une des méthodes officiellement supportées par systemd. Sinon suivre le wiki de ecryptfs devrait fonctionner en théorie (monter via PAM).
Tu peux essayer avec un utilisateur de test...

[LunchTime]

Je viens en effet de faire un test avec la procédure de migration de home ecryptfs, et cela fonctionne parfaitement. Il ne me reste donc plus qu'à transférer mes données sur un utilisateur créé de cette manière, et ma machine sera à nouveau pleinement opérationnelle.

Merci, cela clôt de manière heureuse ce week-end relativement angoissant !