[nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login.

Bug #1845801 reported by Martin on 2019-09-28
324
This bug affects 57 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Critical
hugh chao
gdm3 (Ubuntu)
Low
Alberto Milone
Eoan
Low
Alberto Milone
gnome-session (Ubuntu)
Low
Alberto Milone
Eoan
Low
Alberto Milone
nvidia-graphics-drivers-390 (Ubuntu)
Low
Unassigned
nvidia-graphics-drivers-430 (Ubuntu)
Low
Unassigned
nvidia-graphics-drivers-435 (Ubuntu)
Low
Unassigned
Eoan
Low
Unassigned
nvidia-graphics-drivers-440 (Ubuntu)
Undecided
Unassigned

Bug Description

I just updated to the Ubuntu 19.10 beta. After boot, I'm shown the GDM login screen (which I shouldn't; I have auto login enabled), and logging in just takes me back to the same user selection screen even though the password is correct.

If I switch to a TTY and run `sudo pkill gnome-session-binary`, logging in through GDM starts working again.

I should add that the do-release-upgrade was rocky; I did it in a terminal from within gnome, went away for a while, and when I returned, I just saw an Ubuntu 19.10 in a TTY. I was able to do `sudo dpkg --configure -a` and complete the upgrade, but I don't know if something's still messed up due to that.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: xorg 1:7.7+19ubuntu12
ProcVersionSignature: Ubuntu 5.3.0-13.14-generic 5.3.0
Uname: Linux 5.3.0-13-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
.proc.driver.nvidia.gpus.0000.01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0000:01:00.0'
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.suspend: suspend hibernate resume
.proc.driver.nvidia.suspend_depth: default modeset uvm
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module 435.21 Sun Aug 25 08:17:57 CDT 2019
 GCC version: gcc version 9.2.1 20190909 (Ubuntu 9.2.1-8ubuntu1)
ApportVersion: 2.20.11-0ubuntu7
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sat Sep 28 19:55:42 2019
DistUpgraded: 2019-09-28 18:35:15,142 INFO cache.commit()
DistroCodename: eoan
DistroVariant: ubuntu
DkmsStatus: nvidia, 435.21, 5.3.0-13-generic, x86_64: installed
ExtraDebuggingInterest: Yes
GraphicsCard:
 NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. GP102 [GeForce GTX 1080 Ti] [1043:85e4]
InstallationDate: Installed on 2019-09-14 (13 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
MachineType: MSI MS-7A67
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-13-generic root=UUID=04974c80-e732-49b6-8148-c3dce7c02a25 ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
Title: Xorg crash
UpgradeStatus: Upgraded to eoan on 2019-09-28 (0 days ago)
dmi.bios.date: 01/25/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2.60
dmi.board.asset.tag: Default string
dmi.board.name: H270I GAMING PRO AC (MS-7A67)
dmi.board.vendor: MSI
dmi.board.version: 1.0
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: MSI
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2.60:bd01/25/2018:svnMSI:pnMS-7A67:pvr1.0:rvnMSI:rnH270IGAMINGPROAC(MS-7A67):rvr1.0:cvnMSI:ct3:cvr1.0:
dmi.product.family: Default string
dmi.product.name: MS-7A67
dmi.product.sku: Default string
dmi.product.version: 1.0
dmi.sys.vendor: MSI
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.99-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.1.6-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20190820-0ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

Martin (martid0311) wrote :

Please reproduce the failure again. That is to fail to log in. Then without killing anything, from a virtual terminal run:

  journalctl -b0 > failedlogin.txt

and attach the file 'failedlogin.txt' to this bug.

affects: xorg (Ubuntu) → gnome-session (Ubuntu)
tags: added: nvidia
summary: - Trying to log in just takes me back to the login screen. Killing gnome-
- session-binary fixes it.
+ [nvidia] Trying to log in just takes me back to the login screen.
+ Killing gnome-session-binary fixes it.
Changed in gnome-session (Ubuntu):
status: New → Incomplete
Changed in mutter (Ubuntu):
status: New → Incomplete
Martin (martid0311) wrote :

Here's the failedlogin.txt.

By the way, when turning off auto login, everything works normally; I'm greeted with the login screen when the machine boots, I type in my password, and I'm logged in successfully. It's apparently just after the first failed auto-login that subsequent logins don't work.

Also, after that first failed automatic login when auto login is enabled, if I switch to a TTY, my framebuffer will sometimes be filled by a low-res gnome desktop. I assume this is related, and it makes sense that gdm would be confused if there's indeed a running gnome session for my user which doesn't work.

Changed in gnome-session (Ubuntu):
status: Incomplete → New
affects: mutter (Ubuntu) → gnome-shell (Ubuntu)
Changed in gnome-shell (Ubuntu):
status: Incomplete → New
summary: - [nvidia] Trying to log in just takes me back to the login screen.
- Killing gnome-session-binary fixes it.
+ Automatic login fails and then all subsequent logins fail. Killing
+ gnome-session-binary fixes it, or just not using automatic login.

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gdm3 (Ubuntu):
status: New → Confirmed
Changed in gnome-session (Ubuntu):
status: New → Confirmed
Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Daniel van Vugt (vanvugt) wrote :

I wonder if it's a coincidence that both bug reports for this involve the Nvidia driver...

Ted Goddard (tedgoddard) wrote :

I will test with auto login turned off. Is there a different video driver setting that might be useful to test, like VGA only?

Ted Goddard (tedgoddard) wrote :

Confirmed: the user can successfully log in with auto login turned off.

Ted Goddard (tedgoddard) wrote :

Retested with Ubuntu 19.10 release. Auto login still causes login loop on above system. Disabling auto login allows login to work as expected.

Kashif Khan (kashifk) wrote :

I experienced this as well within a VM running Ubuntu 19.10. I have an Nvidia GTX 1060 card. I started the upgrade process to 19.10 and mid way the screen went blank with only a blinking cursor. Rebooted the machine and I was greeted with the login page, but when I logged in there was a screen that said "something went wrong" and logging out started the process again.

Rebuilt the VM and this time disabled Automatic login before starting the upgrade. The upgrade went flawlessly and finished.

dehein (dehein) wrote :

Nvidia GTX1060 proprietary driver. After upgrade i had to disable the autologin via command line:
press ctrl + alt + F3
login with username
now my background and steam where always shown, just type in everything even if you dont see it.
edit with nano or however /etc/gdm3/custom.conf and comment out the login data. if you can't see whats in the editor, use the arrow keys to the right and it will gradually start to show (at least it does in nano).

Basically it is a breaking bug for me and would easily drive away any noob user. I think this should have a much higher priority ASAP.

summary: - Automatic login fails and then all subsequent logins fail. Killing
- gnome-session-binary fixes it, or just not using automatic login.
+ [nvidia] Automatic login fails and then all subsequent logins fail.
+ Killing gnome-session-binary fixes it, or just not using automatic
+ login.
tags: added: rls-ee-incoming
tags: added: rls-ee-tracking
removed: rls-ee-incoming
tags: removed: rls-ee-tracking
Changed in gdm3 (Ubuntu Eoan):
assignee: nobody → Iain Lane (laney)
Valtteri Vainikka (vrln) wrote :

I'm also experiencing this bug with Nvidia GTX 1080 using the proprietary driver version 435.21. Issue persists with other driver versions as well. Currently using the same temporary fix as dehein mentioned, turning the automatic login off manually through editing the GDM config file. When fixing the issue this way via TTY I'm also seeing graphical corruption artifacts from the stuck Gnome session desktop that I cannot enter.

When switching to the open source Nouveau drivers I can leave automatic login on without any issues, everything works fine. So in my case this issue seems to be tied to the Nvidia drivers. Also tried to search more online about this issue and most mentions seem to be from Nvidia users.

I don't really have anything new to add as everything I thought of has already been reported here, but let me know if I can help in any way.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gdm3 (Ubuntu Eoan):
status: New → Confirmed
Changed in gnome-session (Ubuntu Eoan):
status: New → Confirmed
Changed in gnome-shell (Ubuntu Eoan):
status: New → Confirmed
Iain Lane (laney) wrote :

I tried here to reproduce it with 390, and 435, but I'm afraid that automatic login on both worked with me just fine. I don't see anything particularly out of place in the journal log either.

So I've asked Alberto (our NVidia maintainer) if he can take a look; maybe he'll have some luck making it happen.

Changed in gdm3 (Ubuntu Eoan):
assignee: Iain Lane (laney) → Alberto Milone (albertomilone)
dehein (dehein) wrote :

Well after commenting out the lines in /etc/gdm3/custom.conf and rebooting it worked for me. But currently i can not reenable the automatic login again. No matter what i do. Remove the comments, enable the option in the users menu. nothing works. even enabling the option in the users menu does little and after clicking away it does not save it.

Sami Karhula (gskarhu) wrote :

Restarting gdm3 seems to be a workaround if autologin is needed. I entered that into /etc/rc.local and after gdm restarts autologin enabled user will be logged in normally.

dehein (dehein) wrote :

Sorry. Had an error in my custom.conf
Also I found a workaround. Enabling the times login inside the config file works great.

Paul Berkx (pbrk) wrote :

Same issue:got referred to this place on https://askubuntu.com/questions/1183880/19-10-automatic-login-doesnt-work-for-me-when-im-on-a-nvidia-driver-and-cannot

---

On the X.Org X server - Nouveau display driver automatic login does work, but as soon as i use nvidia 435, 430 or 390 i get stuck with a login screen that wont log me in.

I've had no issues that resembles this on ubuntu 19.04.

It's not that big of deal (having to enter my password i mean), but if there is something i can do to solve this i would love to be in the know.

Update: So i decided to connect the tv directly to the pc the resolution was reset to full hd and now i couldn't enter the desktop even without automatic login disabled. So i entered recovery mode > followed by the resume normal boot procedure and now i could get back in, so i tried automatic login again, and yeah, no go on entering my desktop, so back to recovery mode and the resume normal boot procedure... To my surprise i was treated to an automatic login, but i didn't last, because when i rebooted there was the same problem again.

Thanks for reading.

i7 6700K MSI master M7 Z170 16GB DDR4

nVidia 1030GT hooked up through hdmi 2.0 on an Onkyo TX-NR646 receiver that leads me to a 4K philips TV. Same issue with a 960GTX by the way.

Resolution: 3840 x 2160 (16:9) @60Hz @200% scale

drivers nvidia login 19.10

Changed in gdm3 (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
Changed in gnome-session (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
Changed in gnome-session (Ubuntu Eoan):
assignee: nobody → Alberto Milone (albertomilone)
Changed in gnome-session (Ubuntu):
assignee: Alberto Milone (albertomilone) → nobody
Alberto Milone (albertomilone) wrote :

Unfortunately, I can't reproduce the problem on my system, running the 435 driver in 19.10.

What I don't see on my system is the following error from logind:

Oct 02 21:53:45 magni /usr/lib/gdm3/gdm-x-session[1220]: (EE) Error systemd-logind returned paused fd for drm node

Compare this from Martin's journald log:

Oct 02 21:53:45 magni /usr/lib/gdm3/gdm-x-session[1220]: (II) xfree86: Adding drm device (/dev/dri/card0)
...
Oct 02 21:53:45 magni /usr/lib/gdm3/gdm-x-session[1220]: (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 1
Oct 02 21:53:45 magni /usr/lib/gdm3/gdm-x-session[1220]: (EE) Error systemd-logind returned paused fd for drm node
Oct 02 21:53:45 magni /usr/lib/gdm3/gdm-x-session[1220]: (II) systemd-logind: releasing fd for 226:0
Oct 02 21:53:45 magni /usr/lib/gdm3/gdm-x-session[1220]: (--) PCI:*(1@0:0:0) 10de:1b06:1043:85e4 rev 161, Mem @ 0xde000000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x0000e000/128, BIOS @ 0x????????/131072
Oct 02 21:53:45 magni /usr/lib/gdm3/gdm-x-session[1220]: (II) LoadModule: "glx"

With what happens on my system:

ott 30 11:38:49 intel-latest /usr/lib/gdm3/gdm-x-session[2043]: (II) xfree86: Adding drm device (/dev/dri/card0)
ott 30 11:38:49 intel-latest /usr/lib/gdm3/gdm-x-session[2043]: (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0
ott 30 11:38:49 intel-latest /usr/lib/gdm3/gdm-x-session[2043]: (--) PCI:*(1@0:0:0) 10de:1b80:10de:119e rev 161, Mem @ 0xf6000000/16777216, 0xe0000000/268435456, 0xf0000000/33554432, I/O @ 0x0000e000/128,
ott 30 11:38:49 intel-latest /usr/lib/gdm3/gdm-x-session[2043]: (II) LoadModule: "glx"

I could be an bug in logind.

Balint Reczey (rbalint) wrote :

There is a systemd 243 build in
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3801 for Eoan, it may worth a shot to try it, but it looks like an issue with nvidia's drivers rather than a bug in systemd.

anidotnet (anidotnet) wrote :

I want to add further details here. I have GeForce GTX 550 Ti card. When I was in 19.04, there was no such issue. After upgrading to 19.10 I started facing this auto login issue. No version of nvidia driver can solves this (both older or newer).

When I moved to Nouveau driver, this particular autologin issue disappears, but sometimes my system freezes totally. I mean I can't even access keyboard or mouse. I have to do hard reboot. This freezing issue is intermittent and was not there when I was on 19.04. Not sure if this issue is related or not, but want to put my 2 cents here if it helps.

On a separate note, I never have experienced a ubuntu upgrade going smoothly. Everytime there are some glitches and OS slows down a bit after every upgrade. It is very annoying for a daily driver setup like mine. I mean it is okay when you are using it occasionally for fun, but for daily driver fresh install is not an option every time. There are visible differences between fresh install and upgrade. Whenever a new release comes I have a dilemma, should I upgrade or ignore? If I upgrade God knows what will break? This situation never improves.

François Bouffard (fbouffard) wrote :

This is mostly a "mee too" post. Using a GTX 1060. The upgrade to 19.10 did not go well, stuck with graphical artifacts after a reboot. Further reboots were met with kernel panics. Finally managed to boot kernel 5.0 in safe mode and finish the installation by choosing the "repair packages" option. Was met with this autologin bug after (thanks to the thread starter for noting that -- it was not clear autologin was the culprit).

An additional detail: now I seem stuck with the 430 drivers. I cannot upgrade to 435 because of "unmet dependencies" errors. Not sure if this could be related given that clearly the nVidia drivers are involved in this mess.

Simon Lord (ubuntwoone) wrote :

Created an account just to confirm I too am hit with this bug.

Started as 19.04 running on Ryzen 2700X, 32G, RTX2060 with nVidia 430 drivers.

After successfully upgrading from 19.04 to 19.10, or so I thought, I was met with the login screen upon system reboot. This was very strange as I had auto-login set to true with 19.04 so I should *not* be seeing this login screen.

My linux-fu is weak as I'm currently transitioning from OS X to Linux and was completely lost on how to continue. The solution was to go scorched earth and do a clean install of 19.10. My /home directory is on a separate drive so I was confident things would work out ok.

The clean install went well but at this point I was still unaware that the issue was related to the auto-login (and perhaps nvidia 435 combo). So after modding my fstab and rebooting I was confronted again with the login screen and not being able to login (ie, no matter how many times I typed my password the login screen would ignore me).

After some Googling I discovered this page you are reading now.

I did another clean install but this time I mv'd .config and .local in my /home directory to borked.config and borked.local (as mentioned, my linux-fu is weak but I assumed that my previous auto-login setting is stored in a pref file *somewhere* in either of those directories).

After updating fstab I then toggled the auto-login a few times to ensure the prefs would show it clearly in the OFF position. Then I rebooted.

SUCCESS. The login screen appeared but this time I *was* able to login — I spent another hour moving files from my *borks* back to .config and .local and I'm mostly back to normal.

As mentioned by anidotnet above, this is my second update (18.04 > 18.10 && 19.04 > 19.10) and both were extremely unpleasant with this latest update taking the cake.

Sebastien Bacher (seb128) wrote :

setting to incomplete until we get testing feedback from the ppa pointed out in comment #23

Changed in gdm3 (Ubuntu):
status: Confirmed → Incomplete
Changed in gdm3 (Ubuntu Eoan):
status: Confirmed → Incomplete
Changed in gnome-session (Ubuntu):
status: Confirmed → Incomplete
Changed in gnome-session (Ubuntu Eoan):
status: Confirmed → Incomplete
Changed in gnome-shell (Ubuntu):
status: Confirmed → Incomplete
Changed in gnome-shell (Ubuntu Eoan):
status: Confirmed → Incomplete
Martin (martid0311) wrote :

I just updated to systemd 243 from that place and enabled auto login. It had no effect; login fails just like with systemd 242.

Martin (martid0311) wrote :

Sorry, I wrote that comment from my phone and it changed "PPA" to "place" without me noticing.

Sebastien Bacher (seb128) wrote :

Thanks for testing, could you add the journalctl log from that session?

Changed in gdm3 (Ubuntu):
status: Incomplete → New
Martin (martid0311) wrote :

It seems like Ubuntu now freezes when I try to switch to a TTY when auto-login is enabled and has failed. This also happens with systemd 242 now though, so it must be some unrelated change. I got the log though, thanks to journalctl saving logs from previous boots, and attached failedlogin2.txt.

Interestingly, when booting from recovery mode, when just resuming normal boot from the recovery menu, auto login works perfectly. After that, I tried messing with grub options, and when I remove "splash" from the linux cmdline, auto login works perfectly. I assume then that this issue is related to how the GPU is initialized during early boot to show the splash screen? (For the record, I tried to set my cmdline to "quiet splash nomodeset", and it had no effect.)

Paul Berkx (pbrk) wrote :

I too ran

sudo add-apt-repository ppa:ci-train-ppa-service/3801
sudo apt-get update

(new system d was installed)

I can second it had no effect; can't login after autologin has been turned on and it sure does no automic login, the only option i know from there is to boot from recovery mode and then disable autologin again.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gdm3 (Ubuntu):
status: New → Confirmed
Valtteri Vainikka (vrln) wrote :

I think Martin on to something concerning GRUB/Linux boot options, more specifically the "splash" one. With testing-updates enabled what currently happens for me:

If I set automatic login on I'm stuck with the standard infinite login loop, but with the distinction that I can now no longer enter another TTY via ctrl+alt+F3 for example to fix it straight away. The whole system now just freezes, so I fixed it via recovery mode.

Out of curiosity I then went and disabled the following line in /etc/default/grub and ran "sudo update-grub":

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Result: Automatic login now works perfectly, no issues anymore.

Paul Berkx (pbrk) wrote :

Indeed, thanks

Olivier Robert (novhak) wrote :

Interesting. Just my two (Euro) cents, could that be related to the Nvidia drivers being loaded early in the boot process, and being in the initramfs ?

Imho, the only things that should reside in the initramfs are the tools needed for the kernel to get access to the root filesystem, period. No need for fancy graphics before that, and I'm sure even people encrypting their root fs could be happy with an "ugly" password prompt. I mean, fancy graphics are nice, but that's worth nothing if the system is unbootable, and playing with the early boot process shouldn't be done lightly.

I too had problems with my system being unbootable after upgrade (related to the Nvidia driver too), and among other things I removed everything that was setting the FRAMEBUFFER initramfs option, because that's what brings the Nvidia driver in the initramfs. I wasn't sure that solved my problem though, but now that I read that removing the splash option from the kernel command line solves a similar problem, I'm thinking about it again...

On my laptop, two files were setting the FRAMEBUFFER option : /etc/initramfs-tools/conf.d/splash that was created upon installing the MATE desktop environment, and a configuration hook script that was installed by the crypsetup-initramfs package. I removed the first file and purged the crypsetup-initramfs package, and got no more Nvidia GPU driver in the initramfs !

Olivier Robert (novhak) wrote :

s/crypsetup-initramfs/cryptsetup-initramfs

Edgar Bonet (linu7) wrote :

Having the exact same issue here:

 - NVIDIA GeForce GTX 1050 Ti
 - NVIDIA Driver Version: 430.50

System utterly broken after upgrade from 19.04 (kernel panics), managed
to kind of repair it, then this infinite login loop. I could get out of
the loop by logging in another virtual console, then typing

    sudo systemctl restart display-manager.service

Now I tried Valtteri Vainikka's workaround, and it worked wonderfully.
Thanks!

Edgar Bonet (linu7) wrote :

Today, after an `apt upgrade' that brought me an updated grub, the
problem came back. I logged on the second virtual console, edited
/etc/default/grub, and found a new instance of the line

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

I commented it out, typed `sudo update-grub`, then `sudo reboot', and
everything seems fine again.

Why did this line ever come back after I removed it? I grepped my way
around the system files in search for an answer and found a likely
culprit to be `/var/lib/dpkg/info/grub-pc.postinst'. I don't quite
understand what this post-installation script does, but it kind of looks
like it is putting into /etc/default/grub some settings that come from
debconf.

I then ran `sudo dpkg-reconfigure grub-pc' and, when prompted from
the default Linux command line, the text field was pre-filled with
"quiet splash". I emptied it and left the other settings untouched.
Now, my /etc/default/grub contains the line:

    GRUB_CMDLINE_LINUX_DEFAULT=""

I hope the fix is definitive now. We'll see on the next upgrade of the
grub packages.

Mario Kleinsasser (m4r10k) wrote :

Sadly, I am not having Nvidia drivers installed and the fix about

   GRUB_CMDLINE_LINUX_DEFAULT=""

doesn't work either for me. The only way I was able to suspend the login loop was to uninstall gdm3 and switch back to lightdm.

I think it is not useful that I open up a new issue therefore I am posting my comment here. To sum it up: If I like to use gdm3 I am unable to login.

Note: This is an upgraded laptop from 19.04 -> 19.10.

Rick (rickandtired) wrote :

I'm having this login loop issue.

Fresh install of 19.10 booted the first time fine, after the first update and reboot I started getting the login loop.

I'm using an Nvidia GT-1030 and installed the proprietary drivers during the install.

I removed quiet splash and added nomodeset to grub and that fixed the issue for me.

Rick (rickandtired) wrote :

I did some more testing and just removing splash fixes the issue for me.

I edited

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

sudo update-grub

Changed in gnome-session (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
Changed in gnome-shell (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
Changed in gnome-shell (Ubuntu Eoan):
assignee: nobody → Alberto Milone (albertomilone)
Bart (misterbart) wrote :

Problem as described by topic starter also appeared on two computers of mine:
1) An old laptop (Core2Duo and Nvidia GTX260M), that uses Ubuntu from 2015 onwards.
2) A newer desktop (Corei5, Intel graphics card), which started with Ubuntu 19.04. Performed the release upgrade one week after the laptop.
What these two computers have in common, and in common with the other poster: automatic login.
My fix followed the steps of https://askubuntu.com/a/346795 (resume after failed release upgrade):
$ sudo apt-get install -f
$ sudo dpkg --configure -a
$ sudo apt update
$ sudo apt dist-upgrade
$ reboot

It's an error that probably scares new users, so idd, I think it should receive high priority.

Anatoly (ubuntusiast) wrote :

on my two machines, on radeon graphics the bug does NOT reproduce, on nvidia graphics card the bug DOES reproduce.

Tizzy (salterio) wrote :

Hi, i'm running Ubuntu 19.10 on a Thinkpad L530 with automatic login enabled. I hadn't made any changes to my computer's settings but when I powered the laptop on today, I ended up with the login loop in gdm3. What I did was switch to a new terminal with Ctrl+Alt+F2, log in there, update apt, install lightdm, and switched to lightdm for login. I then rebooted, entered my password on lightdm and was back to work.

Daniel van Vugt (vanvugt) wrote :

I wonder if this is a distant relation to bug 1716857, whereby Nvidia fails to expose any monitors leaving Xorg unusable.

Changed in gdm3 (Ubuntu):
importance: Undecided → Low
Changed in gdm3 (Ubuntu Eoan):
importance: Undecided → Low
Changed in gnome-session (Ubuntu):
importance: Undecided → Low
Changed in gnome-session (Ubuntu Eoan):
importance: Undecided → Low
Changed in gnome-shell (Ubuntu):
importance: Undecided → Low
Changed in gnome-shell (Ubuntu Eoan):
importance: Undecided → Low
Changed in nvidia-graphics-drivers-435 (Ubuntu):
importance: Undecided → Low
Changed in nvidia-graphics-drivers-435 (Ubuntu Eoan):
importance: Undecided → Low
Changed in nvidia-graphics-drivers-435 (Ubuntu):
status: New → Confirmed
Changed in nvidia-graphics-drivers-435 (Ubuntu Eoan):
status: New → Confirmed
Daniel van Vugt (vanvugt) wrote :

Set to priority Low since you need to be using both the Nvidia proprietary driver and automatic logins to hit this bug.

no longer affects: gnome-shell (Ubuntu)
no longer affects: gnome-shell (Ubuntu Eoan)
Changed in nvidia-graphics-drivers-430 (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Changed in nvidia-graphics-drivers-390 (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Daniel van Vugt (vanvugt) wrote :

Sorry about the noise. I have shotgunned a more appropriate set of packages related to this bug.

Changed in gdm3 (Ubuntu Eoan):
status: Incomplete → Confirmed
Changed in gnome-session (Ubuntu):
status: Incomplete → Confirmed
Changed in gnome-session (Ubuntu Eoan):
status: Incomplete → Confirmed
Changed in systemd (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Gustavo Poveda (dominusbelial) wrote :

 I just killed my workstation with autologin o/ I went back to the original state by commenting both AutomaticLogin lines on /etc/gdm3/custom via ssh, it was the only way to log in!

Martin (martid0311) wrote :

@vanvugt: Actually, the only things necessary to trigger this bug (and thus leave your computer useless) is to install Ubuntu, with auto-login enabled, and an nvidia card in your computer. The proprietary drivers aren't necessary.

Considering nvidia's market share (80% according to the steam hardware survey, which will be skewed towards people with discrete GPUs, but still), I think giving this issue a priority of low is wrong.

I think preventing people from bricking their systems should be given a higher priority. Maybe add a feature in the installer to detect if someone has an nvidia GPU, and prevent them to enable auto login if they do. Or maybe remove "splash" from the kernel CLI args for people with an nvidia GPU by default.

Daniel van Vugt (vanvugt) wrote :

> Considering nvidia's market share (80% according to the steam hardware survey, which will be skewed towards people with discrete GPUs, but still), I think giving this issue a priority of low is wrong.

That might be true for gaming machines but I don't think that's an accurate figure for machines running Ubuntu. I don't have the stats handy but what we see in bug reports is that Intel-only graphics is the most common type of machine.

I'm not saying this bug won't be fixed, but to suggest most Ubuntu machines have Nvidia GPUs is incorrect.

Alberto Milone (albertomilone) wrote :

@Martin: comment #13 says that autologin works without problems with nouveau.

@all: are you able to use auto-login if add the following line to your /etc/X11/Xwrapper.config and reboot?

needs_root_rights = yes

Rick (rickandtired) wrote :

@albertomilone: That does not work. I still cannot auto-login after adding

needs_root_rights = yes
in /etc/X11/Xwrapper.config

Alex (aymkin) wrote :

I had the same issue and I had to reinstall 19.04, but anyway I want to use the latest Ubuntu, so I afraid to install it again.

Question: How can I check compatibility before updating?

Paulo Narciso (p-narciso) wrote :

Is this going to be fixed in 20.04?

Laguna Thanga (laguna-thanga) wrote :

How to find out who submitted this code that broke the system?

I wonder weather this is intentional by competitors

I am currently having this issue.
The issue = Login Loop.

Distro: Ubuntu 19.10

As a temporary solution, I am using Lightdm instead of default GDM3.
Is there anything that I can help, do let me know.

Note: I don't even have any NVIDIA stuff.

Balint Reczey (rbalint) wrote :

Marking as invalid for systemd since there is not much pointing at systemd here.

Changed in systemd (Ubuntu):
status: Confirmed → Invalid
Balint Reczey (rbalint) on 2020-03-31
Changed in systemd (Ubuntu):
status: Invalid → Confirmed
status: Confirmed → Invalid
status: Invalid → Incomplete
Thomas (ng0177) wrote :

Same issue here (NVIDIA GTX1060) and related bug 1869565; solved by 20.04 daily w/o propriety driver during install for now.

Béné (bene-d) wrote :

I have the same issue on a fresh install of the Focal Beta.

Using a GTX1060 with any proprietary drivers (I tested 440, 435, 390) breaks autologin.

Removing "splash" from /etc/default/grub and doing "sudo update-grub" fixes it.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1845801

tags: added: iso-testing
Rajat Pandita (rajat-pandita) wrote :

Fresh install with proprietary driver’s installation check box ticked worked fine till I rebooted again and then I could not get into the desktop. All drivers installed fine but one reboot later things were back to being unable to login. So I did a chroot and removed splash from grub command line followed by update grub and I Am back in business

Rick (rickandtired) wrote :

20.04 beta still has this issue for me

Jack Howarth (jwhowarth) wrote :

20.04 RC shows the same problem with the nvidia-340 drivers on a MacPro 3,1 with Mac ROM'd GTX680. The autologin is ignored and the greeter is shown instead. While the login works fine at the point, restarting then causes the system to hang rather than completing the restart.

Jack Howarth (jwhowarth) wrote :

Confirmed that setting 'WaylandEnable=false' in /etc/gdm3/custom.conf under 20.04 has no impact on the autologin bug with nvidia-340.

Jack Howarth (jwhowarth) wrote :

This bug is definitely triggered by the built kernel image loading the nvidia drivers. The autologin failures and associated hangs on restarts can be suppressed as follows...

1) Edit /etc/config/grub to remove 'splash' from GRUB_CMDLINE_LINUX_DEFAULT
2) Regenerate /boot/grub/grub.cfg with 'sudo update-grub'
3) Regenerate the initrd.img files by using 'sudo apt-get --reinstall install' to reinstall the currently installed kernel packages.

After rebooting, the autologin feature in gdm3 can be reselected and on the next reboot, it will autologin as expected. No loading the nvidia module through initrd.img also eliminates the hangs on restarting while autologin is enabled.

I suspect the folks who thought removing splash from grub.cfg didn't work had failed to rebuild the initrd.img files after regenerating grub.cfg.

Jack Howarth (jwhowarth) wrote :

Couldn't the nvidia packages all be modified to prune 'splash' from /boot/grub/grub.cfg prior to rebuilding its kernel modules and thus regenerating the initrd.img files?

Rajat Pandita (rajat-pandita) wrote :

Did a Fresh Install today, and Selected the option to automatically install proprietary drivers, Something changed and my Installation Failed, I got a message saying that there was already a bug for that, I followed along and updated my situation in that bug report, because why not, It is just a 2 Minute Job.
So this time around I changed the kernel parameters before installing Nvidia Drivers using the ubuntu-drivers autoinstall command. I edited by /etc/default/grub and I added nvidia-drm.modeset=1, Did not remove splash or any other parameters.

I then ran sudo ubuntu-drivers autoinstall and waited for that to finish,

Once done, I ran sudo update-grub.

Then rebooted.
This way I now have the flicker free boot/Animation and I can get into the desktop without any issues, GDM autologin works absolutely fine. I rebooted again just to be sure, and things stayed good.

I wanted to update here so others can benefit while the bug is addressed. This is a working solution for me. I have a GTX 1070 CPU.

Martin Vernay (magean) wrote :

@Rajat Pandita: awesome, thanks for sharing!

I came here to report that I too was experiencing this bug: GTX 1060, up-to-date Focal Fossa beta, NVidia 440 driver series, 5.4.0-24 kernel. Couldn't log in.

Removing `splash` from grub's kernel parameters solved the issue, but adding `nvidia-drm.modeset=1` is a much better solution since it leaves the splash screen unaffected (so you get a nice-looking boot). Besides, I remember from using KDE on Archlinux that `nvidia-drm.modeset=1` is required to get decent performance from NVidia drivers on KDE (though on Ubuntu I'm using Gnome).

The driver install script should really edit and update grub configuration accordingly.

Daniel van Vugt (vanvugt) wrote :

Note that we don't recommend use of nvidia-drm.modeset=1 for most users because it still results in some bugs:

  https://bugs.launchpad.net/ubuntu/+bugs?field.tag=nvidia-drm.modeset

And I'm not sure that's even a complete list. So you should be aware of what you're getting into.

Daniel van Vugt (vanvugt) wrote :

And yes nvidia-drm.modeset=1 will give you back the missing boot animation, but that discussion should stay in bug 1868240.

Rajat Pandita (rajat-pandita) wrote :

@Daniel Van Vugt. I appreciate your feedback, and I do very much appreciate it, However I think it is worth a try. I think it is more of Nvidia screwing with us rather than we creating problems for ourselves, It is like a chicken and and egg situation, You enable nvidia-drm.modeset=1 and then you have flicker free boot and potential to suffer from other bugs (Most of them are unconfirmed for the want of testing). Or you can not do anything and suffer this bug. then go and remove splash and from kernel parameters and go on with your life, However in either Case Nvidia needs special treatment from someone, because there is still more than 75 % Linux users using Nvidia, and would expect Flicker Free boot to work or atleast be able to login after installing the nvidia drivers.

Daniel van Vugt (vanvugt) wrote :

The actual proportions of Ubuntu users with Nvidia are:

21.94% in Ubuntu 18.04
24.10% in Ubuntu 19.10

And even fewer will be using automatic login.

So to say that most users have Nvidia is false. And to imply that even most Nvidia users can't login is false.

Daniel van Vugt (vanvugt) wrote :

24.38% in Ubuntu 20.04

Balint Reczey (rbalint) on 2020-04-20
Changed in systemd (Ubuntu):
status: Incomplete → Invalid

I have clean installed 20.04 development daily built for 23rd March and everything was working fine.
Then i updated my Ubuntu to 20.04 beta release and now i cannot login in GDM(auto logging is disabled , after i enter my correct password it redirects me to login screen)
I have 2070 super with NVIDIA 440 drivers.

Alberto Milone (albertomilone) wrote :

I have just updated an Eoan installation to Focal, enabled auto-login, and I can't reproduce the problem. I am using the 440.64 driver, and nvidia-drm.modeset is disabled. I can also see the bootsplash.

Daniel van Vugt (vanvugt) wrote :

vijay, the problem you describe in comment #78 is not this bug. Please open a new bug for that by running:

  ubuntu-bug gnome-shell

Daniel van Vugt (vanvugt) wrote :

Alberto, make sure it's an Nvidia-only system. Not a hybrid.

Martin (martid0311) wrote :

I can confirm that auto-login with the kernel parameters "quiet splash nvidia-drm.modeset=1" works without issues, and that auto-login with just "quiet splash" is still broken for me. This is with a GTX 1080Ti now running nvidia-driver-440.

suKo (suko) wrote :

Using an NVIDIA GTX 1080 on 20.04 with the latest daily image I can confirm this bug still exists. Removing the "splash" option from the /etc/default/grub file variable GRUB_CMDLINE_LINUX_DEFAULT seems to fix the issue. I too encountered this with automatic boot enabled, and it also occurs no matter which version of the NVIDIA driver I use (except for the FOSS driver). Unusually, this does not occur on my laptop which also has an NVIDIA GPU (in this case, a 1650).

Alberto Milone (albertomilone) wrote :

@Daniel: I tested this on an NVIDIA only system. I am going to test again on a fresh focal installation, to see if it makes any difference.

Alberto Milone (albertomilone) wrote :

I still can't reproduce the problem here. I am attaching the output of lspci -vvv.

Rajat Pandita (rajat-pandita) wrote :

If you can't reproduce the big, then I will nuke my absolutely functional system and post output here. I see you have a 1080 Card, I have a 1070, mine is an HP OMEN from 2017. Will post here soon.

Brian Collins (xbrico) wrote :

I have just built a brand new Ubuntu 20.04 system (nVidia GTX1070) and the bug existed on 2 fresh reinstalls. When enabling Autologin, the system fails. Disabling it and there is no issues. Running Proprietary 440 driver build, installed by the installer.

Pablo Catalina (xkill) wrote :

I installed Ubuntu 20.04 5 days ago (using the daily iso) and works fine with Quadro P3200 Mobile and default proprietary drivers installed.

I installed it setting up the user with autologon from the installer.

Luis Alvarado (luisalvarado) wrote :
Download full text (3.6 KiB)

This is exactly what is happening to me. I installed Ubuntu 20.04 today (The official released version, not beta), and if I set the auto login on, it will give me the same issue the original poster said. You can't login afterwards and if your logout, it enter a loop where you will never come out from unless you purge gdm3 and install it back or other workarounds that I can't guarantee work alone. I have an Nvidia GTX 1080 running on the Proprietary 440 Driver. My user is "luis" and the password is "x" in case anyone would want to literally try it out with the same user/pass/hardware combination.

If I disable the auto login then everything related to logout/login works correctly.

The hardware is down below of an Asus Hero Alpha VII, Intel 6700k and 64 GB of RAM. The SSD is a Samsung 850 Pro 1TB.

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 07)
00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31)
00:16.0 Communication controller: Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode] (rev 31)
00:1b.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #17 (rev f1)
00:1c.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #1 (rev f1)
00:1c.2 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #3 (rev f1)
00:1c.4 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #5 (rev f1)
00:1c.7 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #8 (rev f1)
00:1d.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #9 (rev f1)
00:1d.4 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #13 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Z170 Chipset LPC/eSPI Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller (rev 31)
00:1f.3 Audio device: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31)
00:1f.4 SMBus: Intel Corporation 100 Series/C230 Series Chipset Family SMBus (rev 31)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V (rev 31)
01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1080] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller (rev a1)
03:00.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
04:00.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
04:01.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
04:02.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015]
04:0...

Read more...

Luis Alvarado (luisalvarado) wrote :

Confirmed, after adding the nvidia-drm.modeset=1 to the GRUB file it worked. I tested 3 cases:

1. Reboot without Log out afterwards.
2. Reboot with a Log out afterwards and then try to log in again.
3. Reboot with a Log out afterwards, try to log in again and then reboot.

It worked for all cases. Of course this is still a workaround, but it works for the time being.

suKo (suko) wrote :

As per my earlier comment, I have a GTX 1080. I'm happy to provide any log information if @Alberto can tell me what he needs to help him figure out what's going on.

Mathew Hodson (mhodson) on 2020-04-24
no longer affects: systemd (Ubuntu)
slamdunk (antongiulio05) wrote :

Confirmed here with Ubuntu 20.04 and GTX 1060. As already suggested I used the fix:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

in the file:

sudo nano /etc/default/grub

and after:

sudo update-grub

which worked for me.

NErdgOd (nerdgod56) wrote :

I had this bug in 19.10, just uninstalled Nvidia driver and used nouveau, however I just clean installed 20.04, forgot about the bug and ran into it again. This time I had time to mess around, and ended up updating my bios from f40 to f50a which solved the issue for some reason. (GA-AB350M-Gaming 3 https://www.gigabyte.com/us/Motherboard/GA-AB350M-Gaming-3-rev-1x/support#support-dl)

PS uefi, CSM disabled, I have a 1070 in primary pcie slot, 680 in secondary, and the bios is set to POST on 680 for a passthrough setup.

I also changed a BUNCH of settings in my bios. Honestly have no idea what fixed it, I did the bios stuffs at one time stupidly.

NErdgOd (nerdgod56) wrote :

PPS:I tried using an old ati-branded hd5450 (or something) to POST on instead, the presence of the 1070 (with no display plugged in) was enough to make autologin not work. Removing the 1070 and only using the ati card brought me to a desktop.

Martin (martid0311) wrote :

In comment #50, I said having the proprietary drivers aren't necessary. I was wrong, but I thought it was true because I had the problem on an nvidia system without manually installing the nvidia drivers.

I just learned from an episode of the Ubuntu Podcast that since Ubuntu 19.10, proprietary drivers are included with the ISO, and that they're automatically enabled when you check the "install third-party software" option during install. That's interesting, because it means that the conditions for encountering this bug are:

1. Have a system with an affected nvidia graphics card.
2. Check both "enable automatic login" and "install third-party software" during install.

I don't know the stats, but I would bet most people check the third-party software box, and that lots of people want automatic login. In my opinion, this makes the issue significantly more important, because people will encounter this issue without entering "Additional Drivers" and manually enabling the proprietary drivers.

Especially considering there's a simple workaround available ("nvidia-drm.modeset=1" in GRUB_CMDLINE_LINUX) which doesn't affect any features, I think it would be good to get a hotfix out there before the upstream nvidia proprietary drivers are fixed.

I can confirm this is still an issue. The odd part is, however, that I did not have this issue on 19.10 with the nvidia drivers from the ppa. Upgrading to 20.04 introduced this issue to me.

testato (testato) wrote :

I installed Ubuntu 20.04 on a new hdd and an Nvidia 650TI. During the installation I enabled the use of proprietary drivers and autologin, so the new 440 drivers are already installed from the first boot.
Unfortunately the AutoLogin bug is confirmed also on the new Ubuntu LTS and therefore imho should have a high priority.
If it can be useful, on the new UbuntuDDE 20.04 the problem does not arise

tags: added: focal
Changed in gdm3 (Ubuntu):
milestone: none → ubuntu-20.04.1
hugh chao (hugh712) on 2020-06-04
tags: added: oem-priority stella
hugh chao (hugh712) on 2020-06-04
tags: added: sutton
Rex Tsai (chihchun) on 2020-06-08
Changed in oem-priority:
importance: Undecided → Critical
assignee: nobody → hugh chao (hugh712)
jeremyszu (os369510) wrote :

Update for summarizing current symptoms and workaround solution:

[Steps to reproduce]
1. Enable auto login through GUI ("Settings"->"Users"->"Automatic Login" to enable)
2. reboot
3. system stop at gdm login screen
There are two symptom I found currently:
4.1 enter correct password is not able to login
4.2 enter correct password manually and it can login

[Workaround]
Here are two workaround solution from comment#31 and comment#71:
1. Removing 'splash' from kernel command line
2. Adding 'nvidia-drm.modeset=1' in kernel command line

[Environments]
product: Lenovo ThinkStation P720[1]
bios-version: S04KT41A
CPU: Intel(R) Xeon(R) Gold 6240C CPU @ 2.60GHz (72x)
GPU: 18:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106GL [Quadro P2000] [10de:1c30] (rev a1)
kernel-version: 5.6.0-1010-oem
nvidia-driver: nvidia-driver-440

[1] https://www.lenovo.com/gb/en/workstations/p-series/ThinkStation-P720/p/33TS3TPP720

Alex Tasin (alextasin) wrote :

for me the two workaround doesn't work

hugh chao (hugh712) on 2020-06-26
Changed in nvidia-graphics-drivers-440 (Ubuntu):
status: New → Confirmed
To post a comment you must log in.