1

I am running ubuntu 20.04 and running hardware with 2 AMD radeon vii GPUs.

I think this issue started when I recently plugged in the 2nd GPU.

I have this issue where I am stuck in a login loop. I am able to login via the terminal.

I have tried the following methods:

  • edit Xauthority
  • reinstall lightdm
  • edit grub config nomodeset
  • run xstart (this didnt work)
  • delete proprietary drivers (amdgpu-pro)
  • delete and update recent and or unnecessary dpkg packages
  • reinstall Ubuntu 20.04

I think I listed most advice people have given and those that I have tried.

I think I might have done editing the Xauthority wrongly because I saw somebody say that doing it on sudo defeats the purpose.

I am a little perplexed because my last choice was to fully flush the drive and reinstall Ubuntu and the same problem persists but less aggressively (less errors).

At this point I am thinking of buying a new drive bc maybe the drive is corrupted (I am using a bootable external ssd drive).

Do you guys have any other advice?

1 Answer 1

Reset to default
0

I ran into the same trouble.

I was using gdm3 with no problem. After booting due to some updates, I was unable to login, due to the login loop.

I tried more or less the same: validate .Xauthority permissions, /tmp permissions, review my nvidia drivers, remove all custom drivers and install again, remove gnome, remove lightdm, install lightdm (I got the same loop), install gdm3 again from scratch, ...

None of that worked.

Like you, when I went to the terminal and ran startx, I gained access to the X environment, but in a very ugly way, in the sense that, e.g. I couldn't open a terminal with CTRL+ALT+T.

Finally, my fix was super silly.

Of course it was a permissions problems: If you are able to startx from the command line but unable to start the session from the standard graphical login screen, something is there...

In my case, I had added a new entry on /etc/environment to change the PATH.

I had an entry on line 1 with something like:

PATH=/bin:/sbin:...

And the new entry was:

export PATH=$PATH:/newpath

It looks like export is causing the problem right here, as you only need to export for new variables, not for the existing ones.

Just removed the entry and everything worked fine!

4
  • That is not a permissions problem. Also, it's not related to which variables should be exported, although you are correct that variables already in the environment don't need to be exported again (updates to them automatically propagate to the environment & child processes). The problem is that /etc/environment isn't executed by Bash - commands like export can't be used and parameter expansion (the expansion of expressions like $PATH) doesn't work. You should normally use ~/.profile to set environment variables like your PATH.
    – Zanna ♦
    Commented Apr 8, 2021 at 8:46
  • Thanks Zanna for your comment. I considered a permissions problem in the sense that having the export in the /etc/environment makes whatever is parsing it to fail, and prevents the other path configurations to be loaded. Then, not having the path set, any X are working at all. Let's agree that is a configuration problem, then.
    – JBC
    Commented Apr 8, 2021 at 17:52
  • yes, I agree with that :)
    – Zanna ♦
    Commented Apr 9, 2021 at 3:11
  • Actually my issue was solved when I recovered startx in terminal. I had to edit the xstart conf to disable SNA. source: askubuntu.com/questions/714771/segmentation-fault-in-xserver
    – charlie090
    Commented May 1, 2021 at 13:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .