GDM : Problème de login automatique

Support Debian
#1

Bonjour à tous,

Edit : Avant que vous lisiez la suite (qui peut avoir son importance), je pensais initialement le soucis lié à X, mais il semblerait que ce ne soit finalement pas le cas.

J’ai fait l’erreur d’essayer d’installer les pilotes propriétaires ATI (fglrx-driver) pour régler certains problèmes que j’avais. Lorsque j’ai compris que ça ne fonctionnerait jamais, je les ai désinstallé pour remettre les drivers libres sur lesquels je tourne actuellement. Seulement, depuis que j’ai remis les drivers libres, j’ai un soucis au démarrage. D’abord, j’ai l’écran de login GDM qui s’affiche pour me demander mon mot de passe alors qu’il ne devrait pas puisque le login automatique est activé dans les paramètres des utilisateurs (et ça fonctionnait très bien auparavant d’ailleurs). J’imagine qu’il y a un échec quelconque au démarrage qui fait que je suis redirigé vers l’écran de connexion.
Bref, une fois que je me connecte, la sentence est immédiate, j’obtiens un magnifique écran noir et un underscore “_” clignotant en haut à gauche. Ma session ne s’affiche jamais.
Comble de la bizarrerie, si je me rends dans un TTY et lance startx manuellement, la session se lance tout à fait normalement.
J’ai tenté un bête dpkg-reconfigure xserver-xorg, sans succès. Je n’ai aucun fichier de configuration Xorg. Ma configuration est, à priori, strictement identique à celle que j’avais avant d’installer ces maudits pilotes propriétaires. Les firmeware-linux-nonfree sont bien installés.

Je tourne sous Debian testing.

~ uname -a Linux jfl 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3 (2015-04-23) x86_64 GNU/Linux

~ lspci|grep VGA 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Chelsea LP [Radeon HD 7730M] (rev ff)

~ dmesg | grep -E 'drm|radeon' | grep -iE 'firmware|microcode' [ 6.652500] [drm] Loading VERDE Microcode [ 6.652951] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/VERDE_pfp.bin [ 6.653335] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/VERDE_me.bin [ 6.653565] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/VERDE_ce.bin [ 6.653702] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/VERDE_rlc.bin [ 6.654069] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/VERDE_mc2.bin [ 6.654454] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/VERDE_smc.bin [ 6.661419] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin

~ lspci -nnk | grep -i vga -A3 | grep 'in use' Kernel driver in use: i915 Kernel driver in use: radeon

Quelques messages inquiétants dans mon .xsession-errors : paste.debian.net/hidden/1265abb6/
Mon log Xorg (même si mon œil inexpérimenté n’y voit rien d’alarmant) : paste.debian.net/hidden/277adeed/
Mon syslog (idem) : paste.debian.net/hidden/4bea8230/

Merci d’avance :slightly_smiling: .
BrasDeMehldau

#2

tu es sure ?

#3

Salut,

[quote=“BrasDeMehldau”]J’ai fait l’erreur d’essayer d’installer les pilotes propriétaires ATI (fglrx-driver) pour régler certains problèmes que j’avais.
(…)
j’ai l’écran de login GDM[/quote]

[quote]5.11. Le bureau GNOME ne fonctionne pas avec le pilote AMD propriétaire FGLRX

Contrairement aux autres pilotes OpenGL, le pilote AMD FGLRX pour les adaptateurs Radeon ne prend pas en charge l’interface EGL. Ainsi, plusieurs applications GNOME, dont le cœur du bureau GNOME, ne démarreront pas du tout quand ce driver sera utilisé.

Il est recommandé d’utiliser à la place le pilote libre [mono]radeon[/mono], qui est le pilote par défaut de Jessie.
[/quote]
Nous pouvons raisonnablement penser qu’il en est de même sous [mono]stretch[/mono].

[quote=“BrasDeMehldau”]je les ai désinstallé pour remettre les drivers libres
(…)
j’obtiens un magnifique écran noir et un underscore “_”[/quote]
Essayes simplement de supprimer (il sera recréer automatiquement au boot) le fichier [mono]~/.Xauthority[/mono] puis reboot.

Info disponible en [mono]~/.xsession-errors[/mono] et [mono]/var/log/Xorg.0.log[/mono].

  • edit *

[quote=“BrasDeMehldau”]Quelques messages inquiétants dans mon .xsession-errors :
Mon log Xorg (même si mon œil inexpérimenté n’y voit rien d’alarmant) :[/quote]

#4

Merci de vos deux réponses.

[quote=“misaine”]tu es sure ?

D’accord, je les ai ceux-là, mais ils n’ont pas été touchés par fglrx.

[quote=“BelZéButh”]Salut,

[quote=“BrasDeMehldau”]J’ai fait l’erreur d’essayer d’installer les pilotes propriétaires ATI (fglrx-driver) pour régler certains problèmes que j’avais.
(…)
j’ai l’écran de login GDM[/quote]

[quote]5.11. Le bureau GNOME ne fonctionne pas avec le pilote AMD propriétaire FGLRX

Contrairement aux autres pilotes OpenGL, le pilote AMD FGLRX pour les adaptateurs Radeon ne prend pas en charge l’interface EGL. Ainsi, plusieurs applications GNOME, dont le cœur du bureau GNOME, ne démarreront pas du tout quand ce driver sera utilisé.

Il est recommandé d’utiliser à la place le pilote libre [mono]radeon[/mono], qui est le pilote par défaut de Jessie.
[/quote][/quote]
Ouh là, tu as complètement tronqué mes citations et du coup, tu me fais dire ce que je n’ai pas du tout dit. J’utilise BIEN le pilote libre radeon (comme l’indiquent mes nombreux messages de log). J’ai simplement (sur un coup de folie, dans un élan de bêtise absolu, je reconnais), voulu tenter le pilote fglrx. Quand j’ai compris que :

, je me suis empressé de le virer, lui, et les fichiers de configuration Xorg que j’avais faits ou qu’il avait laissé.

Néanmoins, je comprends ton énervement et ta lecture en diagonale à la simple évocation du mot “fglrx” ; j’aurais certainement fait la même chose à ta place :wink: .

Le rappel ne fait pas de mal, mais nul besoin de m’accabler encore plus, je suis déjà suffisamment honteux de mon erreur…

Par ailleurs, tout fonctionne correctement lorsque je fait un startx, ce qui tendrait à prouver quelque chose. Je sais pas quoi, mais quelque chose. Genre qu’il essaye de me loger trop tôt ou je sais pas.

Là par contre, c’est moi qui ai dû mal m’exprimer. Je suis sur la branche testing (avec “testing” dans mon sources.list, et pas “jessie”, ni “stretch”), et donc, a priori, encore sous Jessie. En effet, le basculement de la branche testing vers stretch ne semble pas encore effectif dans les sources. En tout cas, dist-upgrade ne m’a toujours rien donné de gros à manger et dans paramètres=>Détails, je suis toujours indiqué sous Jessie.

[quote=“BelZéButh”][quote=“BrasDeMehldau”]je les ai désinstallé pour remettre les drivers libres
(…)
j’obtiens un magnifique écran noir et un underscore “_”[/quote]
Essayes simplement de supprimer (il sera recréer automatiquement au boot) le fichier [mono]~/.Xauthority[/mono] puis reboot.[/quote]

J’ai fait ça, mais ça n’a rien changé au problème malheureusement :frowning: .

Info disponible en [mono]~/.xsession-errors[/mono] et [mono]/var/log/Xorg.0.log[/mono].

  • edit *

[quote=“BrasDeMehldau”]Quelques messages inquiétants dans mon .xsession-errors :
Mon log Xorg (même si mon œil inexpérimenté n’y voit rien d’alarmant) :[/quote][/quote]

Les messages qui s’ajoutent au .xsession-errors depuis que j’ai désinstallé fglrx se limitent à :

Xsession: X session started for brad at samedi 2 mai 2015, 09:19:46 (UTC+0200) localuser:brad being added to access control list openConnection: connect: Aucun fichier ou dossier de ce type cannot connect to brltty at :0

Merci encore de votre aide. Je suis un peu à court d’idées là :-/ .
BrasDeMehldau

#5

si ça fonctionne avec startx, ce n’est pas un probléme xorg.
essaie un

#6

[quote=“piratebab”]si ça fonctionne avec startx, ce n’est pas un probléme xorg.
essaie un

Effectivement, cette explication me convient bien. La commande que tu m’as donnée n’a rien corrigé.

Néanmoins, il semble qu’un nouvel utilisateur sur mon système ne soit pas concerné par le problème (je viens de tester). Il s’agirait donc bien d’un soucis de configuration de mon utilisateur (/etc ou dans un dotfile). De là à trouver lequel… J’ai pensé que cela pouvait être lié à mon récent passage sur zsh plutôt que bash, mais remette bash n’a rien arrange.

Comme le suggérait habilement BelZéButh, j’ai tenté de supprimer le fichier .Xauthority, mais cela n’a rien changé. Idem pour le fichier .ICEAuthority.

Merci !
BrasDeMehldau

#7

Non, je ne faisais que souligner le fait que tu avais installé le pilote FGLRX, le désinstaller pour revenir à radeon.

Il n’en est rien, dans les deux sens.

La solution n’est pas très loin.

[mono]Jessie[/mono] est la version stable depuis le 24 de ce mois.
[mono]stretch[/mono] est la nouvelle [mono]Testing[/mono].
Voir la liste des paquets

[quote]Voir les paquets de la distribution testing
Cette zone contient les paquets destinés a faire partie de la distribution stable. Il existe des critères stricts qu’un paquet de “unstable” (voir plus bas) doit satisfaire avant de pouvoir être ajouté à “testing”. Cette distribution ne bénéficie pas de mises à jour spéciales de la part de l’équipe chargée des problèmes de sécurité. [/quote]
Voir les paquets de la distribution testing

[quote]List of sections in “stretch”
(…)[/quote]

Ok, crées toi un nouvel utilisateur et démarres sur sa session.

Résultat ?

#8

BelZéButh Merci de cette réponse. Donc il semblerait, contrairement à ce que j’ai dit et à ce qui est indiqué dans les détails, que je suis bien sous stretch. (http://ftp.fr.debian.org/debian/dists/testing/Release) \o/
Le nouvel utilisateur que j’ai créé fonctionne bien. Il s’agirait donc bien d’un soucis avec mon utilisateur et sa configuration (un dotfile par exemple comme tu l’avais justement intuité). Le problème est donc bien différent et mon diagnostic était mauvais. Il s’agit maintenant de trouver le dotfile problématique.

#9

Bien, je connais pas vraiment le Gnome et/ou j’ai oublié.
Ce que tu peux faire.

[ul][li]un comparatif du répertoire [mono]/home/user_posant_problème[/mono] et [mono]/home/toto[/mono]
sur la foi de [mono]$ ls -la /home/…[/mono][/li]
[li]faire une sauvegarde de [mono]/home/user_posant_problème[/mono] ou des répertoires et fichiers de ton choix[/li]
[li] à la suite de quoi tu copies (écrases) le répertoire [mono]/home/toto[/mono] vers [mono]/home/user_posant_problème[/mono]
soit [mono]$ cp -ari /home/toto /home/user_posant_problème[/mono][/li]
[li] tu quittes la session [mono]toto[/mono] et relances celle de l’utilisateur initial[/li]
[li] après quoi tu supprimes l’utilisateur [mono]toto[/mono].[/li][/ul]

#10

Après avoir mieux testé, il semblerait que le soucis soit lié au login automatique au démarrage. Lorsque je le désactive, le comportement n’est pas anormal. Lorsqu’il est activé, le problème est strictement équivalent, peu importe l’utilisateur. Par exemple, si j’active l’autologin sur l’utilisateur test, je suis redirigé vers l’écran de log de GDM, puis l’utilisateur brad fonctionnera correctement, mais pas l’utilisateur test.

D’après ces nouveaux éléments, il y a fort à parier qu’un changement des fichiers utilisateurs ne changera rien : le problème réapparaîtra dès que je réactiverai l’autologin.

Étrange problème tout de même.

BrasDeMehldau

#11

Essaie un autre lanceur, tel que kdm, tu verras bien

#12

Est-ce à cela que tu faisais allusion ?

#13

Avec KDM, l’autologin ne fonctionne pas non plus. Je suis redirigé vers l’écran de login de la même manière. Lorsque je me log pour la première fois, j’ai un rapide écran noir (avec quelques informations de log), puis retour sur l’écran de login. La seconde tentative de log se passe correctement, ce qui est un progrès par rapport à GDM qui ne me laissait même pas essayer une seconde fois.

Pas du tout. J’avais des soucis de performance, de ventilateur tournant constamment et/ou de surchauffe. Rien à voir donc.

#14

Ok.

Gdm3 autologin fonctionne et ne fonctionne pas

[quote=“lebardix”]Le probleme est bien un défaut du serveur X, je ne sais pas pourquoi, au deuxieme lancement, X est correct,
La desinstallation du pilote propriétaire a permis de retrouver la fonction autologin
Vérification installation pilote libre

# apt-get install xserver-xorg-video-radeon xserver-xorg-video-radeon est déjà la plus récente version disponible. Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : libdumbnet1 zerofree

root@pc-soun:/var/log/gdm3# apt-get autoremove Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets suivants seront ENLEVÉS : libdumbnet1 zerofree Suppression de libdumbnet1 ... Suppression de zerofree ...
Suppression du pilote propriétaire pour éviter tout confit :
# aptitude purge '~ifglrx' Les paquets suivants seront ENLEVÉS : fglrx-atieventsd{p} fglrx-control{p} fglrx-driver{p} fglrx-modules-dkms{p} glx-alternative-fglrx{p} libfglrx{p} libfglrx-amdxvba1{p} libgl1-fglrx-glx{p} ...

L’autologin est OK, merci à tous[/quote]
et là, ATI/AMD : radeon et fglrx.

#15

BelZéButh, tout ceci semble correspondre d’assez près à mon soucis (fglrx et autologin cassé), malheureusement, tous mes paquets fglrx sont bien désinstallés, tous les paquets des pilotes libres sont installés, mais rien de nouveau sous le soleil :frowning: .

> aptitude purge '~ifglrx' Aucun paquet ne va être installé, mis à jour ou enlevé. 0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de télécharger 0 o d'archives. Après dépaquetage, 0 o seront utilisés.

# apt-get purge fglrx* Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait …………… 0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

# apt-get install firmware-linux-nonfree Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait firmware-linux-nonfree est déjà la plus récente version disponible. 0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

# apt-get install xserver-xorg-video-radeon Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait xserver-xorg-video-radeon est déjà la plus récente version disponible. 0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

De même, dpkg-reconfigure xserver-video-[all|ati|intel] ou encore xserver-xorg ou gdm3 ou kdm ne change rien au problème.

BrasDeMehldau

#16

Tu devrais t’assurer d’un nettoyage complet.
Cela ne coûte rien et lèverait le doute.
Une recherche des paquets désinstallés et leurs fichiers de conf non purgés.

Tu nettoies.

Une nouvelle recherche.

#17

BelZéButh, pas plus de chance avec ces quelques commandes, malheureusement :frowning: .

Il restait le fichier /usr/X11R6/lib64/modules/dri/fglrx_dri.so que j’ai supprimé et qui tendrait à prouver que fglrx a quand même laissé quelques traces de son passage, mais rien de plus.

BrasDeMehldau

#18

Problème “résolu” en downgrandant vers Debian stable. Je pense que je vais attendre le freeze de la version testing avant de m’y réessayer. Faut-il ouvrir un ticket sur un bugtracker pour aider le projet Debian ?

Merci à tous ceux qui m’ont aidé, particulièrement Belzébuth :slightly_smiling: .
BrasDeMehldau

#19

Bonjour,

Gné ? La nouvelle stable venant de sortir, tu vas de voir attendre 2 ans :wink:
Il faut éviter d’utiliser la version testing (qui porte bien son nom).
Pour une utilisation courante, préférer :
[ul]stable (avec des backports éventuellement pour avoir des versions de certaines applications un peu plus récentes),
ou sid (pour avoir des versions très récentes mais il faut avoir un petit peu d’expérience !)[/ul]

Debian a son propre système de gestion de bogues.
Je te conseille d’installer le paquet [mono]reportbug[/mono]

#20

C’est la vie :slightly_smiling: .

J’utilisais Jessie quasiment depuis sa sortie sans aucun soucis. M’enfin. Je ne peux pas passer tout le temps entre les gouttes.

[quote=“lsam”]Pour une utilisation courante, préférer :
[ul]stable (avec des backports éventuellement pour avoir des versions de certaines applications un peu plus récentes),
ou sid (pour avoir des versions très récentes mais il faut avoir un petit peu d’expérience !)[/ul][/quote]
Mon utilisation courante, c’est du dev principalement. Il paraît qu’il n’y a pas besoin d’interface graphique pour faire ça :stuck_out_tongue: .
Je me contenterai des backports alors.

[quote=“lsam”]Debian a son propre système de gestion de bogues.
Je te conseille d’installer le paquet [mono]reportbug[/mono][/quote]
C’est noté et c’était déjà installé.

BrasDeMehldau