Mon Ubuntu est bloqué dans une boucle de connexion en essayant d'entrer sur mon bureau. Lorsque je me connecte, l'écran devient noir et, peu après, l'écran de connexion réapparaît.
J'ai lu que le problème pouvait être dû à une erreur liée aux graphiques, voici ma carte graphique: ATI Radeon 7670M
Êtes-vous arrivé ici après avoir exécuté Sudo startx
? Néanmoins:
Presse Ctrl+Alt+F3 et connectez-vous à la coquille.
Maintenant, lancez ls -lA
. Si vous voyez la ligne
-rw------- 1 root root 53 Nov 29 10:19 .Xauthority
alors vous devez faire chown username:username .Xauthority
et essayer de vous connecter (vous devrez peut-être faire la même chose pour pour .ICEauthority
).
Sinon, faites ls -ld /tmp
. Recherchez les 10 premières lettres à gauche: ils doivent lire exactement comme suit: drwxrwxrwt
.
drwxrwxrwt 15 root root 4096 Nov 30 04:17 /tmp
Sinon, vous devez faire Sudo chmod a+wt /tmp
et vérifier à nouveau.
Si ce n'est pas les deux, je vous recommanderais soit
Sudo dpkg-reconfigure lightdm
Maintenant, appuyez sur Alt+→ jusqu'à ce que vous atteigniez à nouveau l'écran de connexion et redémarrez.
J'avais ceci et après avoir regardé /var/log/Xorg.0.log
j'ai découvert que c'était un problème de Nvidia (il y avait une ligne disant Xlib: extension "GLX" missing on display ":0
).
J'ai réalisé que j'avais des pilotes Nvidia du site officiel qui ne sont pas vraiment stables et testés (donc j'ai lu et j'ai déjà fait l'expérience).
La solution ici consistait à installer le paquetage nvidia-current
à partir du dépôt Ubuntu; c'est une version terriblement obsolète, mais au moins, elle a été testée correctement. Son installateur est tout à fait capable aussi et il a désinstallé avec succès ma version unstable installée sur le site Web de Nvidia.
TL; DR, essayez simplement de vous connecter au shell (Ctrl+Alt+F2 ou quel que soit F entre F1 et F6) et le type
Sudo add-apt-repository ppa:graphics-drivers/ppa
Sudo apt update
Sudo apt install nvidia-367
Si cela réussit, redémarrez.
Sudo reboot
Si le problème est résolu, vous devriez pouvoir vous connecter à Unity.
UPDATE
Veuillez noter que parfois nvidia-current
peut installer le mauvais pilote. Dans ce cas, recherchez le dernier pilote compatible pour votre carte vidéo et installez-la. Par exemple, sous Ubuntu 16.04, nvidia-current
pointe vers la version: 304.131-0ubuntu3. Cela pourrait être incompatible avec votre carte graphique. par conséquent, recherchez avec Sudo apt-cache search nvidia-[0-9]+$
le paquet dont vous avez besoin et installez-le.
J'ai rencontré ce problème et aucune des solutions suggérées ci-dessus n'a fonctionné pour moi. Après avoir failli abandonner, j’ai regardé le .xsession-errors
et constaté que j’avais une faute de frappe dans mon .profile
(j’ai eu un }
supplémentaire dans le fichier après que je l’ai édité plus tôt dans la journée).
Cela causait la boucle de connexion. Ce pourrait être un autre endroit à regarder si les autres solutions suggérées ne fonctionnent pas pour vous.
J'ai eu un problème presque identique il y a quelques mois. Le passage à une console à partir de l'écran de connexion LightDM (Ctrl-Alt-F1), en vous connectant avec un nom d'utilisateur et un mot de passe administratifs et en entrant les commandes suivantes a résolu le problème:
Sudo mv ~/.Xauthority ~/.Xauthority.backup
Sudo service lightdm restart
Face au même problème aujourd'hui.
La cause était un peu étrange pour moi. xubuntu-desktop
a été supprimé, donc ubuntu-desktop
. LightDM s'est arrêté sans message d'erreur. J'ai essayé de lxdm et quand j'ai essayé de me connecter, un message indiquant que Xubuntu était introuvable a été affiché.
xubuntu-desktop
réinstallé et c'est corrigé maintenant. Pensez que apt-get autoremove
a supprimé le paquet.
Presse Ctrl+ALT+F3. Vous devriez recevoir une invite de connexion de style unix, alors entrez votre nom d'utilisateur et votre mot de passe ici. À partir de là, vous devriez recevoir un Shell (un programme qui vous permet de saisir des commandes, un peu comme le code cmd.exe
de windows). Entrez ces commandes et appuyez sur ENTER (ou Return) après avoir écrit chacun (vous devrez entrer votre mot de passe quand il affichera quelque chose comme [Sudo] password for USERNAME
. Notez que le mot de passe ne s'affichera pas lorsque vous le taperez!):
Sudo apt-get update
Sudo apt-get -y dist-upgrade
Sudo apt-get -y install fglrx
Puis redémarrez votre ordinateur en utilisant cette commande:
Sudo reboot
Voyez si cela fonctionne :)
Si cela ne fonctionne pas, essayez de revenir au 3ème terminal (Ctrl+ALT+F3), connectez-vous et entrez cette commande (en appuyant sur ENTER après l'avoir tapé):
Sudo apt-get -y install lxdm
Cela montrera un dialogue semblable à DOS après un peu. Si lxdm
n’est pas sélectionné, sélectionnez-le à l’aide de la touche UP et DOWN touches fléchées et appuyez sur ENTER d'accepter cette sélection. Puis redémarrez en utilisant la même commande que précédemment (Sudo reboot
).
Si cela toujours ne fonctionne pas, retournez au 3ème terminal (ALT+F3), connectez-vous et entrez cette commande (même procédure):
Sudo apt-get -y install lubuntu-desktop
Cela installera un environnement de bureau beaucoup plus léger qui devrait fonctionne pour le moment (devrait vous permettre de vous connecter et d’utiliser votre ordinateur). Une fois que cela est fait, redémarrez (Sudo reboot
), et lorsque vous serez confronté à la page de connexion, sélectionnez l'environnement Lubuntu
au lieu de Ubuntu
.
Mon le dossier de départ était plein :-( df -h
vous donnera cette réponse que je devais me connecter via ssh a fait de la place et a fonctionné comme une fleur
ctrl+alt+F1, connectez-vous en tant qu'utilisateur, libérez de l'espace et redémarrez votre serveur X! principalement Sudo service sddm restart
Vous pourriez avoir des problèmes avec LightDM, le gestionnaire de connexion fourni par défaut avec Ubuntu. En 12.04, le problème que vous décrivez était utilisé auparavant.
Vous pouvez installer GDM, un autre gestionnaire de connexion, pour résoudre ce problème:
À l'écran de connexion, maintenez enfoncé Ctrl+Alt+F2 aller au terminal. N'aie pas peur! Connectez-vous simplement ici avec votre nom d'utilisateur et votre mot de passe.
Ensuite, tapez Sudo apt-get install gdm
. Laissez-le s'installer et tapez Sudo dpkg-reconfigure gdm
, puis suivez les invites pour le définir en tant que gestionnaire de connexion.
Presse Ctrl+Alt+F7 pour revenir à l'écran de connexion qui devrait maintenant avoir un aspect différent. La connexion fonctionne-t-elle? Si c'est le cas, votre problème est résolu!
Si ce n’est pas le cas, retournez au terminal plein écran (à nouveau, Ctrl+Alt+F2) et exécutez Sudo dpkg-reconfigure lightdm
pour définir LightDM lorsque vous vous connectez à nouveau au gestionnaire. Vous savez maintenant qu’il s’agit d’un problème lié aux pilotes graphiques.
Ce n'est pas une réponse directe à votre cas, mais plutôt une solution générale pour les boucles de connexion.
Le problème peut être aussi simple qu'une mauvaise commande placée dans le fichier .profile du répertoire de base. (Depuis que ce fichier est chargé lors de la connexion)
Pour voir si c'est vraiment le cas, appuyez sur CtrlAltF1et vous connecter. Vérification du fichier .xsession-errors dans votre répertoire personnel
~/.xsession-errors
Cela devrait donner des indices sur une commande problématique.
Votre environnement de bureau ne parvient pas à démarrer (cela ressemble à). Je commencerais par essayer de me connecter en tant qu'utilisateur différent.
Ctrl+Alt+F1 puis connectez-vous
Sudo adduser testing
Une fois l'utilisateur ajouté ctrl+alt+f7 et essayez de vous connecter en tant que test. Si vous pouvez vous connecter en tant que test, votre configuration d'unité/gnome est ignorée et doit être réinitialisée. Cette question le couvre. Je préfère mv ~/.config ~/.config.old
.
Problèmes de pilotes propriétaires
J'ai pu me connecter à TTY
à l'aide de ctrl+alt+F1
, mais je n'avais pas d'accès Internet, car le pilote est également propriétaire.
Aucun problème de Xorg n'était apparent.
J'ai décidé de supprimer les packages lorsque j'ai reçu le message MokSB failed
m'indiquant qu'il ne pouvait PAS modifier les paramètres de démarrage sécurisé. La partie notable est qu’il m’a demandé un mot de passe même s’il a échoué.
Attention: Ne retirez PAS aveuglément vos pilotes!
Un bon test pour déterminer s'il s'agit d'un problème de pilote propriétaire consiste à désactiver le démarrage sécurisé, à démarrer Ubuntu et à tenter de se connecter. Si la connexion fonctionne, vous savez maintenant quel est votre problème.
Pilotes Broadcom et Pilotes Nvidia
J'ai enlevé les paquets nvidia
Sudo apt-get purge nvidia-*
puis j'ai enlevé les paquets broadcom
Sudo apt-get purge bcmwl-kernel-source
et redémarré.
J'ai essayé de me connecter à nouveau et le succès!
J'ai vu mon bureau!
J'ai redémarré à nouveau. connecté à nouveau et tout a été réglé par défaut.
J'ai redémarré dans le BIOS
désactiver le démarrage sécurisé (non recommandé, besoin d'une meilleure solution)
démarrer ubuntu en utilisant grub
connecté et installé le fichier * .deb téléchargé pour mon pilote wifi
installé à l'aide du centre logiciel
et redémarré.
J'ai suivi la même procédure pour mes pilotes nvidia car les pilotes vidéo par défaut sont affreux sur ma carte.
Réactiver le démarrage sécurisé
Si j'active à nouveau le démarrage sécurisé, je vois le même problème. Comme les pilotes ne sont PAS signés, ce n'est pas un vrai démarrage sécurisé et je suis bloqué.
Personnellement, je trouve que c'est un problème très faux (et ennuyeux).
Solution alternative?
La solution la plus pratique que j'ai vue était personnalisant le noya car je ne peux pas simplement laisser le démarrage sécurisé désactivé, l'activer puis le désactiver, lorsque je change de système d'exploitation. Encore une fois, c'est juste énervant.
UPDATE le 4 janvier 2017
Selon ce article , le noyau Linux> = 4.6 supporte maintenant officiellement
Prise en charge accélérée de la série GeForce GTX 900 avec des images de micrologiciel signées.
Cela devrait résoudre le problème de démarrage sécurisé causé par l'utilisation des images de microprogramme non signées.
Oui, j'ai provoqué une boucle de connexion sur mon utilisateur principal Ubuntu 12.10 et le correctif était simple.
Fond d'écran: Ubuntu 12.10 est installé dans VirtualBox sous Windows 7 et utilise Unity.
Cause: à partir du bureau I Ctrl+Alt+T en mode terminal, puis j'ai essayé de lancer 'startx' (j'essayais d'aider un ami par téléphone tard dans la nuit ... mais c'était une chose stupide à faire). Un nouveau bureau vierge Unity est apparu et tout a été suspendu ...
Problème:
Forcer VirtualBox à se fermer puis redémarrer Ubuntu Je suis arrivé à l'écran de connexion, mais j'ai gardé la boucle pour revenir au même écran chaque fois après la saisie du mot de passe. Aucune erreur n'a été affichée. Je pouvais me connecter en tant qu'invité mais je n'avais aucun droit Sudo et donc aucun contrôle ... Cependant, une fois connecté en tant qu'invité, Ctrl+Alt+F3 et arrivé à un login de terminal.
J'ai entré mon nom d'utilisateur principal et mon mot de passe et je me suis connecté avec le mode commande. La déconnexion m'a ramené à la connexion CLI et Ctrl+Alt+F7 m'a ramené au bureau des invités. Donc, mon compte fonctionnait toujours. J'ai ensuite ajouté un utilisateur test et lui ai donné les droits Sudo. À partir de la connexion Unity, je pouvais me connecter et me déconnecter. Testez l'utilisateur sans problème. Donc, l'unité fonctionnait toujours.
Correction: mon compte principal était donc toujours accessible via CLI et Unity fonctionnait pour tous les autres comptes. Cela indiquait un problème de configuration sur mon compte principal. J'ai suivi les conseils de SiddharthaRT en haut de ce post et ai fait chown username:username .Xauthority
. Cela a résolu mon problème. Merci !!
J'ai pressé Ctrl+Alt+F3 et connecté à la coquille. Ensuite avec cette commande:
chown username:username .Xauthority
username
étant mon identifiant, j'ai résolu le problème.
J'ai traversé ce problème plusieurs fois et ce fut un problème différent à chaque fois. L’un des problèmes suivants pourrait être à l'origine de votre problème et vous pouvez utiliser l'interface de ligne de commande à l'aide de Ctrl+Alt+F1 (Remplacez F1 par F2, F3 .... si votre tty1 est occupé) pour essayer les solutions suivantes
nvidia-smi
pour accéder à l'interface de gestion du système NVIDIA. La sortie devrait être quelque chose de ce genre.Mon Sep 17 14:58:26 2018 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 390.87 Driver Version: 390.87 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GT 720 Off | 00000000:01:00.0 N/A | N/A | | 19% 35C P8 N/A / N/A | 543MiB / 980MiB | N/A Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 Not Supported | +-----------------------------------------------------------------------------+
Si vous ne pouvez pas y accéder, il y a probablement un problème avec vos pilotes graphiques.
lspci | grep VGA
.Sudo apt-get purge nvidia*
.Installez les pilotes en utilisant
Sudo add-apt-repository ppa:graphics-drivers
Sudo apt-get update
Sudo apt-get install nvidia-390
(Ou quel que soit le pilote compatible pour votre carte graphique)
Essayez un redémarrage en utilisant systemctl reboot -i
et espérez que votre boucle de connexion est corrigée.
ls -l /home
Sudo chown $USER:$USER $HOME
ls -l ~/.Xauthority
Sudo chown $USER:$USER ~/.Xauthority
Sudo mv ~/.Xauthority ~/.Xauthority.bak
ls -ld /tmp
et assurez-vous que les autorisations sont exactement drwxrwxrwt
name__. La sortie devrait être de cette sortedrwxrwxrwt 27 root root 36864 Sep 17 17:15 /tmp
Sudo chmod a+wt /tmp
dpkg-reconfigure lightdm
et essayez les autres gestionnaires d'affichage (gdm3, lightdm,) disponibles. Peut-être que cela vous donnera suffisamment d’indices pour avancer.Sudo apt-get install sddm
lors du dernier essai. reconfigurer l’affichage sur sddm.Si aucune des solutions ci-dessus ne fonctionne, vous pouvez essayer de réinstaller Ubuntu.
P.S: Ceci est une compilation des réponses des sources auxquelles j'ai fait référence, certaines de ce post aussi.
Je devais seulement changer les permissions de mon dossier personnel:
Sudo chmod 755 /home/<username>
Cela peut être fait en vous connectant à un terminal, en utilisant votre nom d'utilisateur et votre mot de passe dans un shell en utilisant CtrlAltF1.
J'ai eu la boucle de connexion en liaison avec une mise à jour d'Ubuntu 12.04 à 14.04. Avec gdm j’avais des messages d’erreur dans ~/.cache/gdm/session.log avec des entrées telles que /etc/gdm/Xsession: line 33: mktemp: command not found
et après Sudo aptitude purge gdm
avec lightdm j’ai reçu plusieurs messages d’erreur similaires dans ~/.xsession-errors
, par exemple, usr/sbin/lightdm-session: line 24: mktemp: command not found
.
J'ai essayé plusieurs choses. Ce qui, à mon avis, a finalement résolu le problème pour moi est le suivant:
J'ai déplacé mes fichiers de configuration .profile
, .bashrc
et .pam_environment
vers d'autres noms, puis j'ai réussi à me connecter. Je soupçonne qu'il y a un problème dans l'un d'entre eux.
Sudo chown $USER:$USER $HOME
était le problème pour moi.
J'avais mis en place une partition home avec:
Sudo mkdir /home/$USER
mais j'ai oublié de chown
it.
Cela peut aussi être dû à une combinaison spéciale de paramètres:
/home/$USER
crypté$USER
in nopasswdlogin
grouplightdm
essaiera de vous connecter, mais ne pourra accéder à aucun fichier pour que vous obteniez les symptômes décrits.
Pour résoudre ce problème, supprimez $USER
du groupe:
Sudo gpasswd -d $USER nopasswdlogin
J'ai eu le même problème après une nouvelle installation d'Ubuntu 12.10 (mais en réutilisant ma partition home existante). J'ai essayé toutes les autres réponses, mais aucune n'a fonctionné. Mais j'ai trouvé la clé de mon problème spécifique dans le fichier .xsession-errors de mon répertoire personnel.
Voici comment je l'ai résolu dans mon cas:
Frappé Ctrl+Alt+F1 ouvrir un terminal virtuel. Puis connectez-vous avec nom d'utilisateur et mot de passe.
Ouvrez le fichier ~/.xsession-errors
s'il existe (tapez cat ~/.xsession-errors
). Dans mon cas, ce fichier contenait une seule ligne avec un message d'erreur:
/ usr/sbin/lightdm-session: 27:.: Impossible d'ouvrir/usr/bin/byobu-launch
Maintenant, byobu
est un outil de ligne de commande que j'utilise et je ne sais pas du tout comment cela a abouti dans un fichier système puisque c'était juste après une nouvelle installation. Byobu n'étant pas installé par défaut, cela pourrait expliquer l'erreur car il recherche un fichier (/usr/bin/byobu-launch
) qui n'existe pas. Donc, dans mon cas, j'ai dû installer byobu
pour résoudre le problème:
Sudo apt-get install byobu
Frappé Ctrl+Alt+F7 pour revenir à l'écran de connexion, et la connexion a bien fonctionné maintenant.
Bien sûr, dans votre cas, vous pourriez trouver un message d'erreur différent dans .xsession-errors, qui nécessite une solution différente.
J'ai eu un problème très similaire où je pouvais me connecter au terminal, mais pas sur le bureau. Mon fond d'écran du profil était chargé lors de la connexion, mais après quelques secondes, il est revenu à l'écran de connexion. J'ai vérifié toutes les autorisations de fichiers comme suggéré, elles allaient bien. J'ai essayé sans partition d'accueil distincte et j'ai pu me connecter au bureau. Après cela, j’ai vérifié les paramètres de la partition d’origine chiffrée LUKS, qui étaient également satisfaisants (bien qu’il y ait des messages d’erreur sur le terminal, me disant que le volume chiffré ne pouvait pas être monté, car il était déjà monté).
Ensuite, j'ai examiné dmesg, trouvé des erreurs BTRFS liées au système de fichiers de la partition home chiffrée LUKS (ouais, je mélange LUKS et BTRFS), essayé d'écrire sur le système de fichiers et constaté qu'elle m'avait généré des erreurs d'E/S. J'ai donc dû réparer le système de fichiers ou en créer un nouveau et le restaurer à partir d'une sauvegarde.
Longue histoire courte: Regardez dmesg et essayez réellement d'écrire sur le système de fichiers qui semble être accessible en écriture.
J'ai trouvé que les paramètres d'autorisation de mon fichier /tmp
n'étaient pas corrects. Il avait des autorisations pour root uniquement.
C'était ma propre erreur. J'ai oublié qu'un jour plus tôt, j'avais supprimé le dossier /tmp
avec les droits Sudo
et après l'avoir recréé à nouveau avec Sudo mkdir tmp
. Grosse erreur. J'ai créé un dossier/tmp avec les autorisations root uniquement.
Dans le fichier ~/.Xsession-errors
, j'ai pu constater que x11 n'était pas en mesure d'écrire un fichier dans /tmp
. Après avoir exécuté ces commandes à partir du compte root (ou Alt+Ctrl+f1) dans l'écran de bienvenue et utiliser les informations d'identification du compte du problème pour vous connecter), j'ai résolu le problème:
Sudo chmod 1777 /tmp
Sudo chown root:root /tmp
Après cela, j'ai pu me connecter à nouveau à Unity avec le compte normal. Donc, si vous avez ce qui ressemble à un problème de .Xauthority
, vous pouvez essayer ceci si rien ne fonctionne.
J'ai dû faire face au même problème. Malheureusement, dans mon cas, le problème n’a pas été résolu simplement en modifiant les autorisations; ma contribution consistera donc à essayer de créer un guide, du plus simple au plus complexe. Espérons que vos utilisations seront résolues avec les plus simples.
Remarque: remplacez <username>
par votre nom d'utilisateur.
Hypothèses: Nvidia Graphic Card
, lightdm
Accès au terminal
Pour ouvrir un nouveau terminal, utilisez simplement (puis connectez-vous avec vos identifiants):
Ctrl+Alt+F1
Vérifiez le propriétaire/groupe/autorisations de vos fichiers de répertoire personnel
cd ~<username>
ls -lah
Fixe le propriétaire et le groupe de .Xauthority
et/tmp
chown <username>:<username> .Xauthority
Sudo chmod a+wt /tmp
Vérifiez s'il y a toujours un problème en redémarrant lightdm
Sudo service lightdm restart
Reconfigurer lightdm
dpkg-reconfigure lightdm
Sudo service lightdm restart
Si vous souhaitez voir les erreurs possibles du système
tail -n 50 /var/log/Xorg.0.log # if you want to see the last 50 errors
tail -f /var/log/Xorg.0.log # if you want to be able to see all new errors live
Fichiers journaux pertinents:
/var/log/Xorg.0.log
/var/log/lightdm/lightdm.log
En dernier recours, comme je l’ai fait, réinstallez les pilotes de la carte graphique. Nvidia
ne fonctionne tout simplement pas bien avec Ubuntu
.
J'ai rencontré le même problème et la cause dans mon cas est que j'ai essayé d'ajouter quelque chose au fichier /etc/environment
et que tout ce que j'ai ajouté semblait ne pas vouloir que je me connecte après avoir redémarré.
Quand à l'écran de connexion appuyez sur CTRL + ALT + F2. Connectez-vous avec le nom d'utilisateur et le mot de passe administrateur, éditez le fichier /etc/environment
et supprimez les modifications que vous y avez apportées.
Dans le terminal, vous pouvez exécuter la commande suivante, utilisez nano
pour éditer le fichier:
Sudo nano /etc/environment
Presse CTRL + o puis appuyez sur ENTER pour sauvegarder le fichier. presse CTRL + x sortir nano.
Une fois que vous avez édité et enregistré le fichier, appuyez simplement sur CTRL + ALT + F2 pour revenir à l'écran de connexion de l'interface graphique et vous devriez pouvoir vous connecter.
Cela m'est arrivé lorsque j'ai éteint l'ordinateur alors qu'il achevait encore de mettre à niveau les dernières images du noyau. Je ai fait CTRL-ALT F1, connecté, puis Sudo apt-get update
et Sudo apt-get dist-upgrade
et laissez-le terminer à la configuration.
Après le redémarrage, j'ai été capable de me connecter à nouveau à la destkop.
J'ai dû supprimer les pilotes NVIDIA pour pouvoir entrer, comme dans (remplacez nvidia-current par nvidia-340 ou quel que soit votre numéro).
Ensuite, j'ai eu un cadre UNITY buggy. Je devais suivre les étapes montrées ici pour les réparer:
Peut-être êtes-vous affecté par bug n ° 1240336 où différentes autorisations ont été supprimées après la mise à niveau de la version.
Autres effets indésirables
Je me connecte pour pouvoir travailler lorsque je mets l'utilisateur dans le groupe video
ou après avoir exécuté Sudo chmod a+rw /dev/dri/*
dans un terminal.
Mais:
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
en cours d'exécution donne: polkit-gnome-authentication-agent-1: 5805): polkit-gnome-1-WARNING **: Impossible de déterminer la session dans laquelle nous sommes: Aucune session pour le pid 5805Solution
Exécutez Sudo pam-auth-update --force
dans le terminal. Cela a résolu les problèmes décrits dans mes cas.
Passez à un autre écran de connexion.
Ctrl+Alt+F2 ouvrir un terminal.
Ctrl+Alt+F7 pour revenir au mode graphique.
Tapez Sudo dpkg-reconfigure gdm
Dans un écran graphique, sélectionnez GDM et OK.
Tapez Sudo reboot
Pour moi, la configuration de certains paquets était désactivée, donc en cours d'exécution (après ctrl
+ alt
+ F3
):
Sudo dpkg --configure -a
résolu le problème.
Juste au cas où changer les privilèges d'accès pour les fichiers .Xauthority
et .IDEauthority
avec la commande chown
ne fonctionnait pas pour vous:
Cette solution s’applique à ceux qui, outre le fait de devoir modifier les privilèges d’accès aux fichiers susmentionnés, ne peuvent pas utiliser les commandes comme ils le faisaient auparavant, c’est-à-dire que le shell ne les trouve pas. (C’est la raison pour laquelle la commande de connexion ne peut pas non plus être exécutée.)
Tapez echo $Shell
dans votre terminal. Si vous récupérez /bin/bash
, utilisez export PATH=$PATH:/usr/local:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
pour pouvoir utiliser temporairement des commandes.
Puis ouvrez votre fichier .profile
, situé dans votre répertoire personnel ~
, c.-à-d. /home/yourusername
avec Sudo gedit ~/.profile
et ajoutez les chemins manquants à PATH
, de sorte à ressembler à ceci:
PATH=/usr/local:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
Maintenant, redémarrez votre système pour que les modifications apportées à la variable d'environnement PATH prennent effet.
(Si les commandes ne sont pas reconnues par votre shell, vous pouvez également utiliser les chemins d'accès équivalents aux exécutables des commandes, par exemple, au lieu de Sudo gedit ~/.profile
tapez /usr/bin/Sudo /usr/bin/gedit ~/.profile
. Le shell vous indique le répertoire à utiliser, c'est-à-dire command
non trouvé, mais la commande votre essayez d'utiliser peut être trouvé dans /path/to/command's/directory
- pourrait être l'un des chemins que vous voyez ci-dessus.)
Si les autres questions n'aboutissent pas à une solution, ma suggestion est d'essayer de suivre ces étapes:
Connectez-vous en mode caractère avec un VC (console virtuelle). C'est, CtrlAltF1 et votre nom d'utilisateur/mot de passe Appelons cet utilisateur original
name__.
Créez un nouvel utilisateur. Vous pouvez utiliser par exemple :
adduser newuser --group Sudo
pour ajouter un nouvel utilisateur administratif (c'est-à-dire, un utilisateur pouvant faire Sudo
name__).
Essayez de vous connecter en tant que newuser
name__. Si cela fonctionne, vous dites maintenant que le problème réside dans la configuration spécifique de original
user. Sinon, arrêtez de lire ici - le problème concerne le système et vous devrez probablement réinstaller un élément de la pile graphique.
Maintenant, vous pouvez essayer de chercher ce qui est arrivé. Comparez les fichiers cachés dans ~original
et ~newuser
et essayez de trouver des incohérences. En particulier, vous devez rechercher des fichiers qui ne vous appartiennent pas:
find . \! -user original
et les fichiers qui ne vous sont pas écrits (il y en aura plus, surtout dans les caches):
find . \! -perm -u=w
Vous pouvez déplacer des fichiers suspects vers une sauvegarde (Sudo mv whatever whatever-backup
) et essayer de vous reconnecter.
Les fichiers dans /tmp
et /var
qui peuvent être sensibles à ce problème devraient être supprimés par un redémarrage --- mais il y a parfois des traces là-bas aussi.
En dernier recours, vous pouvez sauvegarder les informations importantes de original
(pas tout le répertoire home! Ou vous allez propager le problème), et le supprimer et le recréer, même s'il est préférable de pouvoir le trouver où le problème est.
Dans mon cas, mon dossier utilisateur a reçu chown
'ed par root! La réponse se trouve dans .Xauthority
et d’autres fichiers de votre dossier personnel; si les données de configuration de l'utilisateur ne peuvent pas être ouvertes en lecture/écriture, lightdm échouera.
Je, simplement ctrl+f1, connecté, puis Sudo chown /home/<userdir>
, puis Sudo service lightdm restart
(peut ne pas être nécessaire), puis j'ai pu revenir en arrière.
Certains messages de diagnostic seraient plus utiles, mais telle est la vie avec les logiciels libres.
Après avoir lu réponse de James , j'ai réalisé que j'avais changé le mot de passe de l'utilisateur en me connectant en tant que root. Je connaissais l'ancien mot de passe. Je me suis donc reconnecté en tant que root (pour vous connecter en tant que root, appuyez sur ctrl+alt+F3
et donnez le nom d'utilisateur en tant que root, puis entrez votre mot de passe root) et modifiez le mot de passe de cet utilisateur en ancien par la commande ci-dessous.
passwd <username>
Maintenant, changez le mot de passe en ancien, appuyez sur ctrl+alt+F7
et connectez-vous normalement. Cette solution ne fonctionne que si vous avez un problème de répertoire personnel chiffré et que vous avez modifié le mot de passe à l'aide de root.
J'ai trouvé un autre moyen de provoquer une boucle de connexion qui ne soit couverte par aucune de ces réponses, yay me!
J'avais un script pour configurer mes deux moniteurs qui était référencé dans /etc/lightdm/lightdm.conf
en tant que session-setup-script
. Lorsque je suis allé à une configuration de moniteur unique, j'ai supprimé le script, mais je n'ai pas supprimé la référence. La prochaine fois que j'ai démarré - boucle de connexion.
En examinant le fichier journal dans /var/log/lightdm/lightdm.log
, j'ai trouvé un message d'erreur explicite m'indiquant que le script était introuvable et que, par conséquent, lightdm n'a pas pu démarrer. Commenter la référence dans lightdm.conf
l'a corrigée.
Je rencontre le même problème plusieurs fois par semaine et j'ai essayé la plupart des solutions données ici, mais le seul moyen de me reconnecter est de redémarrer lightdm.
Sudo service lightdm redémarrer.
Ce qui est amusant, c’est que même après avoir restitué à lightdm, il ne se connecte pas à la première tentative, mais seulement à ma deuxième tentative, même si je saisis le bon mot de passe. Je m'en suis rendu compte il y a quelques semaines et je l'ai vérifié plusieurs fois en m'assurant de ne pas taper mon mot de passe par inadvertance. Je suis maintenant certain qu'il ne me connecte pas la première fois après le redémarrage de lightdm, mais uniquement à la deuxième tentative!
Je suis entré dans la boucle de connexion en exécutant le programme de mise à jour du logiciel le 18 janvier 2018 pour le 18.04. Il était très difficile d'entrer en mode terminal Ctrl+Alt+F1 ou F2 ou F3, ne réussissant généralement qu'après un certain nombre de redémarrages. Entrer en mode terminal par Ctrl+Alt+F3 n’est devenu fiable qu’après avoir installé lightdm et passé à celui proposé dans la réponse populaire ci-dessus. Les autres recettes standard (vérifier la propriété de .Xauthority et .ICEauthority et les autorisations de/tmp) étaient en ordre et le nettoyage du pilote nvidia n’a pas aidé. Après beaucoup de recherches sur Google, j'ai trouvé la suggestion de Khalil Laleh à l'adresse boucle de la fenêtre de connexion Ubuntu 18.04 pour vérifier les extensions de votre gnome. Bingo! Dans mon cas, la grille de travail de Zakkak = '[email protected]' dans le répertoire ~/.local/share/gnome-Shell/devait être supprimée pour que Ubuntu puisse enfin démarrer, puis être réinstallé à partir de - https://extensions.gnome.org restauré la présentation de mon espace de travail.
Concernant les utilisateurs de Gnome:
J'ai essayé toutes ces options en vain. Probablement en raison de l'utilisation de Gnome comme interface utilisateur préférée.
Après avoir regardé la réponse de Sooth , j’ai réussi à le connecter à l’interface utilisateur graphique ubuntu et xubuntu. Son message a donc aidé un spark dans mon cerveau.
Je n’ai rien vu qui soit lié à Gnome, j’ai donc cherché quelques instants et suivi ce guide de OMG Ubunt pour Gnome 3.2 sur Ubuntu 16.04.
Gnome fonctionnait parfaitement, alors je ne sais pas ce qui ne va pas un jour. C'est un peu un téléchargement et des mises à jour mais cela a fonctionné pour moi avec Gnome et je suis heureux sans la boucle de connexion de la mort!
Dans mon cas, cela était dû à un logiciel nouvellement installé par le biais du centre logiciel (ou de son surnom) appelé Brightness Control (Xrandr). Je me suis donc connecté à Ubuntu à l’aide de Unity à partir de la fenêtre de journalisation, puis j’ai ouvert le Centre de logiciel pour le désinstaller. Après le redémarrage, je pouvais me connecter à Ubuntu (Gnome).
Même problème sur plusieurs RPI (versions 2B et 3). Solution:
cat ~/.xsession-errors
. Le mien a montré:Xsession: la session X a commencé pour pi à ****
Xsession: impossible de démarrer la session X --- pas de fichier "/home/pi/.xsession", pas de fichier "/home/pi/.Xsession", pas de gestionnaire de session, pas de gestionnaire de fenêtre ni d'émulateur de terminal trouvé; avorter.
Sudo apt-get install xserver-xorg-core xserver-xorg-input-all \
xserver-xorg-video-fbdev libx11-6 x11-common \
x11-utils x11-xkb-utils x11-xserver-utils xterm lightdm openbox
Source: https://www.raspberrypi.org/forums/viewtopic.php?t=15419
Remarque: j'ai déjà utilisé les RPI avec le mode de connexion automatique et le mode non-gui. Ainsi, j'ai réinstallé lightdm et je me suis retrouvé confronté au problème de boucle de connexion après le passage au mode d'interface graphique de connexion automatique (raspi-config).
Je suis sûr que personne, sauf quelqu'un avec un cas extrême du problème, ne verra cela, mais si vous le faites ... cela aidera peut-être! :)
En ajoutant aux réponses actuelles - et en les construisant dans une large mesure, j’ai rencontré une ou deux fois le problème suivant: les fichiers other que .Xauthority
sont la propriété de root pour une raison quelconque. Cela peut créer des boucles de connexion, des problèmes avec les moniteurs secondaires et une foule d'autres problèmes. Pour localiser les fichiers suspects, exécutez:
user@hostname:~$ find -user root
À partir de là, vous devez en quelque sorte pêcher dans la sortie et voir si vous ne pouvez pas localiser quelque chose qui semble inhabituel.
En remarque, il indique également si .Xauthority
appartient à root ...
Les extensions GNOME-Shell installées sur le profil de l'utilisateur étaient apparemment à l'origine de la boucle de connexion en cas d'installation de Bionic Beaver ici. L'utilisateur peut à nouveau se connecter à son environnement graphique avec succès jusqu'à la suppression de toutes les extensions GNOME-Shell installées dans le profil utilisateur. Les éléments trouvés, puis supprimés de Bash étaient [email protected]
et [email protected]
.
Je crois avoir trouvé cette piste en examinant le journal systemd, il y avait aussi un signal dans l’adressage Web des extensions de Gnome Shell dans ce contexte ou dans un contexte proche.
Des problèmes ont commencé à se produire après l'installation des mises à jour de sécurité et de base au cours de la semaine calendaire n ° 3 de 2019. En réalité, aucune reconfiguration au niveau du système n'a été effectuée par l'utilisateur à cette époque.
Il reste maintenant deux extensions GNOME au niveau du système, car aucun moyen de les désinstaller n’a été trouvé. Cependant, ils sont désactivés. L'interrupteur principal des postes est également sur OFF. Peut-être qu'à moyen ou à long terme, j'essaierai d'utiliser de nouveau les extensions, mais en progressant avec prudence et par petites étapes.
Par conséquent, aucune des indications trouvées ici ne pourrait aider car les points sous-jacents étaient OK, par exemple. ~/.XAuthority, ~/.ICEAuthority, répertoire/tmp, pile Nvidia. L’approche lightdm n’était pas souhaitable car dans ce cas, Ubuntu 18.04 est utilisé et n’utilise pas lightdm par défaut. Il s’agit d’une installation exécutée dans VmWare-hypervisor, de sorte que la carte graphique émulée ne provient pas de Nvidia. Ces astuces ne pouvaient pas être appliquées ni aider. J'ai également été incapable de trouver dans la directive ~/xsession-errors.
J'ai trouvé l'approche de Rmano intéressante et j'ai appliqué ce qui, par conséquent, a révélé quelques autres points intéressants, qui seront soulevés dans de nouvelles questions. La suggestion de Rmano a également contribué au succès dans ce cas. Je vous remercie.
Si vous ne pouvez pas vous connecter, le disque/la partition de votre dossier de base est peut-être plein.
Pour savoir si votre disque/partition est plein: appuyez sur Ctrl + Alt + F3, identifiez-vous et tapez df
. Vous obtenez des informations sur l'espace disque utilisé.
Pour moi, la suite a fonctionné. Tapez ctrl + alt + F1
et connectez-vous avec votre nom d'utilisateur à la commande Invite.
user@Dell$ ls -l ~/.ICEauthority
-rw------- root root 3668 May 28 09:28 /home/user/.ICEauthority
user@Dell$ Sudo chmod 777 ~/.ICEauthority
password:
user@Dell$ ls -l ~/.ICEauthority
-rwxrwxrwx root root 3668 May 28 09:28 /home/user/.ICEauthority
ctrl + alt + F7
et la connexion ont fonctionné.
J'ai rencontré ce problème sur un Xenial installé sur une clé USB, monté sur un ordinateur portable sans HD, exécutant l'unité et le flashback gnome. J'ai essayé toutes les solutions de contournement ici sans succès, puis je me suis rappelé qu'il y a quelques jours, alors que j'étais en mode chroot et utilisant qemu, si je choisissais gnome-flashback-compiz, j'avais le problème alors qu'avec l'unité, je ne le faisais pas. Essayé avec gnome-flashback-metacity et cela a fonctionné.
Dans ce cas aussi, cela ne fonctionne pas avec gnome-flashback-compiz mais avec gnome-flashback-metacity et avec l'unité, cela a fonctionné.
Silvia
Dans mon cas, le problème était dû à des autorisations erronées sur mon répertoire personnel.
1: Démarrez depuis un média en direct (ou une autre distribution linux installée sur le même système) et ouvrez un terminal avec Ctrl-Alt-T
2: Créez un point de montage temporaire et montez la partition contenant votre/home (dans mon cas c'était/dev/sda6)
Sudo mkdir /mnt/sda6
Sudo mount /dev/sda6 /mnt/sda6
: vérifier les autorisations
Sudo ls - la /mount/sda6/
vous devriez voir une entrée nom d'utilisateur `où ( nom d'utilisateur est votre nom d'utilisateur
À partir de là, nous utiliserons le nom d'utilisateur tvbox (remplacez-le par votre nom d'utilisateur).
Vous devriez voir quelque chose comme ça:
drwxr-x--- 67 tvbox tvbox 12288 May 1 07:00 tvbox
Cela indique que tvbox est un répertoire et que le propriétaire dispose des autorisations de lecture, d’écriture et d’exécution requises.
4: autorisations correctes si incorrectes.
Si ce qui précède n'est pas correct, nous devons le corriger.
Si les données ont été déplacées par la racine, vous verrez la racine plutôt que tvbox. Tvbox (nom du propriétaire du groupe de propriétaires) Cela pourrait être appelé la "cause première" ;-)
Pour résoudre ce problème, utilisez la commande `Sudo chown -R tvbox: tvbox/mount/sda6/tvbox
Si, d'une manière ou d'une autre, les autres autorisations ne sont pas correctes, vous devrez les modifier avec Sudo chmod +rwx tvbox
en ajoutant des autorisations de lecture, d'écriture et d'exécution (le bit d'exécution d'un répertoire vous permet de le parcourir.)
5: redémarrer le système d'exploitation qui pose problème
6: connexion
Si cela ne résout pas votre problème, reportez-vous aux nombreuses autres réponses de qualité ici.
J'ai eu un problème similaire récemment. Ubuntu a fait des mises à jour et j'ai eu cette boucle de connexion qui semblait être liée à lightdm.
J'ai finalement réussi à résoudre le problème après avoir essayé plusieurs choses.
Je suspecte amdgpu d'être la raison de l'échec mais parce que je ne sais pas avec certitude, je vais tout poster, que j'ai essayé:
Tiré de ma question initiale sur askubuntu: voir ici
amdgpu-pro-uninstall
)À ce stade - après le redémarrage - mon clavier ne répondait plus, j'ai donc démarré en mode de récupération et sélectionné l'option de réparation des paquets cassés, ce qui a fonctionné et j'ai pu utiliser mon clavier à nouveau.
Malheureusement, la connexion ne fonctionne toujours pas. De plus, j'ai ajouté mon utilisateur au groupe lightdm, mais je doute que cela ait une importance quelconque.
Ensuite, j'ai trouvé d'autres problèmes similaires et essayé les étapes suivantes:
# as root
add-apt-repository ppa:paulo-miguel-dias/pkppa
apt-get update
apt-get upgrade
reboot
Toujours pas de succès jusqu'à présent, alors j'ai décidé d'essayer une autre méthode de mise à niveau
# as root
apt full-upgrade
reboot
Et puis j'ai pu me connecter à nouveau.
Ma conclusion personnelle
Il semble que le problème existe dans le pilote amdgpu et Ubuntu ne sera pas en mesure d’installer un pilote en état de marche à moins d’ajouter le ppa mentionné ci-dessus. Il dit de ne travailler qu'avec Ubuntu 18.04 mais je l’ai essayé quand même et cela a fonctionné pour le moment .
J'ai eu le même problème après avoir mis à niveau vers 12h10. Je suis ensuite venu ici de Google. J'ai créé un autre utilisateur et je pouvais me connecter.
Comme je n’utilise pas Unity, j’ai désinstallé lighdm. Après le redémarrage, je pouvais me connecter. Vous pouvez essayer ça.
Bonne chance!