2

I can't login in my gdm3 usual session and it goes [in loop like there]. I made sudo adduser test, and things go just fine with that user.

Before I got in that loop I did update/upgrade my system, install blueman, and edited iwlwifi files for slow connexion troubleshooting.

I since reversed the edit I made in that iwlwifi file, trying to resolve my login loop, and uninstalled blueman, I also purge gdm3 and install it back...

I installed lightdm to log in (it works, selecting lxde in the login screen...) but I'd really rather use gdm3.

I cannot login in both "Ubuntu" and "Ubuntu on Wayland" with that main account, but I do can in LXDE ; and with the testing account, I can login with Ubuntu and Ubuntu on Wayland.

I do have .Xauthority rights and I do have /tmp access right. Here's my .xsession-errors file

Any path I didn't think of ?

Edit : I'm Ubuntu 20.04 LTS / kernel 5.4.0-29 ; x86

UPDATE : I don't really know how, my guess is by

sudo apt purge gdm3 lightdm
reboot

sudo apt install gdm3
sudo apt install lightdm
reboot

I come to the lightdm login screen and, then, I can login to my usual user account just fine, as Ubuntu-defaut or Ubuntu on Wayland.

BUT if I run sudo dpkg-reconfigure gdm3 I get an error that gmd3 is not loaded. Ok then, I do it for lightdm then choose gdm3. I saw this trick sooner. Reboot, came to the gdm3 login screen. And it login loop again just as before.

On ttyX, I run again sudo dpkg-reconfigure gdm3 to select gdm3 properly. No luck after reboot.

I then, on ttyX, sudo dpkg-reconfigure lightdm and here I am. I can do with that, but it's unfortunate gdm3 seems to be broken, and I'd like to know why it is... I could login in LXDE with gdm3.

Improve this question
1
  • Which version of Linux and which release number is in use? Different releases have different tools. Please click edit and add that to your question; please do not use Add Comment as that's our one-way channel to you. – K7AAY May 17 '20 at 23:36
1

I had this problem and tried all the things you did. The culprit turned out to be a very long environment variable. My LS_COLORS env var was over 9000 characters long as is was generated from a dircolors database. As soon as I removed it I could log in again. In /var/log/syslog I was getting a segfault in libpcre.so.3.13.3. That env var must have been causing it to crash.

Improve this answer
3
  • Not the same issue, but mine was about a .bashrc alias for file.io CLI upload.. I found that when I changed my laptop and use the same .bashrc config. I didn't find why exactly, my syntax was correct. I say your answer is good because it's related. – B. du Garay Jul 9 '20 at 13:11
  • Further to @Falcon comment, the problem is not related to LS_COLORS specifically but to any env var that is very very long. – Paul Netherwood Jul 9 '20 at 21:49
  • If you do have problems with a long env var in your bashrc you can restrict the offending lines to be in a terminal sessions only by prefixing with if [[ "$TERM" =~ "xterm" ]]; then – Paul Netherwood Jul 11 '20 at 9:31
1

@paul-netherwood .. I tried removing the LS_COLORS With no Luck.. The only way I found working is

  1. Making a temp account and make it an Admin Using Terminal ctrl + alt + F3 and adduser
  2. If the new temp account logged-in using gdm3 with no problems.. Continue the with the steps
  3. Copy Main Account Data to it somewhere
  4. Deleting the Main Account and reboot
  5. Creating a User with the same information as the Main Account and Make it Admin
  6. Copy the Main User Data back to the newly created account
  7. Login using gdm3 login screen 'No Problem With login for me after that'.

This worked for me.. Best of luck

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.