[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
170
This bug affects 31 people
Affects Status Importance Assigned to Milestone
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
systemd (Ubuntu)
Low
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.

To post a comment you must log in.