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

[Martin]

[ Impact ]
In some platforms with specific Nvidia cards (with nvidia-driver-440), enable auto-login (either during installation or after installation) will fail (either stuck in gdm login screen and not able to login even typing correct password).

[ Test Case ]
Here are two scenario of auto login with groovy (20.10) daily build[1]:

1) Checked "Install third-party software" (e.g. nvidia-driver) with enabling "Login automatically" during installation.

2) Install groovy daily build with default options, after installation completed:
2.1) Install nvidia-driver-440 (450.66-0ubuntu1) from ubuntu-archive.
2.2) Enable "Login automatically" from system settings.

Then reboot.

[Expected result]
System will boot into desktop environment without the login page.

[Actual result]
System boots to login page, and can't login to desktop environment with the correct password.

[ Regression potential ]
Medium, the patch comes from upstream[2] to use /dev/tty1 (instead of tty0) to prevent the auto-login user gets tty1. I did verified gdm3 from my PPA[3] and it works good. It passed the 30 times reboot stress test by using stress/reboot_30 from checkbox.

[1] sha256sum: bf4359114660504ad3f6fbde5e0c3edbc67a4101e4480f576d3cbd4f59acf822
[2] https://gitlab.gnome.org/GNOME/gdm/-/commit/f843233ad4 https://gitlab.gnome.org/GNOME/gdm/-/commit/690b3c01
[3] https://launchpad.net/~os369510/+archive/ubuntu/gdm3-1845801

---

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

[Daniel van Vugt (vanvugt)]

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.

[Martin (martid0311)]

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.

[Launchpad Janitor (janitor)]

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

[Daniel van Vugt (vanvugt)]

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

[Ted Goddard (tedgoddard)]

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)]

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

[Ted Goddard (tedgoddard)]

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)]

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)]

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.

[Valtteri Vainikka (vrln)]

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)]

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

[Iain Lane (laney)]

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.

[dehein (dehein)]

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)]

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)]

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)]

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

[Alberto Milone (albertomilone)]

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)]

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)]

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)]

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)]

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)]

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

[Martin (martid0311)]

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)]

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

[Sebastien Bacher (seb128)]

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

[Martin (martid0311)]

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)]

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)]

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

[Valtteri Vainikka (vrln)]

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)]

Indeed, thanks

[Olivier Robert (novhak)]

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)]

s/crypsetup-initramfs/cryptsetup-initramfs

[Edgar Bonet (linu7)]

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)]

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)]

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.

[hugh chao (hugh712)]

Hi Guys,

Help me to test this, this works for me,
please find this line "set vt_handoff=vt.handoff=7" in /boot/grub/grub.cfg,
and change it to "set vt_handoff=vt.handoff=1", then reboot let's see how it goes, thanks.

[hugh chao (hugh712)]

if the result in #101 is positive for everyone,
then I think it's because of this missed patch since from cosmic

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "vt_handoff.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Zakhar (alainb06)]

Hello, I can confirm that this bug still exists in 20.04.

I am using NVidia 340.108 because this is a 12 years old laptop with a completely obsolete GeForce GT230M.

Workaround #34 (removing quiet splash) worked but slows down the boot process due to the speed of writing on the console.

Workaround #101 work fine: no "garbage" output on the console and no slow down. 12 years old PC booting in 40 sec (including 8.5 due to the BIOS itself).

Unfortunately patching manually the grub.cfg does not withstand updates like kernel that will run update-grub, so I hope there will be a better patch soon!

[Zakhar (alainb06)]

So to make #101 permanent, you have to "patch" line 335 of /etc/grub.d/10_Linux

from:
  set vt_handoff=vt.handoff=7
to:
  set vt_handoff=vt.handoff=1

Not sure though the same "patch" is also to be applied in other files like 10_linuxzfs, etc...

Patch attached:
$ cat 10_linux.patch
--- 10_linux_orig 2020-07-13 09:06:55.593140059 +0200
+++ 10_linux 2020-07-13 09:08:57.799858927 +0200
@@ -332,7 +332,7 @@
 if [ "$vt_handoff" = 1 ]; then
   cat << 'EOF'
  if [ "${1}" = "keep" ]; then
- set vt_handoff=vt.handoff=7
+ set vt_handoff=vt.handoff=1
  else
   set vt_handoff=
  fi

[Zakhar (alainb06)]

Note: the patch (if #101 is the "right" solution) applies to the package "grub-common" that contains /etc/grub.d/10_linux

[hugh chao (hugh712)]

I'll start the SRU for this issue soon

[Steve Langasek (vorlon)]

hugh, you will need to coordinate this with the Foundations Team, as there are a number of grub changes currently queued for SRU.

[Dimitri John Ledkov (xnox)]

Ubuntu no longer uses vt.handover and it should not be specified at all anymore.

We boot directly to tty1, always and everywhere, and we should not be setting that at all.

Thus a patch changing that from 7 to 1 is not a good idea for focal+.

And I can't quite remember which releases we have changed to booting to tty1 by default. Maybe it was bionic, or between xenial and bionic?

[hugh chao (hugh712)]

the origin change was in
'''
commit 9dadfd82504afa114b39e508e4580cb0212468ea (tag: pkg/import/2.00-20)
Author: Colin Watson <email address hidden>
Date: Thu Nov 14 10:49:31 2013 +0000

+ Set vt.handoff=7 for smooth handoff to kernel graphical mode.
'''

https://git.launchpad.net/~hugh712/ubuntu/+source/grub2/commit/?h=ubuntu/devel&id=9dadfd82504afa114b39e508e4580cb0212468ea

then it's been changed in bionic as:
'''
commit db84c3cc6faa4750d12c451f7a0c20560d0893bd
Author: Mathieu Trudel-Lapierre <email address hidden>
Date: Fri Feb 9 16:30:45 2018 -0500

Add configure option to use vt.handoff=1
'''
https://git.launchpad.net/~hugh712/ubuntu/+source/grub2/commit/?h=bionic&id=c9b225dd94935e17dc8196dcaea524d4897bef4d

[hugh chao (hugh712)]

Upload debdiff for groovy,
please help to review this patch,
in the meantime, I'm running the stress test with this package in a nvidia platform,
let's see how it goes.

[Luis Alberto Pabón (copong)]

A workaround, if you really need auto-login, is to install lightdm (at this point still choose gdm3), enable auto-login via gnome settings, then switch to lightdm (sudo dpkg-reconfigure gdm3). Not sure why it autologins but it does. Can't lock the gnome session however as not using gdm anymore.

[hugh chao (hugh712)]

Hi all,

Currently grub is frozen in all series for point releases. So I will start the SRU after focal point release, please just use #105 with a "sudo update-grub" as a workaround.

[DiegoRivera (diego-rivera)]

The workaround for me was to disable vt_handoff in /etc/grub.d/10_linux* (i.e. set vt_handoff=0 in both places near the top of the file).

That resolved the issue completely.

[Luis Alberto Pabón (copong)]

There's an update to grub coming, so anybody who's modified the grub scripts are going to hit the issue again.

[Steve Langasek (vorlon)]

Modifications to the grub scripts will not be overwritten by the grub security update.

[Julian Andres Klode (juliank)]

The proposed debdiff is wrong, it reverts a patch in the patch series by adding a new patch. I think we can probably remove the vt-handoff.patch from the patch series for groovy without much checking, but any SRU will need to consult with flavours to check if they need the handoff.

[Daniel van Vugt (vanvugt)]

This might be relevant:

https://gitlab.gnome.org/GNOME/gdm/-/commit/f843233ad4

(fixed in gdm3 3.36.2)

[Daniel van Vugt (vanvugt)]

Seems there are a few fixes in gdm3 3.36 that we don't have, being on 3.34 in Ubuntu.

[Dimitri John Ledkov (xnox)]

However dropping vt.handoff is not regression free it may impact flavours that use lightdm.

[Dimitri John Ledkov (xnox)]

We could use gfxpalyload blacklist, to mark certain nvidia cards there. And then gfxpayload will not be set to keep, and then vt.handoff will not be appended.

See grub-gfxpayload-lists package, and files in /usr/share/grub-gfxpayload-lists/blacklist/

My current preference would be the gdm3 fix. And migrate the rest of the login managers to tty1 too.

[jeremyszu (os369510)]

I tried to install stock 20.04.1 ubuntu with 'Install third party pkgs (e.g. nvidia)' + enable login automatically. After a reboot because of installation completed, the system will stuck in GDM login screen and can't login even if typing correct password.

[jeremyszu (os369510)]

[Summary]
Here are two scenario of auto login with groovy (20.10) daily build[1]:

1. Checked "Install third-party software" (e.g. nvidia-driver) with enabling "Login automatically".

2. Install with default options
2.1 Install nvidia-driver-440 (450.57-0ubuntu2) from ubuntu-archive.
2.2 Enable "Login automatically" from system settings.

After reboot, the system won't login automatically even can not login manually.

[Environment]
HP Z4 G4 Workstation + RTX6000 (10de:1e30)

[Solution]
Tried to patch the solution from comment#119 as a debian package[2]. The problem is solved. (Verified in scenario 2)

The debdiff as attachment, please help to review.

[1] sha256sum
```
$ sha256sum ~/Downloads/groovy-desktop-amd64.iso
bf4359114660504ad3f6fbde5e0c3edbc67a4101e4480f576d3cbd4f59acf822 /home/jeremysu/Downloads/groovy-desktop-amd64.iso
```
[2] gdm3 from https://launchpad.net/~os369510/+archive/ubuntu/gdm-1845801/+packages

[Rex Tsai (chihchun)]

Upstream found a regression[1] with the new patch in #128, Jeremy will review and re-test the solution in focal before asking for sponsorship.

[1] Multiple regressions in multi-user environments since 3.36.2 (#602) · Issues · GNOME / gdm · GitLab - https://gitlab.gnome.org/GNOME/gdm/-/issues/602

[jeremyszu (os369510)]

I'd confirmed the regression with enabling Wayland.
Due to nvidia-driver (nvidia-driver-440) disable wayland as default, I'll separate the verification to two scenarios.

1. Make sure the new gdm3 fixes this issue.
2. Make sure the new gdm3 without the regression (https://gitlab.gnome.org/GNOME/gdm/-/issues/602)

---

* Make sure the new gdm3 fixes this issue *

[Summary]
Here are two scenario of auto login with groovy (20.10) daily build[1]:

1. Checked "Install third-party software" (e.g. nvidia-driver) with enabling "Login automatically".

2. Install with default options
2.1 Install nvidia-driver-440 (450.66-0ubuntu2) from ubuntu-archive.
2.2 Enable "Login automatically" from system settings.

After reboot, the system won't login automatically even can not login manually.

[Environment]
HP 800 G6 DM + GeForce GTX 1660 [10de:2191]

[Solution]
Backport the solution from comment#119 as a debian package[2] (commit ID from upstream: f843233a, 690b3c01). The problem is solved. (Verified in scenario 2)

The debdiff as attachment, please help to review.

[1] sha256sum
```
$ sha256sum ~/Downloads/groovy-desktop-amd64.iso
bf4359114660504ad3f6fbde5e0c3edbc67a4101e4480f576d3cbd4f59acf822 /home/jeremysu/Downloads/groovy-desktop-amd64.iso
```
[2] gdm3 from https://launchpad.net/~os369510/+archive/ubuntu/gdm3-1845801/+packages

---

* Make sure the new gdm3 without the regression (https://gitlab.gnome.org/GNOME/gdm/-/issues/602) *

This issue is happens when switching user under Wayland.
I'd verified gdm3#602 issue when using intel graphic in the same machine because nvidia-driver disable Wayland as default.

Steps to reproduce gdm3#602 issue:
1. Login a user "test" under x11
2. Create a user "test2"
3. Press "switch user ..." to "test2" under wayland
4. Switch back to "test" under x11
5. Switch to "test2" under wayland (then the running session be killed immediately)
6. Login again and then the mouse won't work.

After applying commit 690b3c01, above problems are solved. Repeat to switch user and everything goes well.

[Iain Lane (laney)]

Uploaded to proposed, not the debdiff here but the new upstream release 3.36.3 which has the same fix in it

[Chris Halse Rogers (raof)]

Hello Martin, or anyone else affected,

Accepted gdm3 into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gdm3/3.36.3-0ubuntu0.20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted gdm3 (3.36.3-0ubuntu0.20.04.1) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/245.4-4ubuntu3.2 (amd64, s390x, ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#gdm3

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Edward Savage (epssyis)]

Chris,

With the following packages installed and the workaround removed the issue no longer occurs for me when enabling Automatic Login via Settings. I have tested rebooting and starting from off several times and it worked as expected each time. Previously the issue occurred on every boot.

gdm3 (3.36.3-0ubuntu0.20.04.1)
libgdm1 (3.36.3-0ubuntu0.20.04.1)
gir1.2-gdm-1.0:amd64 (3.36.3-0ubuntu0.20.04.1)
nvidia-driver-450 (450.66-0ubuntu0.20.04.1)

/etc/default/grub
```
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
```

Of note, when the desktop loaded I was greeted with the Ubuntu new user "Connect Your Online Accounts" setup screen and what appeared to be a fresh users settings. If this happens to anyone here there's a helpful README.txt in ~/ reminding you that you encrypted your home directory, and to run ecryptfs-mount-private to gain access. Oh yeah...

You can also expect to be prompted to unlock your login keyring at some random moment a few minutes after the desktop loads.

Anyway, wonderful work, and thanks to everyone who helped fix this, at least for me. :)

[jeremyszu (os369510)]

Hi All,

I'd confirmed this issue is be fixed by gdm3 3.36.3-0ubuntu0.20.04.1 and passed the 30 times reboot stress test by using stress/reboot_30 from checkbox.

The environment:

kernel: 5.4.0-47-generic
gdm3: 3.36.3-0ubuntu0.20.04.1
nvidia-driver-440: 440.100-0ubuntu0.20.04.1
GPU: VGA compatible controller [0300]: NVIDIA Corporation TU116M [GeForce GTX 1660 Ti Mobile] [10de:2191]

[Launchpad Janitor (janitor)]

This bug was fixed in the package gdm3 - 3.36.3-0ubuntu0.20.04.1

---------------
gdm3 (3.36.3-0ubuntu0.20.04.1) focal; urgency=medium

  [ Iain Lane ]
  * New upstream release (LP: #1894874).
    - Always use separate session bus for greeter sessions
      This runs dbus-run-session, so the binary needs to be available
    - Chrome remote desktop fix
    - Don't hardcode path to plymouth
    - Fixes for when GDM isn't started on its configured initial VT (LP:
      #1845801)
    - keyutils has a .pc file so use it
    - User switching fix
  * debian/{control,gbp.conf}: Update for ubuntu/focal & upstream/3.36.x

  [ Simon McVittie ]
  * Add Depends on dbus, for dbus-run-session
  * Update symbols file.
    This ignores a change to private symbols: gdm_find_display_session_for_uid
    isn't declared in a public header, and nothing in Debian/Ubuntu seems to
    call it.

 -- Iain Lane <email address hidden> Tue, 08 Sep 2020 18:01:39 +0100

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for gdm3 has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Ivan Devon (ivanixdev)]

Just FYI,

Seems still broken with gdm3 package 3.36.3-0ubuntu0.20.04.2 on ubuntu 20.04.1.
and nvidia nvidia-driver-460 460.39-0ubuntu0.20.04.1.

[Daniel van Vugt (vanvugt)]

This bug is closed. If you still experience any problem then please open a new bug.