[Résolu] Journal d’une tentative de résolution d’absence d’affichage graphique
[Résolu] Journal d’une tentative de résolution d’absence d’affichage graphique avatar

Résumé des faits :
(si vous n’avez pas le courage de lire la démarche ci-après)
(je vous suggère néanmoins d’en lire aussi la conclusion en bas de page – riche en informations)

Le 10/10/2016, après la résolution des bugs sur le PC du Bottin, j’ai songé à mettre à jour le PC relié à internet (qui me sert aussi de PC de secours en cas de plantage de celui du Bottin). N’ayant pas été mis à jour depuis près de 2 mois, le nombre de paquets concernés était assez important (grosses mises à jour de KDE, Gnome et MATE). Visiblement la mise à jour était trop grosse pour Synaptic, qui a fini par planter en affichant que certains paquets étaient cassés, ce qui n’était pas le cas. Ce dysfonctionnement étant relativement courant, et facile à résoudre (il suffit de fermer Synaptic puis de le redémarrer et recommencer la sélection), je ne me suis pas inquiété, ai fermé Synaptic et ai tenté de le redémarrer, mais celui-ci a refusé de redémarrer (sur une erreur GtK ; précisons que de nombreux paquets GtK étaient en cours de mise à jour).
Pensant qu’il suffisait de mettre à jour les paquets GtK, j’ai poursuivi l’opération de mise à jour sur ces paquets ainsi que d’autres plus importants via un nouvel outil découvert, dénommé « Outil de mise à jour de paquets » (gtk-update-viewer), puis j’ai redémarré le PC pour m’assurer que les mises à jour correspondantes étaient correctement effectuées.
Au démarrage suivant, l’interface graphique ne démarrait plus du tout (lightdm, kdm, gdm3 et lxdm plantaient).
Finalement, ce n’est que le 16/10/2016, soit 6 jours après, que je suis enfin parvenu à restaurer cette interface graphique.
Après analyse, il semble que le souci venait d’une mauvaise installation de certains paquets précédemment mis à jours (résolu en réinstallant de nombreux paquets manuellement via la commande : « # apt install nomdupaquet »).
Est-ce le fait du plantage de Synaptic (qui aurait laissé certains paquets mal configurés ou mal installés) ou de ce nouvel outil de mise à jour (gtk-update-viewer) : je ne sais pas.
A noter que j’avais aussi lancé les commandes :
# dpkg-reconfigure -a
# apt-get -f install
et elles ne m’avaient pas signalé de paquets laissés non configurés.

—————————————————————————————————————————————————————–

Les faits

Bon, je pensais pouvoir résoudre relativement rapidement le bug conduisant au plantage de Xorg sur le PC internet : je me suis trompé.
J’ouvre un journal pour ordonner mes réflexions sur le sujet ; et si ça peut aider quelqu’un … tant mieux.

Historique des opérations :
Sur le PC relié à internet, après un plantage de synaptic, j’ai tenté de mettre à jour via apt-get et l’ »Outil de mise à jour de paquets » le maximum de paquets en rapport avec nvidia (ma carte graphique), Xorg, le bureau MATE, et les programmes de démarrage (sysvinit, udev, noyau). J’ai ensuite redémarré le système. Celui-ci redémarre bien, et avec de l’internet, mais il plante au démarrage de Xorg : aucune interface graphique, seule la console demeure accessible si l’on démarre en mode sans échec (noyau avec option « recovery mode » sous Grub).

– J’ai bien-sûr tenté une réinstallation du pilote (commande « m-a … », voir plus bas), un « modprobe nvidia » ne m’affiche pas d’erreur,
– j’ai tenté un démarrage sur plusieurs noyaux différents,
– j’ai tenté aussi un démarrage avec lightdm, gdm3 (une catastrophe car il fait clignoter l’écran et bloque le clavier, seul un redémarrage en mode sans échec permet de changer pour un autre gestionnaire de démarrage) et kdm,
– j’ai tenté de remplacer l’utilisation de nvidia dans /etc/X11/xorg.conf par le driver nouveau et même vesa : rien n’y fait, j’obtiens toujours un écran noir avec curseur clignotant.

Un « # dpkg -l | grep nvidia » sur le PC (fonctionnel) du Bottin (avec là aussi une carte graphique nvidia « legacy » de quelques années) m’affiche les paquets nvidia installés :
glx-alternative-nvidia
libegl1-nvidia-legacy-340xx:i386
libgl1-nvidia-legacy-340xx-glx:i386
libgles1-nvidia-legacy-340xx:i386
libgles2-nvidia-legacy-340xx:i386
libnvidia-legacy-340xx-cfg1:i386
libnvidia-legacy-340xx-eglcore:i386
libnvidia-legacy-340xx-glcore:i386
libnvidia-legacy-340xx-ml1:i386
mate-sensors-applet-nvidia
nvidia-installer-cleanup
nvidia-kernel-common
nvidia-legacy-340xx-alternative
nvidia-legacy-340xx-driver
nvidia-legacy-340xx-driver-bin
nvidia-legacy-340xx-driver-libs:i386
nvidia-legacy-340xx-kernel-3.2.0-4-686-pae
nvidia-legacy-340xx-kernel-4.3.0-1-686-pae
nvidia-legacy-340xx-kernel-4.4.0-1-686-pae
nvidia-legacy-340xx-kernel-4.5.0-2-686-pae
nvidia-legacy-340xx-kernel-dkms
nvidia-legacy-340xx-kernel-source
nvidia-legacy-340xx-kernel-support
nvidia-legacy-340xx-vdpau-driver:i386
nvidia-modprobe
nvidia-persistenced
nvidia-settings-legacy-340xx
nvidia-support
xserver-xorg-video-nvidia-legacy-340xx

Pas sûr qu’ils soient tous indispensables, mais bon, ça marche quand ils sont là.
Ca serait bien que ce nombre de paquets soit revu à la baisse, car là c’est vraiment trop.

J’installe et désinstalle sur le PC internet tout ce qui n’est pas dans la liste ci-dessus (en dehors de ceux liés aux noyaux différents).

J’ai donc ajouté :
libnvidia-legacy-340xx-cfg1:i386
nvidia-legacy-340xx-driver
nvidia-legacy-340xx-driver-bin
nvidia-legacy-340xx-driver-libs:i386
nvidia-legacy-340xx-kernel-dkms
nvidia-legacy-340xx-vdpau-driver:i386
nvidia-persistenced

Et enlevé :
libgl1-nvidia-legacy-340xx-glx-i386 (à ne pas confondre avec : libgl1-nvidia-legacy-340xx-glx:i386 ci-dessus)
nvidia-legacy-340xx-smi
nvidia-xconfig

J’ai relancé un : # m-a a-i -f nvidia-legacy-340xx-kernel-source
sur chacun des noyaux du PC internet (pour qu’il créé bien le dernier driver nvidia disponible et remplace éventuellement des liens symboliques défectueux).

Précisons qu’un : # modprobe nvidia
charge le module sans me renvoyer d’erreur.
Et je retrouve bien le module nvidia listé lorsque je lance ensuite la commande : # lsmod

J’ai redémarré, et testé tous les noyaux disponibles avec kdm et lightdm : rien n’y fait, j’ai un écran noir avec un curseur (ou non) et le PC ne répond plus (les Ctrl Alt F1 à F6 ne répondent plus ni le Ctrl Alt Supp pour reseter). Seul moyen de reprendre la main : le redémarrage en mode sans échec.

(Nota à posteriori : kdm et le noyau 3.2.0 sont les seuls éléments qui actuellement ne fonctionnent plus, mais je ne le savais pas à ce moment là)

Je consulte le fichier /var/log/Xorg.0.log :

X.Org X Server 1.18.4
Release Date: 2016-07-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
Current Operating System: Linux goup3 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1 i686

(plusieurs autres lignes d’informations, puis ci-après)

(**) NVIDIA(0) : Enabling 2D acceleration
(II) NVIDIA(0) : Display (Ancor Communications Inc ASUS VK221 (CRT-1)) does not
(II) NVIDIA(0) : support NVIDIA 3D Vision stereo
(II) NVIDIA(0) : Detected PCI Express Link width: 16X
(EE) NVIDIA(0) : EVO Push buffer channel allocation failed
(EE) NVIDIA(0) : Failed to allocate EVO core DMA push buffer

Lors du démarrage suivant avec le noyau 3.2.0 :
l’écran devient noir, je m’attends à voir le logo NVIDIA, puis il clignote en un noir moins profond et je vois un curseur blanc fixe.
Il est de nouveau planté. Au démarrage suivant, le fichier /var/log/Xorg.0.log :
(…)
(tous les paramètres semblent bons, pas d’erreur majeur signalée)
çà se termine par :
(**) NVIDIA(0) : DPMS enabled
(II) Loading sub module « dri2 »
(II) Loadmodule: « dri2 »
(II) Module « dri2 » already built-in
(II) NVIDIA(0) : [DRI2] Setup complete
(II) NVIDIA(0) : [DRI2] VDPAU driver: nvidia
(–) RandR disabled
(II) SELinux: Disabled on system
(II) Initializing extension GLX
(II) Indirect GLX disabled

Et c’est tout ! On dirait que çà marche et pourtant pas d’écran lightdm ni de kdm 🙁

(Nota à posteriori : il est vraisemblable qu’à ce moment si j’avais testé un autre noyau avec un autre gestionnaire de démarrage, çà aurait marché)

Je retente une mise à jour des paquets avec un :
# apt-get update
# apt-get upgrade

Sans trop y croire (vu les mises à jour disponibles, qui semblent en rapport avec Gnome mais pas avec Xorg ni nvidia) …
Un forum très intéressant sur le sujet : sur Archlinux.
J’y apprend (merci aux participants) que KMS n’est utilisé que par le driver nouveau et pas par le driver propriétaire nvidia

Je vais retenter le driver « nouveau » pour voir :
Avec le driver « nouveau », j’ai le fond noir avec un curseur clignotant et je peux accéder aux autres consoles via un Ctrl Alt xx.
C’est un peu mieux, mais toujours pas de lightdm. Idem avec le driver « vesa ».

(Nota à posteriori : le driver nouveau était blacklisté par /etc/modeprobe.d/nvidia-blacklists-nouveau.conf)

Je reprend mon driver nvidia (sous Xorg).

Je regarde à nouveau le fichier /var/log/Xorg.0.log :
(EE) Screen 0 deleted because of no matching config section.
(II) UnloadModule: « vesa »
(EE) Device(s) detected, but none match those in the config file

Pourtant mon fichier /etc/X11/xorg.conf fonctionnait avec le driver nvidia et je ne l’ai pas modifié :

(Nota à posteriori : j’ai à présent repris ce fichier pour enlever la section « Device » devenue inutile, voir en bas de ce journal)

Section « Device »
Identifier « Carte graphique »
Driver « nvidia »
# Driver « nouveau »
# Driver « vesa »
EndSection

Section « Monitor »
Identifier « Ecran »
Option « DPMS »
EndSection

Section « Screen »
Identifier « Affichage »
Device « Carte graphique »
Monitor « Ecran »
EndSection

Section « ServerLayout »
Identifier « Default Layout »
Screen « Affichage »
EndSection

J’ai le même (avec quelques paramètres supplémentaires liés à ma tablette graphique) sur le PC du Bottin et çà fonctionne bien (avec le driver nvidia).

Suivant un exemple de fichier xorg.conf trouvé sur un forum, j’ai un peu modifié mon fichier en :
Section « ServerLayout »
Identifier « Default Layout »
Screen 0 « Affichage »
EndSection
(j’ai ajouté le chiffre 0, correspondant au 1er écran trouvé je pense)

Et relancé la commande X
J’ai toujours un curseur blanc sur fond noir.
Le fichier /var/log/Xorg.0.log :
(II) LoadModule: « glx »
(II) Loading /usr/lib/xorg/modules/linux/libglx.so
(II) module glx: vendor= »NVIDIA Corporation »
(II) NVIDIA GLX Module 340.98 …
(II) Module nouveau: vendor= »X.Org Foundation »
(…) (ça semble fonctionner, jusqu’à la ligne)
(EE) [drm] Failed to open DRM device for (null):22
(EE) [drm] Failed to open DRM device for pci:0000:03:00.0: -22
(EE) No devices detected.
(EE)
Fatal server error:
(EE) no screens found(EE)

Pénible
J’arrête là pour ce soir 12/10/2016 🙁

————————————————————————————-

Reprise le 13/10/2016

Pas beaucoup de temps ce soir pour regarder ce problème.

Je viens de mettre à jour une nouvelle fois le PC relié à internet par un :
# apt-get update
# apt-get upgrade

Juste au cas où. Mais là aussi peu d’espoir puisque aucun paquet ne concernant le driver nvidia ou xorg.
Et après un redémarrage je suis toujours avec mon écran noir et le curseur blanc en haut à gauche de l’écran …

L’idée, sur le peu de temps qu’il me reste (1h environ), est de tester un autre noyau.

Petit aparté :
J’ai de l’internet et une interface graphique sur le PC du Bottin, mais je ne me consacrerai à nouveau au Bottin des Jeux Linux que lorsque les 2 PC seront opérationnels, car je tiens à toujours garder un PC de secours opérationnel.
De même je ne mettrai à jour le PC du Bottin que lorsque le PC internet sera réparé (pour éviter de me retrouver avec 2 PC plantés).

Actuellement les noyaux installés et testé sur le PC internet sont :
4.4.0-1-686-pae
4.3.0-1-686-pae
3.2.0-4-686-pae

Pourquoi installer un nouveau noyau ?
1. le nouveau driver nvidia et les autres mises à jour pourraient peut-être utiliser une nouvelle fonction du noyau ?
Peu probable, mais bon.
2. Lors de la mise à jour précédent le crash, il me semble bien avoir aperçu la désinstallation d’un noyau précédent, par le jeu des dépendances. Mais je ne suis pas sûr. Et je ne suis pas sûr non plus que tous les noyaux déjà installés fonctionnaient avec Xorg. Il y a une petite chance pour que le seul qui fonctionnait était celui qui aurait été désinstallé.

En regardant synaptic sous le PC du Bottin – qui lui, dispose d’une interface graphique et de l’internet via le PC internet (qui le lui redistribue), je vois que le dernier noyau disponible dans les dépôts Debian Sid est le 4.7.0.
Mon choix se porte plus précisément sur le : 4.7.0-1-grsec-686-pae
« Linux kernel 4.7.0-1-grsec-686-pae, generally used for building out-of-tree kernel modules ».
Il me parait pas mal.
(Nota à posteriori : mauvais choix, il est buggé)

Donc :
# apt-get install linux-headers-4.7.0-1-grsec-686-pae
# apt-get install linux-image-4.7.0-1-grsec-686-pae

Ensuite je redémarre dessus, pour pouvoir installer mon driver nvidia.
Par curiosité je démarre en mode normal, évidemment il ne démarre pas l’interface graphique, mais il me laisse la main sur une autre console (Ctrl Alt Fn) pour compiler mon driver nvidia par la commande :
# m-a a-i -f nvidia-legacy-340xx-kernel-source

Sauf que la compilation s’interrompt sur la fenêtre :
« La construction du paquet nvidia-legacy-340xx-kernel-source a échoué. Que souhaitez-vous faire ? »
J’examine le journal de construction :
make[3] : *** Aucune règle pour fabriquer la cible  » scripts/Makefile.gcc-plugins ». Arrêt
plus quelques autres messages qui en découlent.

Je l’ai relancé une 2nde fois l’histoire de voir s’il y avait des différences de messages, mais non.
Donc pour l’instant on oublie cette variante du noyau.

D’autant que je reçois en parallèle des messages alarmant du type :
EXT4-fs (sda2) : unable to read superblock
FAT-fs (sda2) : bogus number of reserved sectors
ufs : You didn’t specify the type of your ufs filesystem

Il me paraît bien foireux ce noyau 🙂

# apt-get install linux-headers-4.7.0-1-686-pae
# apt-get install linux-image-4.7.0-1-686-pae

Ensuite je redémarre dessus, relance la compilation de mon driver nvidia dessus :
# m-a a-i -f nvidia-legacy-340xx-kernel-source

Celui là me permet de compiler mon driver nvidia sans problème.
Un : # modprobe nvidia
ne m’affiche aucune erreur, donc au moins le module nvidia se charge sans râler.
Je tente un /etc/init.d/lightdm restart
Bon il plante lui aussi, avec un message que je n’ai pas eut le temps de lire.
Après un reboot, je vais ré-examiner /var/log/Xorg.0.log :
# nano /var/log/Xorg.0.log

Il y a quelques messages (dans la longue liste de messages) qui attirent mon attention :
(II) LoadModule: « glx »
(II) Loading /usr/lib/xorg/modules/linux/libglx.so
(II) Module glx: vendor= »NVIDIA Corporation »
compiled for 4.0.2, module version = 1.0.0
module class: X.Org Server Extension
(II) NVIDIA GLX Module 340.98 Mon Sep 19 17:08:03 PDT 2016
(II) LoadModule: « nvidia »
(II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
(II) Module nvidia: vendor= »NVIDIA Corporation »
compiled for 4.0.2, module version = 1.0.0
module class: X.Org Video Driver
(II) NVIDIA dlloader X Driver 340.98 Mon Sep 19 16:47:17 PDT 2016
(II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

(Nota à posteriori : çà aurait pu marcher, mais visiblement il y avait un souci avec DBus, résolu par une réinstallation de plusieurs paquets)

Je me demande si au travers de tous ces paquets nvidia, il n’y en aurait pas un, générique, qui m’installerait un driver nvidia, générique et foireux, qui serait utilisé en lieu et place de celui que je m’évertue à compiler.

(Nota à posteriori : non finalement çà n’était pas le cas)

J’ai déjà rencontré ce souci il y a quelques années. J’avais passé un bon bout de temps à chercher pourquoi mon driver ne fonctionnait pas, alors que le souci venait tout simplement d’un lien dynamique installé par un paquet (à l’utilité douteuse) qui dévoyait l’utilisation du driver vers un driver générique qui ne fonctionnait pas.

Le log se termine encore une fois par :
(II) NVIDIA(0) : Detected PCI Express Link width: 16X
(EE) NVIDIA(0) : EVO Push buffer channel allocation failed
(EE) NVIDIA(0) : Failed to allocate EVO core DMA push buffer

A suivre … (demain ? sinon samedi)

————————————————————————————-

Reprise le 15/10/2016

En réponse à la question que je me posais il y a 2 jours :
lors de la grosse mise à jour de ce PC, les noyaux 4.6.0-1-686-pae et 4.6.0-1-rt-686-pae ont vraisemblablement été désinstallés, puisque je trouve encore via un « dpkg -l | grep nvidia les drivers :
nvidia-legacy-340xx-kernel-4.6.0-1-686-pae
nvidia-legacy-340xx-kernel-4.6.0-1-rt-686-pae
A moins qu’ils aient été désinstallés encore avant, mais je ne crois pas.

Relisant une de mes docs précédentes, je lance successivement :
# apt-get install –reinstall xserver-xorg-video-nvidia-legacy-340xx
# m-a a-i -f nvidia-legacy-340xx-kernel-source
Ca ne fonctionne pas mieux.

Je tente autre chose :

Le paquet glx-alternative-nvidia (précédemment installé) fournit (doc du paquet Debian) la commande update-glx :

allows the selection of NVIDIA as GLX provider

« In setups with several GLX providers (e.g. the free MESA implementation and proprietary graphics hardware vendor implementations) this metapackage allows one to switch to the non-free NVIDIA driver and libraries.
Use ‘update-alternatives –config glx’ to select an implementation.
This package does not depend on the corresponding NVIDIA libraries. In order to install the NVIDIA driver and libraries, install the nvidia-driver package instead ».

# update-glx –help
Un utilitaire de configuration des alternatives glx et nvidia
# update-glx –config glx
Il existe 3 choix pour l’alternative glx (qui fournit /usr/lib/glx).

Sélection Chemin Priorité État
————————————————————
* 0 /usr/lib/nvidia 100 mode automatique
1 /usr/lib/mesa-diverted 5 mode manuel
2 /usr/lib/nvidia 100 mode manuel
3 /usr/lib/nvidia/bumblebee 95 mode manuel

Appuyez sur [entrée] pour conserver la valeur par défaut[*] ou choisissez le numéro sélectionné :0
Traitement des actions différées (« truggers ») pour glx-alternative-nvidia (0.7.4) …
Traitement des actions différées (« truggers ») pour update-glx (0.7.4) …
Traitement des actions différées (« truggers ») pour glx-alternative-nvidia (0.7.4) …
Traitement des actions différées (« truggers ») pour libc-bin (2.24-3) …
Traitement des actions différées (« truggers ») pour initramfs-tools (0.125) …

Si j’interprète correctement ce que je lis, je n’ai fait que reconfigurer que ce qui était déjà configuré par défaut. Néanmoins je préfère le faire une 2nde fois au cas où la fois précédente quelque-chose ce serait mal passé (interrompu en cours de configuration à cause du plantage de synaptic par exemple).

Je creuse un peu et tombe sur ce forum superuser.com qui m’a l’air très intéressant.
Je lance un : # update-alternatives –display glx
glx – mode automatique
link best version is /usr/lib/nvidia
le lien pointe actuellement sur /usr/lib/nvidia
link glx is /usr/lib/glx
slave glx–libEGL.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libEGL.so.1
(…)

A noter que la même commande lancée sur le PC du Bottin me donne les mêmes résultat (que j’ai recopié ci-dessus depuis la console).

Je lance sur les 2 PC la même commande suivante, afin de comparer les résultats :

# update-alternatives –display nvidia
nvidia – mode automatique
link best version is /usr/lib/nvidia/legacy-340xx
le lien pointe actuellement sur /usr/lib/nvidia/legacy-340xx
link nvidia is /usr/lib/nvidia/nvidia
slave nvidia–libEGL.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/nvidia/libEGL.so.1
slave nvidia–libGL.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/nvidia/libGL.so.1
slave nvidia–libGLESv1_CM.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
slave nvidia–libGLESv2.so.2-i386-linux-gnu is /usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
slave nvidia–libglx.so is /usr/lib/nvidia/libglx.so
slave nvidia–libnvidia-cfg.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
slave nvidia–libnvidia-ml.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/libnvidia-ml.so.1
slave nvidia–libvdpau_nvidia.so.1-i386-linux-gnu is /usr/lib/i386-linux-gnu/vdpau/libvdpau_nvidia.so.1
slave nvidia–monitoring.conf is /usr/share/nvidia/monitoring.conf
slave nvidia–nv-control-dpy is /usr/bin/nv-control-dpy
slave nvidia–nvidia-blacklists-nouveau.conf is /etc/nvidia/nvidia-blacklists-nouveau.conf
slave nvidia–nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh
slave nvidia–nvidia-debugdump is /usr/bin/nvidia-debugdump
slave nvidia–nvidia-drm-outputclass.conf is /etc/nvidia/nvidia-drm-outputclass.conf
slave nvidia–nvidia-load.conf is /etc/nvidia/nvidia-load.conf
slave nvidia–nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf
slave nvidia–nvidia-settings is /usr/bin/nvidia-settings
slave nvidia–nvidia-settings.1.gz is /usr/share/man/man1/nvidia-settings.1.gz
slave nvidia–nvidia-settings.desktop is /usr/share/applications/nvidia-settings.desktop
slave nvidia–nvidia_drv.so is /usr/lib/nvidia/nvidia_drv.so
/usr/lib/nvidia/legacy-340xx – priorité 340
lien secondaire nvidia–libEGL.so.1-i386-linux-gnu : /usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libEGL.so.1
lien secondaire nvidia–libGL.so.1-i386-linux-gnu : /usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libGL.so.1
lien secondaire nvidia–libGLESv1_CM.so.1-i386-linux-gnu : /usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libGLESv1_CM.so.1
lien secondaire nvidia–libGLESv2.so.2-i386-linux-gnu : /usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libGLESv2.so.2
lien secondaire nvidia–libglx.so : /usr/lib/nvidia/legacy-340xx/libglx.so
lien secondaire nvidia–libnvidia-cfg.so.1-i386-linux-gnu : /usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libnvidia-cfg.so.1
lien secondaire nvidia–libnvidia-ml.so.1-i386-linux-gnu : /usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libnvidia-ml.so.1
lien secondaire nvidia–libvdpau_nvidia.so.1-i386-linux-gnu : /usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libvdpau_nvidia.so.1
lien secondaire nvidia–monitoring.conf : /usr/lib/nvidia/legacy-340xx/monitoring.conf
lien secondaire nvidia–nv-control-dpy : /usr/lib/nvidia/legacy-340xx/nv-control-dpy
lien secondaire nvidia–nvidia-blacklists-nouveau.conf : /etc/nvidia/legacy-340xx/nvidia-blacklists-nouveau.conf
lien secondaire nvidia–nvidia-bug-report.sh : /usr/lib/nvidia/legacy-340xx/nvidia-bug-report.sh
lien secondaire nvidia–nvidia-debugdump : /usr/lib/nvidia/legacy-340xx/nvidia-debugdump
lien secondaire nvidia–nvidia-drm-outputclass.conf : /etc/nvidia/legacy-340xx/nvidia-drm-outputclass.conf
lien secondaire nvidia–nvidia-load.conf : /etc/nvidia/legacy-340xx/nvidia-load.conf
lien secondaire nvidia–nvidia-modprobe.conf : /etc/nvidia/legacy-340xx/nvidia-modprobe.conf
lien secondaire nvidia–nvidia-settings : /usr/lib/nvidia/legacy-340xx/nvidia-settings
lien secondaire nvidia–nvidia-settings.1.gz : /usr/lib/nvidia/legacy-340xx/nvidia-settings.1.gz
lien secondaire nvidia–nvidia-settings.desktop : /usr/lib/nvidia/legacy-340xx/nvidia-settings.desktop
lien secondaire nvidia–nvidia_drv.so : /usr/lib/nvidia/legacy-340xx/nvidia_drv.so

J’ai strictement le même résultat.

# update-glx –config nvidia

En lisant la ligne « nvidia-blacklists-nouveau.conf » ci-dessus, et en fouillant dans /etc/, je trouve d’autres trucs intéressants :
Dans /etc/modprobe.d/ :
un lien dynamique dénommé : nvidia-blacklists-nouveau.conf
pointant vers /etc/alternatives/glx–nvidia-blacklists-nouveau.conf
et dans ce fichier je trouve :
# You need to run « update-initramfs -u » after editing this file.

# see #580894
blacklist nouveau

Ca m’étonne moins que le driver nouveau ne fonctionne pas, puisqu’il semble être blacklisté ici. Mais pourquoi ? Incompatibilité entre ce driver et celui de nvidia ? Peut-être. Une autre piste à creuser (celle de supprimer ce blacklist et de lancer le driver nouveau).
Sinon, il y a d’autres fichiers nvidia dans /etc/modprobe.d/ qui pourraient être d’autres pistes à creuser.

Finalement je teste immédiatement :
je renomme le fichier nvidia-blacklists-nouveau.conf en nvidia-blacklists-nouveau.conf-old
j’édite le fichier /etc/X11/xorg.conf et remplace le driver nvidia par nouveau et relance Xorg (# /etc/init.d/lightdm restart)
Ca plante une nouvelle fois, mais j’ai accès aux autres consoles. J’édite le fichier /var/log/Xorg.0.log
Une nouvelle fois, je trouve les lignes (en fin de fichier) :
(EE) [drm] Failed to open DRM device for (null):22
(EE) [drm] Failed to open DRM device for pci:0000:03:00.0: -22
(EE) No devices detected.
(EE)
Fatal server error:
(EE) no screens found(EE)

Ca ne fonctionne pas mieux, je reprend le driver nvidia (modif du fichier de conf de Xorg).
Pfff…

J’explore de nouveau la piste du noyau :

Actuellement les noyaux installés et testé sur le PC internet sont :
4.4.0-1-686-pae
4.3.0-1-686-pae
3.2.0-4-686-pae
4.7.0-1-686-pae (le dernier installé)

Suivant mes précédents drivers installés :
nvidia-legacy-340xx-kernel-4.6.0-1-686-pae
nvidia-legacy-340xx-kernel-4.6.0-1-rt-686-pae

J’installe les entêtes et noyaux correspondants :
# apt-get install linux-headers-4.6.0-1-rt-686-pae
# apt-get install linux-headers-4.6.0-1-686-pae (déjà installé)
# apt-get install linux-image-4.6.0-1-rt-686-pae
# apt-get install linux-image-4.6.0-1-686-pae

Je reboot en mode sans échec (recovery mode sous Grub) sur le noyau linux-image-4.6.0-1-rt-686-pae
et lance la compilation du module nvidia correspondant avec : # m-a a-i -f nvidia-legacy-340xx-kernel-source
Puis je retente de démarrer Xorg : # X
Ca plante encore. Au redémarrage suivant je consulte à nouveau le log de Xorg :
(j’ai recopié un extrait de celui du Bottin, qui est en cours d’utilisation puisque je saisi ce message en l’utilisant, les messages sont les mêmes, sauf pour les entêtes de temps évidemment)

[ 34.106] (II) NVIDIA: Using 768.00 MB of virtual memory for indirect memory access.
[ 34.108] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
[ 34.108] (II) NVIDIA(0): may not be running or the « AcpidSocketPath » X
[ 34.108] (II) NVIDIA(0): configuration option may not be set correctly. When the
[ 34.108] (II) NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will
[ 34.108] (II) NVIDIA(0): try to use it to receive ACPI event notifications. For
[ 34.108] (II) NVIDIA(0): details, please see the « ConnectToAcpid » and
[ 34.109] (II) NVIDIA(0): « AcpidSocketPath » X configuration options in Appendix B: X
[ 34.109] (II) NVIDIA(0): Config Options in the README.
[ 34.109] (II) NVIDIA(0): Setting mode « DFP-1:nvidia-auto-select,DFP-0:nvidia-auto-select »
[ 34.922] (==) NVIDIA(0): Disabling shared memory pixmaps
[ 34.922] (==) NVIDIA(0): Backing store enabled
[ 34.922] (==) NVIDIA(0): Silken mouse enabled
[ 34.923] (**) NVIDIA(0): DPMS enabled
[ 34.924] (II) Loading sub module « dri2 »
[ 34.924] (II) LoadModule: « dri2 »
[ 34.924] (II) Module « dri2 » already built-in
[ 34.924] (II) NVIDIA(0): [DRI2] Setup complete
[ 34.924] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia
[ 34.924] (–) RandR disabled
[ 34.932] (II) SELinux: Disabled on system
[ 34.934] (II) Initializing extension GLX
[ 34.934] (II) Indirect GLX disabled.

Les messages affichés dans les logs Xorg du PC du Bottin et dans ceux du PC internet étant les mêmes, tout ceci m’amène à penser que l’interface graphique fonctionne, mais que le souci vient du gestionnaire lightdm et kdm (aucun des 2 ne parvient à fonctionner).
Bizarre cette histoire … (vous avez dit bizarre ? comme c’est bizarre 🙂 )

(Nota à posteriori : l’accélération graphique devait être opérationnelle, mais les interfaces graphiques refusaient de fonctionner vraisemblablement à cause d’un souci avec DBus – résolu en réinstallant une série de paquets vraisemblablement mal installés)

Il doit bien y avoir un fichier log pour lightdm quelque-part …
# cd /var/log/lightdm
# nano lightdm.log

Il y a peu de lignes et je ne vois pas d’erreur en dehors d’une ligne (qui n’est pas la dernière) :
[+0.01s] DEBUG: Could not run plymouth –ping: Failed to execute child process « plymouth » (No such file or directory)
(à noter que sur le PC du Bottin, fonctionnel, plymouth n’est pas installé non plus)

Ayant désinstallé lightdm sur le PC du Bottin (car j’avais eut précédemment des soucis avec lui), je n’ai pas d’éléments de comparaison. Sur le PC du Bottin j’utilise kdm actuellement. Mais kdm plante lui aussi sur le PC internet.

(Nota à posteriori : je viens de réinstaller lightdm sur le PC du Bottin et il semble à présent à nouveau bien fonctionner. Quant à kdm, il ne fonctionne pour l’instant plus sur le PC internet, peut-être est-ce lié à un souci avec des paquets KDE – qui est en pleine mutation).

Sur le PC internet il y a aussi un fichier /var/log/lightdm.log.old d’un horodatage identique (il est donc aussi récent) qui, lui, est nettement plus loquace.
J’y trouve entre-autres messages :
[+0.91s] DEBUG: Seat seat0: Creating greeter session
[+0.91s] DEBUG: Seat seat0: Creating display server of type x
[+0.91s] DEBUG: Could not run plymouth –ping: Failed to execute child process « plymouth » (No such file or directory)
[+0.91s] DEBUG: Using VT 7
[+0.91s] DEBUG: Seat seat0: Starting local X display on VT 7
(…)
[+0.91s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0
[+5.60s] DEBUG: Loading users from org.freedesktop.Accounts
(les lignes se suivent, notez l’écart de temps ci-dessus)
[+5.60s] DEBUG: User /org/freedesktop/Accounts/Userxxxx added
[+5.61s] DEBUG: User /org/freedesktop/Accounts/Userxxxy added
(j’ai masqué volontairement les n° d’utilisateurs, en les remplacant par xxxx et xxxy)
[+7.69s] DEBUG: Process 2096 terminated with signal 11
[+7.69s] DEBUG: DisplayServer x-0: X server stopped
[+7.69s] DEBUG: Releasing VT 7
[+7.69s] DEBUG: DisplayServer x-0: Removing X server authority /var/run/lightdm/root:0
[+7.69s] DEBUG: Seat seat0: Display server stopped
[+7.69s] DEBUG: Seat seat0: Stopping; greeter display server failed to start
[+7.69s] DEBUG: Seat seat0: Stopping
[+7.69s] DEBUG: Seat seat0: Stopping session
(…)
Visiblement il y a un truc qui se passe mal, en rapport avec le Process 2096.
C’est clair non ? 🙂

Une petite recherche sur le net :
« Signal 11, or officially know as « segmentation fault », means that the program accessed a memory location that was not assigned ».

Tout ceci m’amène à penser qu’il y aurait peut-être un souci du côté du serveur Xorg ?

Un dernier test avant : celui du noyau 4.6.0-1-686-pae (j’avait fais précédemment mes tests sur le 4.6.0-1-rt-686-pae)
Je démarre dessus, compile le driver nvidia, et lance Xorg
Même résultat : ça plante sans possibilité de réutiliser une autre console.

Je vais donc me concentrer à présent sur la vérification / réinstallation des paquets Xorg.

# dpkg -l | grep xserver
ii x11-xserver-utils 7.7+7 i386 X server utilities
ii xserver-common 2:1.18.4-2 all common files used by various X servers
ii xserver-xephyr 2:1.18.4-2 i386 nested X server
ii xserver-xorg 1:7.7+16 i386 X.Org X server
ii xserver-xorg-core 2:1.18.4-2 i386 Xorg X server – core server
(…)
Plus d’autres paquets, différents de ceux du PC du Bottin.
Pour plus de simplicité, je commence par rapprocher les configurations en désinstallant / réinstallant tout ce qui diffère de celui du Bottin (ci-dessous la liste des paquets installés sur le Bottin) :

# dpkg -l | grep xserver
ii x11-xserver-utils 7.7+7 i386 X server utilities
ii xserver-common 2:1.18.4-2 all common files used by various X servers
ii xserver-xephyr 2:1.18.4-2 i386 nested X server
ii xserver-xorg 1:7.7+16 i386 X.Org X server
ii xserver-xorg-core 2:1.18.4-2 i386 Xorg X server – core server
ii xserver-xorg-dev 2:1.18.4-2 i386 Xorg X server – development files
ii xserver-xorg-input-evdev 1:2.10.3-1 i386 X.Org X server — evdev input driver
ii xserver-xorg-input-kbd 1:1.8.1-1+b1 i386 X.Org X server — keyboard input driver
ii xserver-xorg-input-mouse 1:1.9.1-1+b1 i386 X.Org X server — mouse input driver
ii xserver-xorg-input-synaptics 1.8.3-2 i386 Synaptics TouchPad driver for X.Org server
ii xserver-xorg-input-wacom 0.30.0-1+b1 i386 X.Org X server — Wacom input driver
ii xserver-xorg-video-cirrus 1:1.5.3-1+b1 i386 X.Org X server — Cirrus display driver
ii xserver-xorg-video-fbdev 1:0.4.4-1+b4 i386 X.Org X server — fbdev display driver
ii xserver-xorg-video-intel 2:2.99.917+git20160706-1 i386 X.Org X server — Intel i8xx, i9xx display driver
ii xserver-xorg-video-nouveau 1:1.0.13-1 i386 X.Org X server — Nouveau display driver
ii xserver-xorg-video-nvidia-legacy-340xx 340.98-1 i386 NVIDIA binary Xorg driver (340xx legacy version)
ii xserver-xorg-video-vesa 1:2.3.4-1+b1 i386 X.Org X server — VESA display driver

# apt-get remove –purge xserver-xorg-input-all
# apt-get install xserver-xorg-dev
# apt-get remove –purge xserver-xorg-input-joystick
# apt-get remove –purge xserver-xorg-input-libinput
# apt-get remove –purge xserver-xorg-input-vmmouse
(je n’installe pas la wacom puisque je n’en ai pas sur le PC internet)
# apt-get remove –purge xserver-xorg-video-all
# apt-get remove –purge xserver-xorg-video-amdgpu
# apt-get remove –purge xserver-xorg-video-ati
(je n’ai pas installé la cirrus ni la intel, je n’en ai pas)
# apt-get remove –purge xserver-xorg-video-radeon
# apt-get remove –purge xserver-xorg-video-vmware

Voilà, il ne me reste que :
x11-xserver-utils
xserver-common
xserver-xephyr
xserver-xorg
xserver-xorg-core
xserver-xorg-dev
xserver-xorg-input-evdev
xserver-xorg-input-kbd
xserver-xorg-input-mouse
xserver-xorg-input-synaptics
xserver-xorg-video-fbdev
xserver-xorg-video-nouveau
xserver-xorg-video-nvidia-legacy-340xx
xserver-xorg-video-vesa

Je relance l’installation des paquets principaux ci-dessus :
# apt-get install –reinstall xserver-common xserver-xephyr xserver-xorg xserver-xorg-core xserver-xorg-input-evdev xserver-xorg-video-fbdev xserver-xorg-video-vesa

Et pour être sûr, je relance la compilation du module nvidia : # m-a a-i -f nvidia-legacy-340xx-kernel-source
Je retente de démarrer Xorg : # /etc/init.d/lightdm restart
Idem. Ca plante 🙁

Je redémarre, cette fois-ci sur le noyau 4.7.6-1 et regarde les fichiers de log :
Xorg.0.log me semble sans anomalie majeure

Ayant changé de noyau, pour être sûr, je relance la compilation du module nvidia : # m-a a-i -f nvidia-legacy-340xx-kernel-source
Puis je teste à nouveau les différents gestionnaires de lancement de Xorg :
gdm3 :
[….] Reloading gdm3 configuration (via systemctl): gdm3.servicegdm.service is not active, cannot reload.
failed!
:))
xdm :
[ ok ] Reloading X display manager configuration…: not running..
:))
And last, but not least :
kdm :
dès que je lance un dpkg-reconfigure lightdm et que je sélectionne kdm comme manager par défaut, j’obtiens :
Please be sure to run « dpkg –configure kdm ».
dbus.service is not active, cannot reload.
invoke-rc.d: initscript dbus, action « reload » failed.
ERROR: /lib/systemd/system/kdm.service is the selected default display manager but does not exist

Il y a des jours où (xxx=autocensure) xxxx xxxxx xxxx xxxxxx, ma patience est mise à rude épreuve 🙂
xxxxxxx
le x ne compte pas pour un caractère 🙂

# dpkg –configure kdm
dpkg: erreur de traitement du paquet kdm (–configure) :
le paquet kdm est déjà installé et configuré
Des erreurs ont été rencontrées pendant l’exécution :
kdm

Je pense être patient. Voir perspicace. Mais là, mon Linux abuse 🙂
Les messages ne sont pas adaptés. S’il est configuré et installé : en quoi est-ce une erreur ?

Je crois que je vais arrêter pour ce soir / aujourd’hui, avant qu’il ne passe par la fenêtre 🙂

Allez encore quelques idées :
# apt-get install –reinstall kdm
La réinstallation de kdm est impossible, il ne peut pas être téléchargé.

Tiens, c’est nouveau çà. Il est pourtant dans les dépôts.

# apt-get install –reinstall gdm3
# apt-get install ldm lxdm
Tiens tiens, lors du paramétrage de lxdm je remarque là aussi un message (auquel je n’avais pas prêté attention pour kdm) :
dbus.service is not active, cannot reload.
invoke-rc.d: initscript dbus, action « reload » failed.
(…)

Une piste …

# apt-get install –reinstall dbus dbus-user-session dbus-x11 dleyna-renderer dleyna-server libdbus-1-3 libdbus-glib-1-2
Il y en a plein d’autres (trouvés via un filtre « dbus » sous synaptic du PC du Bottin), mais ceux-ci me semblent de bons candidats.

Je redémarre (en mode sans échec sur le noyau 4.7) pour un dernier test.
Puis je lance :
dpkg-reconfigure lxdm
je sélectionne lxdm
dbus.service is not active, cannot reload.
invoke-rc.d: initscript dbus, action « reload » failed.

Déjà là ça ne semble pas bon, çà laisse présager de la suite.
# /etc/init.d/lxdm restart
écran noir.
Visiblement il faut que je trouve d’où vient ce problème avec dbus …

Rien à voir, mais pour mon souci de transmission internet :
8139too 0000:08:06.0 eth2: link down
IPv6: ADDRCONF (NETDEV_UP): eth2: link is not ready
En fonction des démarrages, je vois aussi les messages :
eth0: no IPv6 routers present
eth1: no IPv6 routers present

N’ayant plus d’internet sur le PC du Bottin (à chaque démarrage, le réseau est remis en question, néanmoins il reste très fiable lorsque le PC du Bottin disposait déjà de l’internet et que je ne le reboot pas tandis que je reboot celui distribuant internet), je teste le noyau 4.6.0-rt, qui m’affiche pas mal d’erreurs : à virer.
# apt-get remove –purge linux-image-4.6.0-1-rt-686-pae

À suivre : pourquoi y a t-il un souci avec Dbus sur le PC internet …

(Nota à posteriori : il semble que c’était dû à la mauvaise installation de paquets liés à DBus, une série de réinstallation de paquets listés ci-après, semble être à l’origine de la résolution du problème).

Autre piste :
# journalctl
(…)
systemd-udevd [293]: failed to execute ‘/lib/udev/socket:@/org/freedesktop/hal/udev_event’ ‘socket:@/org/freedesktop/hal/udev_event’ : No such file or directory
systemd-udevd [288]: Process ‘socket:@/org/freedesktop/hal/udev_event’ failed with exit code 2.
(le message est répété un très grand nombre de fois)
systemd-udevd [401]: Process ‘/lib/udev/hdparm’ failed with exit code 5.
(…)
systemd [1]: dbus.service: Unit cannot be reloaded because it is inactive.
systemd [1]: gdm.service: Unit cannot be reloaded because it is inactive.

————————————————————————————-

Reprise le 16/10/2016

Me revoilà, frais, dispo, calmé, avec encore une journée disponible pour un sacrifice sur l’autel de la liberté, de la passion et du savoir 🙂
C’est vrai qu’on y prend goût à la longue (là je ne blague pas).

Encore un :
# apt update
# apt upgrade
Je note la disponibilité à la mise à jour d’un paquet nvidia : nvidia-persistenced
mais vu sa description, çà ne devrait pas changer grand-chose. De toute façon mon problème semble provenir d’un blocage de dbus à priori, voir d’un souci avec udev, hal, systemd (que des trucs que je maîtrise encore moins 🙂 ).

J’admire en ce moment la mise à jour en console de l’apt upgrade, avec son barregraphe de « # » sur l’avancement de l’installation, et son avancement exprimé simultanément sur fond vert : du plus bel effet (là non plus je ne plaisante pas, je suis sincère).
Voilà il a fini. Je le redémarre.

Je choisi le noyau 4.7.0 en mode sans échec.
A tout hasard (mais je n’y crois pas)
dpkg-reconfigure lxdm
je sélectionne lxdm
dbus.service is not active, cannot reload.
invoke-rc.d: initscript dbus, action « reload » failed.

Je ne vais pas plus loin. Je vais faire une petite recherche sur le sujet sur le net.

1ere remarque (bon, elle est un peu longue) : le moteur de recherche.
j’ai pris pour habitude d’utiliser par défaut le métamoteur DuckDuckGo pour sa politique de confidentialité qui me plaît.
Si je saisi : « dbus.service is not active, cannot reload. » (avec les guillemets verticales ou « Anglaises », qui rendent en « français » sur ce blog)
J’ai le droit à un :
No more results. Try:
dbus.service is not active, cannot reload.

Si je saisi : lxdm dbus.service is not active, cannot reload. (donc sans les guillemets)
La plupart des 1eres réponses sont en rapport avec DNS, ce qui n’est pas l’objet ici.
La 2nde réponse concerne Freedesktop, c’est une doc sur systemd, c’est moins mauvais mais bof bof.
Je pense qu’un moteur de recherche, ou un métamoteur de recherche doit pouvoir faire mieux, c’est son job.

Même recherche sur Google :
Si je saisi : « dbus.service is not active, cannot reload. »
Les résultats sont beaucoup mieux cernés

Je note que si je modifie la phrase en : lxdm dbus.service is not active, cannot reload.
Sur DuckDuckGo ça s’améliore nettement, mais ça me semble nettement moins bon.

Mon impression quant aux résultats obtenus :
DuckDuckGo renvoi davantage vers des sites de documentations
Google renvoi vers des forums avec des résolutions de problèmes. C’est exactement ce qu’on recherche lorsque l’on saisi ce type de phrase.

On est un amateur, on a bien vu qu’il y a des millions de tonnes de docs plus ou moins pompeuses, plus ou moins explicites, plus ou moins à jour (ma distrib évolue tous les jours, çà ne doit pas être facile de suivre), avec des millions de liens renvoyant vers des millions d’autres docs. Elles sont indispensables lorsque l’on veut approfondir ses connaissances sur un sujet donné. Mais dans le cas présent, on n’est pas là pour prendre un cour théorique sur l’administration des systèmes Unix mais pour tenter de résoudre ce $#@ù% problème de paramétrage ou bug (au moins on n’a pas à chercher du côté du virus 🙂 ).
On n’a pas envie non plus d’y passer des semaines.
On est seul devant ce truc, sans aucune aide facile et immédiate. Alors on se dit que des exemples similaires feraient très bien l’affaire.
Les bouquins c’est bien. C’est utile dans un contexte où l’on a envie d’apprendre, sur un système fonctionnel avec un gestionnaire de fenêtre.
Je pense que la meilleur aide pour la plupart des utilisateurs de systèmes d’exploitation vient des forums (mille merci à leurs mainteneurs).
Les pourrisseurs de forums (à la solde de je ne sais pas qui, j’en sais quelque-chose puisque j’en ai maintenu un petit pendant quelques temps) l’ont bien compris.
Google aussi.

Sur un forum d’ArchLinux (je précise qu’ils font du bon boulot, je me retrouve souvent à lire leur forum d’un très bon niveau technique – comme celui d’UBUNTU), je lis :

Le mec dans la merde :
« I will take a look as soon as I have time, but this is exatcly what I meant when I said in the beginning that I am asking for help because of the lack of time to fix it myself… »

Le mec qui a les connaissances sur son perchoir :  »
« This is a distribution that requires some maintenence from the user. If you have too little time to take care of your system, then this may not be the right operating system for you.

Also, there is no hand holding around here. If you want others to solve your problems for you, you may want to take a look at Ubuntu and Ubuntu based distributions, as they will take to statements like « I am asking for help because of the lack of time to fix it myself… » a bit more kindly. Honestly, that just pisses me off ».
(NdT : « pisses me off »= »me fait chier »)

Le type sur son perchoir (j’imagine qu’il en a marre de ce type de remarques), l’envoi carrément chez le voisin.
Que va faire le quidam débutant (finalement le type semble avoir résolu son problème sur ce forum), dans la merde, à votre avis ?
Mon p’tit doigt me dis qu’en moyenne il va un peu persister, ailleurs, puis il va retourner sous Windows ou Mac qu’il doit déjà regretter d’avoir quitté.
On peux faire tout ce qu’on veut, à crier de joie lorsque l’on franchi les 1% de joueurs Linuxiens sur Steam, à gonfler un peu de la poitrine en montrant nos belles interfaces MATE, KDE, GNOME (et c’est vrai qu’elles sont belles), à dire que Linux c’est bien, c’est libre.
Mais il reste encore un bout de chemin à faire pour mettre tout çà à la portée de l’amateur (les 99 autres % d’utilisateurs).

Je clôt ici le débat philosophique avec moi-même 🙂
(et la 1ere remarque. Cherchez pas, il n’y en a pas 2, la 2nde s’est retrouvée mixée avec la 1ere, elle concernait le type d’aide vraiment recherchée)

Par précaution (en lisant ce même forum), je lance un :
# apt install –reinstall consolekit
et reselectionne lightdm comme gestionnaire de démarrage graphique, puisqu’il fonctionnait précédemment et que lxdm n’a pas encore fait ses preuves sur mon système.
Et du coup, même pour lightdm, je retrouve le message :
dbus.service is not active, cannot reload.
invoke-rc.d: initscript dbus, action « reload » failed.

Sur le PC du Bottin, la commande :
# systemctl status systemd-logind.service
● systemd-logind.service – Login Service
Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
Active: active (running) since dim. 2016-10-16 09:07:19 CEST; 2h 10min ago

# systemctl status dbus.socket
● dbus.socket – D-Bus System Message Bus Socket
Loaded: loaded (/lib/systemd/system/dbus.socket; static; vendor preset: enabled)
Active: active (running) since dim. 2016-10-16 09:07:17 CEST; 2h 28min ago
Listen: /var/run/dbus/system_bus_socket (Stream)

Sur le PC internet :
# systemctl status systemd-logind.service
● systemd-logind.service – Login Service
Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
Active: inactive (dead)

# systemctl status dbus.socket
● dbus.socket – D-Bus System Message Bus Socket
Loaded: loaded (/lib/systemd/system/dbus.socket; static; vendor preset: enabled)
Active: inactive (dead)
Listen: /var/run/dbus/system_bus_socket (Stream)

J’ai beau fouiller sur le net, ce que j’y trouve dépasse de loin mes compétences 🙁

Ah, un léger mieux :

AVANT :
# systemctl status -l dbus-org.freedesktop.login1.service
● systemd-logind.service – Login Service
Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
Active: inactive (dead)

PUIS (lu sur le forum http://unix.stackexchange.com/questions/239489/dbus-system-failed-to-activate-service-org-freedesktop-login1-timed-out) :
# systemctl restart systemd-logind

APRÈS :
# systemctl status -l dbus-org.freedesktop.login1.service
● systemd-logind.service – Login Service
Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
Active: active (running) since dim. 2016-10-16 12:17:04 CEST; 6s ago
Docs: (non reproduit ici)
Main PID: 1997 (systemd-logind)
Status : « Processing requests… »
Tasks: 1 (limit: 4915)
CGroup: /system.slice/systemd-logind.service
1997 /lib/system/systemd-logind

system[1] : Starting Login Service…
systemd-logind[1997] : New seat seat0.
system[1] : Starting Login Service…
systemd-logind[1997] : Watching system buttons on /dev/input/event5 (Power Button)
systemd-logind[1997] : Watching system buttons on /dev/input/event4 (Power Button)

En résumé : je ne sais pas ce que j’ai fais, mais à présent il regarde mes boutons 🙂

# systemctl status dbus.socket
● dbus.socket – D-Bus System Message Bus Socket
Loaded: loaded (/lib/systemd/system/dbus.socket; static; vendor preset: enabled)
Active: active (running) since dim. 2016-10-16 12:17:03 CEST; 14min ago
Listen: /var/run/dbus/system_bus_socket (Stream)

Mon système est en retard de 14 min, mais il semble à présent démarré 🙂
En espérant qu’il se maintienne ainsi par la suite (notamment après un redémarrage).

Je lance un :
# startx
Mais j’ai toujours mon écran noir, avec cette fois-ci une ligne de texte en 1ère ligne :
http://www.freedesktop.org/wiki/Software/systemd/multiseat

Super. Me voilà bien avançé …
Le Ctrl Alt Fn ne fonctionne toujours pas. Planté (mais avec de l’internet sur le PC du Bottin).
J’ai l’impression que le Bottin des Jeux Linux n’est pas prêt d’être mis à jour …

Au démarrage suivant :
# systemctl restart systemd-logind
# dpkg-reconfigure lightdm
je sélectionne kdm
Please be sure to run « dpkg –configure kdm ».
dbus.service is not active, cannot reload.
invoke-rc.d: initscript dbus, action « reload » failed.
ERROR: /lib/systemd/system/kdm.service is the selected default display manager but does not exist

Sur un forum Debian je retrouve un problème analogue.
Effectivement je n’avais pas remarqué que la commande :
# dpkg-reconfigure kdm
je sélectionne kdm
ne retournait pas d’erreur.

En regard de ce forum, par précaution je réinstalle quelques paquets :
# apt install –reinstall consolekit debconf libgcrypt20 libglib2.0-0 libpam-systemd libpam0g libxcb1 libxdmcp6 lightdm-gtk-greeter accountsservice upower
et redémarre.
Au démarrage suivant, un :
# /etc/init.d/kdm reload
[….] Reloading kdm configuration (via systemctl): kdm.servicekdm.service is not active, cannot reload.
failed!

# systemctl status kdm.service
(…)
Active: inactive (dead)
systemd[1] : kdm.service: Unit cannot be reloaded because it is inactive

Ok. Avant il ne faisait pas tant d’histoires.
# /etc/init.d/kdm start

Et là je retrouve mon écran noir tout planté. Aahh. C’est mieux 🙂

# dpkg-reconfigure gdm3
je sélectionne gdm3
# /etc/init.d/gdm3 start
Il ne démarre pas.

# systemctl status gdm3.service
(…)
Active: active (running)
Main PID: 2153 (gdm3)
systemd[1] : Starting GNOME Display Manager…
systemd[1] : Started GNOME Display Manager.
gdm3[2153] Could’nt connect to system bus: Impossible de se connecter : Aucun fichier ou dossier de ce type

Visiblement il doit manquer un fichier quelque-part. Raison pour laquelle j’ai réinstallé ci-avant une série de paquets, suspectant que l’installation de l’un d’eux s’est mal terminée et qu’il n’est donc pas correctement installé.
Mais pour l’instant je fais choux blanc.

(Nota à posteriori : tu as tout à fait raison, continue, continue, … 🙂 )

En voilà 2 justement que je n’ai pas pensé réinstaller :
# apt install –reinstall systemd udev
(…)
Paramétrage de udev (231-9) …
addgroup: Le groupe « input » existe déjà en tant que groupe système. Fin de la procédure.
update-initramfs: deferring update (trigger activated)
Paramétrage de systemd (231-9) …
addgroup: Le groupe « systemd-journal » existe déjà en tant que groupe système. Fin de la procédure.
(…)
J’espère que ces messages n’ont rien interrompu (je ne pense pas).
Je redémarre pour voir.
Je re sélectionne lightdm puis lance :
# /etc/init.d/lightdm start
Curseur blanc sur fond noir

A noter que le fichier /var/log/Xorg.0.log n’affiche pas d’erreur mais la dernière ligne est constituée de :
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
Ca me semble un peu bizarre par rapport aux autres lignes qui contiennent toutes une référence temporelle du type :
[520.92] (II) (…)
Sur le PC du Bottin je n’ai pas cette ligne.
Peut-être est-ce parce qu’il plante et ne termine pas correctement le fichier.

Je vais tester un démarrage sur ma clé USB, l’histoire de voir si j’ai toujours du graphisme sur ce PC 🙂

Je confirme. Ca marche sur ma clé USB avec un noyau 3.2.0, sans fichier /etc/X11/xorg.conf et avec le driver NOUVEAU (d’après le fichier /var/log/Xorg.0.log).
Ca devrait donc fonctionner sans clé USB.

Je tente une expérience :
démarrage sur un noyau 3.2.0, renommage du fichier /etc/X11/xorg.conf, et utilisation de lightdm
Il semble vouloir démarrer mais n’y arrive pas (phases de curseur clignotant puis écran noir avec fonctionnement intermittent du disque dur etc…).
Je vais réessayer avec kdm et gdm3

# dpkg-reconfigure kdm
je sélectionne kdm
# /etc/init.d/kdm start

Eureka, avec kdm j’ai l’interface kdm (sans fichier /etc/X11/xorg.conf), mais avec une résolution très basse.
La joie est de courte durée, car lorsque je saisi un mot de passe, une fenêtre apparaît : « System is booting up. See pam_nologin(8) »
Mais il ne reboot pas
Et j’ai un message furtif « Echec de la connexion ».
Je progresse un peu tout de même.

Après quelques autres tentatives, j’ai un autre message :
Le type de session enregistrée « kde » est devenu non valable.
Veuillez en sélectionner un nouveau, sans quoi le type par défaut sera utilisé.
Ok

Pas moyen de se connecter.
Je vais essayer avec gdm3
Ca ne fonctionne pas. Ca ne plante pas mais ne démarre pas non plus. J’ai juste un message :
[ok] Starting gdm3 (via systelctl): gdm3.service.

Quant à lxdm, il me dit :
# systemctl status lxdm.service
(…)
Active: failed (Result: start-limit-hit)
(…)
systemd[1]: Failed to start LXDE Display Manager.

# apt install –reinstall lxde
puis je recommence : idem.

Avec xdm : j’ai aussi une fenêtre (mais affreuse) mais dès que je saisi le login – et avant même de saisir le mot de passe, j’ai le message :
« Login incorrect or forbidden by policy »

Je remet mon fichier /etc/X11/xorg.conf
Commente toutes les entrées de driver pour qu’aucune ne soit sélectionnée
et enlève ma modif précédente dans la section « ServerLayout » :
Screen 0 « Affichage »
devient donc :
Screen « Affichage »

et redémarre avec mon meilleur candidat : kdm
=> même message : « System is booting up. See pam_nologin(8) »

Dans le fichier /var/log/Xorg.0.log je vois effectivement que c’est le driver nouveau qui est utilisé.
Avec un certain nombre d’erreurs :
(EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket : No such file or directory)

# apt install –reinstall devscripts
(en passant)

J’ai décommenté le driver nvidia sous Xorg et lançé kdm : çà plante, je redémarre
Je retente en décommentant nouveau au lieu de nvidia et lance kdm :çà ne démarre pas.
Sous /var/log/Xorg.0.log j’ai :
(EE) [drm] Failed to open DRM device for pci:0000:03:00.0: -19
(EE) No devices detected.
(EE)
Fatal server error :
(EE) No screens found(EE)

Sur le site freedesktop.org, j’apprends effectivement que le driver nouveau n’a pas besoin de configuration de xorg :
« When using Nouveau, the X-Server doesn’t need configuration, the Nouveau driver should be loaded automatically.  »

Je tourne en rond.

En résumé :
– le PC internet semble avoir un souci de communication avec dbus
– les messages obtenus sont un peu trop génériques pour trouver une aide efficace sur le net
– aucun des gestionnaires de démarrage ne parvient à démarrer Xorg correctement.

# apt install –reinstall consolekit libpam-ck-connector
(en passant)
(libpam-ck-connector n’était pas installé)
Je redémarre et retente le coup : curseur blanc sur fond noir et planté.

# apt install –reinstall debianutils libc6 libdbus-1-3 libexpat1 libice6 libsm6 libx11-6 lsb-base dbus-user-session
(en passant)
Je redémarre et retente le coup : fond noir, pas de curseur blanc, et pas planté.
Ca semble un peu mieux.
La console 1 me redonne le texte, la console 2 est graphique mais noire

# dpkg-reconfigure lightdm
je sélectionne lightdm
Please be sure to run « dpkg –configure lightdm ».
dbus.service is not active, cannot reload.
invoke-rc.d: initscript dbus, action « reload » failed.
Ca n’est donc pas résolu.
En console je lance : # X
fond noir, pas de curseur blanc, et pas planté.
La console 1 me redonne le texte, la console 2 est graphique mais noire
Le fichier /var/log/Xorg.0.log semble très complet :
le module glx semble opérationnel
idem pour nvidia, fb, wfb, ramdac
Je vois les paramétrages NVIDIA(0) avec des valid display device (CRT-0, CRT-1, DFP-0, DFP-1)
Il trouve l’écran en CRT-1 avec une résolution de 1680 x 1050
DPMS enabled
[DRI2] Setup complete
RandR disabled
SELinux: Disabled on system
Indirect GLX disabled
le module evdev fonctionne aussi
Je ne vois aucune erreur. Je vais tenter un démarrage normal pour voir ce qui se passe.

Ca marche !!!!
Je retrouve mon bureau MATE sur le PC internet en résolution normale !!!

Yeepeee yep !!!!! Hourra !!!

Visiblement, le problème devait provenir d’un problème d’installation de l’un des paquets suivants :
debianutils libc6 libdbus-1-3 libexpat1 libice6 libsm6 libx11-6 lsb-base dbus-user-session

Punaise, il était coriace ce problème !
J’avoue que là je commençais à être à cour d’idées 🙂
La persévérance à de nouveau payée ! Yes !

Je vais pousser un peu plus loin :

Tout d’abord, çà démarre sur le noyau 4.7.0-1-686-pae
Le contenu de mon fichier /etc/X11/xorg.conf est le suivant :

Section « Device »
Identifier « Carte graphique »
Driver « nvidia »
# Driver « nouveau »
# Driver « vesa »
EndSection

Section « Monitor »
Identifier « Ecran »
Option « DPMS »
EndSection

Section « Screen »
Identifier « Affichage »
Device « Carte graphique »
Monitor « Ecran »
EndSection

Section « ServerLayout »
Identifier « Default Layout »
Screen « Affichage »
EndSection

Donc le même qu’initialement (pas de « 0 » entre Screen et « Affichage »), il fallait le préciser.
Lightdm fonctionne bien.

Je reteste le driver nouveau :
Je décommente le driver nouveau ci-dessus et recommente le driver nvidia
puis je lance : # /etc/init.d/lightdm restart
J’ai un écran noir avec le curseur clignotant. Mais j’ai accès à présent à toutes les consoles.
Je regarde dans /var/log/Xorg.0.log
Il charge le driver glx puis nouveau, il affiche les cartes supportées,
mais çà se termine par un :
(EE) [drm] Failed to open DRM device for (null):22
(EE) [drm] Failed to open DRM device for pci:0000:03:00.0: -22
(EE) No devices detected.
(EE)
Fatal server error:
(EE) no screens found(EE)

Autre test en renommant mon fichier /etc/X11/xorg.conf (puisque nouveau n’en a pas besoin) :
# /etc/init.d/lightdm restart
Ca marche aussi !!!

(Nota à posteriori : en fait il utilise encore le driver « nvidia » mais pas « nouveau »)

J’ai Xorg avec une belle résolution (nota après analyse : mais avec le driver propriétaire nvidia, et non pas « nouveau »).
Le fichier /var/log/Xorg.0.log affiche qu’il charge le module glx, puis nvidia, puis nouveau, qu’il n’arrive pas à charger le module « nv », puis il charge fbdev, vesa, affiche les cartes supportées, puis charge le module fb, wfb, ramdac, Enabling 2D acceleration, found DRM driver nvidia-drm, que c’est une carte GeForce 210 (GT218) at PCI:3:0:0 (GPU-0),
aïe : il affiche Unloading « nouveau », ainsi que « modesetting », « fbdev », « fbdevhw », « vesa »
ensuite on a DPMS enabled, [DRI2] Setup complete, RandR disabled, Indirect GLX disabled, charge le module evdev (gère tout ce qui est clavier et boutons) et comme il est toujours en fonctionnement, çà se termine par des infos sur le non support de la vision 3D NVIDIA.

Bon, si j’ai bien compris :
çà marche, mais après avoir chargé tous les modules, il décharge tous les drivers non utilisés (dont « nouveau ») et utilise finalement le driver propriétaire nvidia. Je dois pouvoir le vérifier sous l’interface graphique.
Ctrl Alt F7
Sous Mate, dans le menu « Applications>Outils Système>je clique sur l’utilitaire Sysinfo (fourni par le paquet éponyme).
Il a un onglet NVIDIA avec un bouton « NVIDIA Display Settings »
Je retrouve le nom de mon écran « Ancor Communications Inc ASUS VK221 (VGA-0)
Dans l’onglet OpenGL/GLX Information je trouve :
Direct Rendering: Yes
OpenGL Information
Renderer: GeForce 210/PCIe/SSE2
Version: 3.3.0 NVIDIA 340.98
=>donc visiblement, c’est bien le driver nvidia propriétaire qu’il utilise (en version 340.98)
Il y a aussi un onglet spécifique avec des tonnes d’informations sur le driver VDPAU : les codecs supportés (MPEG1, H264, MPEG4, DIVX4, DIVX5, …)
Un autre onglet GPU 0 affiche l’utilisation du GPU (en %), sa mémoire utilisée, sa température avec un barregraphe.
Je vois aussi que cette carte (je n’y avais pas prêté attention) peut utiliser un 2nd écran (connecteur supplémentaire à l’arrière), malgré son prix très bas.

Bref, très complet cet outil.

=> Donc :
1. là aussi le driver propriétaire nvidia se passe très bien de fichier /etc/X11/xorg.conf
2. il est inutile de blacklister le driver nouveau. Le driver propriétaire nvidia se charge automatiquement et les autres inutilisés se déchargent automatiquement.

Passons à kdm.
# /etc/init.d/lightdm stop
# dpkg-reconfigure kdm
je choisi kdm
# /etc/init.d/kdm start
[ok] Starting kdm (via systelctl): kdm.service.
Mais rien d’autre, pas d’interface graphique, ni même sur Ctrl Alt F7
=>kdm ne fonctionne visiblement plus.

Passons à gdm3.
# /etc/init.d/kdm stop
# dpkg-reconfigure gdm3
je choisi gdm3
# /etc/init.d/gdm3 start
=>gdm3 démarre !
Très joli
Il fonctionne, yes !

Passons à lxdm.
# /etc/init.d/gdm3 stop
# dpkg-reconfigure lxdm
je choisi lxdm
# /etc/init.d/lxdm start
=>lxdm démarre !
Très joli aussi (avec son gros titre « Login: » tout en arrondi et son sélecteur d’utilisateurs)
Il fonctionne aussi, yes !

————————————————————————————-

Reprise le 17/10/2016

Encore quelques essais avant de clore définitivement cette page.

Test des noyaux en place avec l’accélération graphique (test réalisé avec l’utilitaire Sysinfo, et glxgears dans l’un des cas) :
3.2.0-4-686-pae : Non (affichage en basse résolution : 1024×768, mais fonctionnel)
Après avoir arrêté le serveur graphique (# /etc/init.d/lightdm stop), j’ai relancé la commande : # m-a a-i -f nvidia-legacy-340xx-kernel-source
=> çà ne fonctionne toujours pas, même après un reboot l’affichage reste en basse résolution.
Je regarde dans le fichier : /var/log/Xorg.0.log
Étonnement il n’essaie pas de charger le driver nvidia, sinon la séquence de chargement semble identique, avec en plus un « (EE) [drm] Failed to open device », suivi plus loin d’un « (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) », pour le reste çà fonctionne, l’interface graphique démarre sans accélération et en basse résolution.
un : « # modprobe nvidia » ne renvoi pas d’erreur.
Tout ceci est étonnant car ce même PC démarre avec l’accélération graphique avec un noyau 3.2.0-4-686-pae et sans fichier xorg.conf sous ma clé USB.
D’autre-part, il me semblait que le driver nouveau était capable de meilleur performance qu’un simple 1024×768 sans accélération graphique (testé dans le Centre de Contrôle de MATE : c’est tout ce que je peux en tirer).
4.3.0-1-686-pae : OK
4.4.0-1-686-pae : OK
4.6-0-1-686-pae : Ok
4.7.0-1-686-pae (le dernier installé, et 1er testé) : Ok, il fonctionne bien.

Enseignements retirés de ces essais :
– lorsque les mises à jours sont importantes (plus d’1 mois sans MAJ), il vaut mieux privilégier la mise à jour en console (# apt update, # apt upgrade) plutôt qu’une mise à jour via Synaptic (qui, en version 0.83, ne présente pas un niveau de fiabilité suffisant),
– plus besoin de fichier /etc/X11/xorg.conf, le driver « nvidia » comme « nouveau » s’en accomodent,
– le serveur Xorg charge d’abord le driver nouveau et l’utilise si le driver nvidia n’est pas disponible, sinon c’est ce dernier qui est utilisé en priorité,
– les gestionnaires de démarrage lightdm, gdm3 et lxdm fonctionnent bien,
– kdm ne fonctionne plus sur ce PC (le seul dont j’étais certain qu’il fonctionnait, car je l’utilise sur le PC du Bottin :)). La raison très probable est que KDE n’est pas complètement installé (suite à de précédents conflits de paquets dans les dépôts) sur ce PC (il n’est d’ailleurs pas présenté en choix dans mes gestionnaires de démarrages).
– idem pour le noyau 3.2.0 : l’accélération graphique ne fonctionne plus avec ce noyau (mais il reste utilisable en basse résolution) alors que c’est le noyau en qui j’avais le plus confiance,
– visiblement mon souci provenait de l’un des paquets (debianutils libc6 libdbus-1-3 libexpat1 libice6 libsm6 libx11-6 lsb-base dbus-user-session) probablement mal installé (voir peut-être aussi d’un des autres réinstallés).

Je suis fin prêt pour retourner sur le Bottin, mais malheureusement je ne vais être que peu disponible dans les jours à venir.

Suite au REX ci-dessus, je me suis décidé à apporter un peu de changement sur le PC du Bottin :
Dans un 1er temps j’ai testé la suppression de mon fichier /etc/X11/xorg.conf : çà fonctionne.

Néanmoins je l’ai finalement repris et allégé, pour 2 raisons :
– j’en ai besoin pour inverser l’ordre d’affichage de mes écrans (les connexions ne sont pas les mêmes – HDMI pour l’un, VGA pour l’autre, celui en HDMI a une meilleur restitution, je souhaite qu’il s’affiche face à moi, l’autre est sur la droite). On peux le faire sous MATE, mais çà n’est pas pris en compte sous lightDM ni gdm3.
– pour paramétrer ma tablette graphique Wacom.

Voici mon fichier /etc/X11/xorg.conf (complet, et fonctionnel évidemment) tel qu’il est à présent (le 17/10/2016) sur le PC du Bottin :
(il n’y a plus de section pour les drivers nvidia, nouveau ou vesa)
(la 1ere section est uniquement là pour inverser l’ordre d’affichage des écrans)

Section « Screen »
Identifier « Affichage »
Option « TwinView » « 1 »
Option « DFP-1: nvidia-auto-select +0+0, DFP-2: nvidia-auto-select +1920+0 »
Option « TwinViewXineramaInfoOrder » « DFP-1 »
EndSection

Section « ServerLayout »
Identifier « Default Layout »
Screen « Affichage »
InputDevice « stylus » « AlwaysCore »
InputDevice « eraser » « AlwaysCore »
InputDevice « cursor » « AlwaysCore »
InputDevice « pad »
EndSection

Section « InputDevice »
Identifier « stylus »
Driver « wacom »
Option « Type » « stylus »
Option « Mode » « Absolute »
Option « USB » « on »
Option « Threshold » « 10 »
Option « Device » « /dev/input/wacom »
EndSection

Section « InputDevice »
Identifier « eraser »
Driver « wacom »
Option « Type » « eraser »
Option « Mode » « Absolute »
Option « USB » « on »
Option « Threshold » « 10 »
Option « Device » « /dev/input/wacom »
EndSection

Section « InputDevice »
Identifier « cursor »
Driver « wacom »
Option « Type » « cursor »
Option « Mode » « Relative »
Option « USB » « on »
Option « Threshold » « 10 »
Option « Device » « /dev/input/wacom »
EndSection

Section « InputDevice »
Identifier « pad »
Driver « wacom »
Option « Type » « pad »
Option « USB » « on »
Option « Device » « /dev/input/wacom »
EndSection

1 comment for “[Résolu] Journal d’une tentative de résolution d’absence d’affichage graphique
[Résolu] Journal d’une tentative de résolution d’absence d’affichage graphique avatar