[regression] Password accepted but login fails (blank purple screen and mouse pointer only)

Maybe this is related to bug 1765261. Some people have suggested there are key repeat problems so if a key is getting unexpectedly repeated in bug 1765261 then that would count as an incorrect password.

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

Same problem on a fresh install from Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180421)
updated today
corrado@corrado-p7-bb-0421:~$ inxi -Fx
System: Host: corrado-p7-bb-0421 Kernel: 4.15.0-15-generic x86_64 bits: 64 gcc: 7.3.0
           Desktop: Gnome 3.28.1 (Gtk 3.22.30-1ubuntu1) Distro: Ubuntu Bionic Beaver (development branch)
Machine: Device: desktop Mobo: ASRock model: H110M-G/M.2 serial: N/A UEFI: American Megatrends v: P1.10 date: 05/11/2017
CPU: Dual core Intel Core i3-7100 (-MT-MCP-) arch: Skylake rev.9 cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 15648
           clock speeds: max: 3900 MHz 1: 800 MHz 2: 800 MHz 3: 800 MHz 4: 800 MHz
Graphics: Card: Intel HD Graphics 630 bus-ID: 00:02.0
           Display Server: x11 (X.Org 1.19.6 ) driver: i915 Resolution: 1920x1080@60.00hz
           OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2)
           version: 4.5 Mesa 18.0.0-rc5 Direct Render: Yes
Audio: Card Intel Sunrise Point-H HD Audio driver: snd_hda_intel bus-ID: 00:1f.3
           Sound: Advanced Linux Sound Architecture v: k4.15.0-15-generic
Network: Card: Intel Ethernet Connection (2) I219-V driver: e1000e v: 3.2.6-k bus-ID: 00:1f.6
           IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: 70:85:c2:44:7b:86
Drives: HDD Total Size: 1000.2GB (1.4% used)
           ID-1: /dev/sda model: TOSHIBA_DT01ACA1 size: 1000.2GB
Partition: ID-1: / size: 32G used: 5.3G (18%) fs: ext4 dev: /dev/sda7
           ID-2: swap-1 size: 8.59GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
RAID: No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors: System Temperatures: cpu: 40.5C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info: Processes: 243 Uptime: 12 min Memory: 1188.3/7680.8MB Init: systemd runlevel: 5 Gcc sys: N/A
           Client: Shell (bash 4.4.191) inxi: 2.3.56
corrado@corrado-p7-bb-0421:~$

I think I might have hit this finally. The blank purple screen with a mouse cursor probably means the shell failed to start. And indeed I have no gnome-shell process running for my UID. The journalctl shows:

pr 23 14:33:47 haz gnome-shell[912]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

Please try to log in to the machine via ssh first, and start monitoring the system log before reproducing the problem:

  journalctl -f

Then reproduce the bug (log in graphically) and let us know what the output from journalctl -f was at the time the bug occurred.

Here is the output from journalctl (extra spacing around probably the most interesting line). Also when I got back to the login screen, I very briefly saw a message under the password form saying 'Authentication error'.

/usr/lib/gdm3/gdm-x-session[1915]: (II) UnloadModule: "libinput"
/usr/lib/gdm3/gdm-x-session[1915]: (II) systemd-logind: releasing fd for 13:65
/usr/lib/gdm3/gdm-x-session[1915]: (II) UnloadModule: "libinput"
/usr/lib/gdm3/gdm-x-session[1915]: (II) systemd-logind: releasing fd for 13:69
/usr/lib/gdm3/gdm-x-session[1915]: (II) UnloadModule: "libinput"
/usr/lib/gdm3/gdm-x-session[1915]: (II) systemd-logind: releasing fd for 13:67
PackageKit[1352]: search-file transaction /372_adaeccdc from uid 1000 finished with success after 602ms
/usr/lib/gdm3/gdm-x-session[1915]: (II) Server terminated successfully (0). Closing log file.
gdm-password][1906]: pam_unix(gdm-password:session): session closed for user chris
gnome-shell[1128]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
systemd[1]: Starting Stop ureadahead data collection...
systemd[1]: Started Stop ureadahead data collection.

gdm-password][2437]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=chris

systemd-logind[904]: Removed session 4.
gdm-password][2440]: pam_unix(gdm-password:session): session opened for user chris by (uid=0)
systemd-logind[904]: New session 5 of user chris.
systemd[1]: Started Session 5 of user chris.
gnome-shell[1128]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
kernel: xhci_hcd 0000:39:00.0: remove, state 4
kernel: usb usb4: USB disconnect, device number 1
kernel: xhci_hcd 0000:39:00.0: USB bus 4 deregistered
kernel: xhci_hcd 0000:39:00.0: xHCI host controller not responding, assume dead
kernel: xhci_hcd 0000:39:00.0: remove, state 4
kernel: usb usb3: USB disconnect, device number 1
kernel: xhci_hcd 0000:39:00.0: Host halt failed, -19
kernel: xhci_hcd 0000:39:00.0: Host not accessible, reset failed.
kernel: xhci_hcd 0000:39:00.0: USB bus 3 deregistered
upowerd[1133]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/0000:02:02.0/0000:39:00.0/usb4/4-0:1.0
upowerd[1133]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/0000:02:02.0/0000:39:00.0/usb3/3-0:1.0
boltd[1351]: [d4030000-0092-XPS13 9360 ] removed (/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/domain0/0-0)
upowerd[1133]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/0000:02:02.0/0000:39:00.0/usb3
boltd[1351]: [d4030000-0092-XPS13 9360 ] dbus: unexported
upowerd[1133]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/0000:02:02.0/0000:39:00.0/usb4

I use persistent logging and got this (entered incorrect passwords and then the correct one, after the last message there's nothing for over 10 seconds (hanging on purple screen) and then I hard shutdown, I'm on a ThinkPad T430 with an SSD so it usually logs in very fast (and does when I get the password correct on the first attempt)).

Sorry must've copypasted badly, here's a better version

I think the relevant parts of the log are from 15:27:15.

I'm not sure how to get the full (unabbreviated) without SSH and I have no devices to use to SSH in unfortunately :(

On Sebastien Bacher's request I've filed this upstream: https://gitlab.gnome.org/GNOME/gnome-shell/issues/227

NOTE: This bug is not about a login failure. Login is succeeding as shown in comment #7. It's only the shell that's failing to start:

gdm-password][2440]: pam_unix(gdm-password:session): session opened for user chris by (uid=0)
systemd-logind[904]: New session 5 of user chris.
systemd[1]: Started Session 5 of user chris.
gnome-shell[1128]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

That is the same behaviour as I see.

Ads20000 might be experiencing something slightly different.

For an actual authentication failure, please see bug 1765261 instead.

Daniel thanks for your work here to try and get this filed correctly. If the logs are different for me and for this bug then perhaps my bug is different? Ray Strode (upstream) thinks the key part of my log is

```
Apr 23 17:43:40 adam-thinkpad-t430 gdm3[2997]: GdmSession: Emitting 'session-opened' signal
[...]
Apr 23 17:43:40 adam-thinkpad-t430 gdm3[2997]: GdmSession: external connection closed
```

Chris A, please could you (as Ray suggested to me) put `Enable=true` (without backticks (``)) in the `[debug]` section of `/etc/gdm/custom.conf`, reboot, reproduce and post the updated logs? Maybe then we'll be able to see if this issue is the same as mine or not (and if not then maybe Chris A's problem needs a separate upstream bug).

 Hi,

As discussed with duflu on irc, here are the steps I took to reproduce and produce a log:

 1. Enable debug in /etc/gdm3/custom.conf
 2. Reboot
 3. From other laptop; ssh wendigo journalctl -f
 4. Intentially login with a faulty password first, which made GDM just prompt as normal
 5. Login with the correct password, which caused the purple screen + mouse
 6. Copy the log up to this point
 7. Press a bunch of ctrl+alt+fn+f-key combos until I got back to login screen
 8. Login as normal, ctrl+c the SSH session and scp the file.

I've added a workaround to the bug description (and to the upstream bug description), do comment if the workaround doesn't work for you :)

To add more info, the following steps cause this issue on my machine and are reproducible.

- Start machine login to user A
- Logout of user A
- Try to login to user B
- Now have a purple display, need to use the cancel workaround (next login will work)

Also often stuck at purple screen after login. Mouse cursor can still be moved around. Another workaround is switching to console and back using CTRL-F1/CTRL-F2/... In my logs I also see the
G_IS_DBUS_CONNECTION (connection) error.

Same here with a 18.04 upgraded from 17.10

Workaround :
* Hitting Alt+F1 return to GDM who complain about a “login fail” and ask another time my password.
* Another successful password attempt finally launch Gnome correctly.

Side effect :
* Hitting Alt+F3,4,5,... give me ugly graphic mashup.

Try :
* Uncommenting the line bellow in /etc/gdm3/custom.conf file to use Xorg by default don't change anything :
#WaylandEnable=false

Note :
* The blanked screen is always GDM, I don't see the top menu-bar but clicking the right place show the GDM style system menu with only few option like shutdown button and no user sub-menu
* I not obtain blank purple screen but grey screen because I choose original Gnome CSS alternative...
`sudo update-alternatives --set gdm3.css /usr/share/gnome-shell/theme/gnome-shell.css`

I'm using a 18.04 upgraded from 17.10 and I have the same issue but slightly different.
The difference is that if I lock the screen for more than a certain amount of time, when I wake it up, I find myself logged out.
And to get away the blanked screen, I used Alt+F2 and then Alt+F1, and the gdm says "Authentication failed", which is quite similar to #19.
And I'm using gnome-session with Wayland.

Joseph, Zihang, that is bug 1765261. Not this one.

Also, if you find yourself logged out unexpectedly, please look for crash files in /var/crash and report them using the 'ubuntu-bug' command.

Finally, if anyone is experiencing this particular bug then please help upstream to debug it here:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/227

Had the same issue after a clean install of Ubuntu 18.04. After installing the proprietary drivers of the NVIDIA graphic card it did not happened again!

Daniel, I don't encounter problem with first attempt if I enter the right password. I only encounter problem with second attempt _after_ a failed first attempt.

I see the same thing as #17 (Andrew). I type in the password correctly each time. I login to a user (successfully, no errors) and then log out. After that, I login as a different user and I get the purple screen without the desktop showing. I typed the correct password. If I switch users leaving the first user still running (instead of logging that user out) the error does not happen. This happens on 3 different PCs that I've updated to 18.04.

Ads20000
The cancel button is not visible (purple screen),
your workaround is for another problem.
I think it's better to remove it from the bug description.

Davide

Ads2000 means to hit cancel before retyping your password. Hit cancel, then re-select user, then retype password, all before hitting enter... and hence the purple screen. I believe it's the same problem. This workaround works for me.

coolhandlewk
You are right, I misunderstood.
It works for me too, thanks.

I have a kinda similar problem on xubuntu 18.04. And had that problem on xubuntu 16.04.

After I type the password, there is only desktop wallpaper and mouse pointer (it moves). Then I press Ctr-Alt-Del and go back to password screen again (screen resolution changes to low), then I enter password and suddenly all works, everything is upsie-daisy.

I believe it somehow connected to nvidia drivers. Under nvidia-384 it problem doesn't existed, but on nvidia-390 and 396 it does.

Confirmed, entering an incorrect password and then trying to log in with the correct one leads to a purple screen.

Sum Sim

Not sure it is the Nvidia driver, I have had the same problem on both the Nvidia-390 and the X-org Nouveau display driver.
There seems to be a lot of talk about error occurring with incorrect password input, this is inconsistent with my experience.
The best workaround I have seen so far is mentioned by Wayne Carr (above), rather than log-out when switching users, use the switch-user option. This obviously leaves all profiles active but the fault does not occur.

Work around does not work for. It is not about nvidia driver. Lets face it, it is a showstopper for ubuntu 18.04 until bug is fixed.

Besides the login problem (wrong first attempt to login, then right password ,leads to a purple screen and nothing else happens) there is another problem when you are in gnome-shell if you issue ctrl-alt
f4 you cannot get back with ctrl-alt f7

That's not a bug. There's nothing on F7.

Your session is on F2, and the login screen is F1.

Is there a fix for this or not?. Please tell me there is -^-

To monitor the latest news about a fix look at:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/227

And when that's available, we will update this bug with information about an Ubuntu fix.

It could be that fixing this would also fixes lp:1703300 https://errors.ubuntu.com/problem/2258b834217f97f59fe38634745b76a577b781d1

I upgraded from Ubuntu 17.10 to 18.04 and all was fine for a couple weeks. I think an update yesterday (5/7) caused the problem. I have two accounts on the system. I can initially log into either fine but switching to the other causes the purple screen with cursor only. It does not matter if I log out of the first account or switch user, either way I have the problem. The password seems to be accepted fine. It seems that the windows don't start or start correctly.

I'm using an HP dv7-2043cl Notebook

Not on first login but on switch user after entering correct password I get purple screen and mouse.

Sometimes after a long delay I can get back to the login screen. I can usually force it back to the login screen by hitting a few random cycles of ctl+alt + F1, ctl+alt F2 and ctl+alt + F3.

At this point, if I click on the the user that failed it shows a message about authorization problem (but the password was correct). At login of this user it then allows access.

I know on subsequent logins it is going to fail as soon as I see the purple screen. If I see initial black, I know it is going to work OK.

I noticed this issue on an initial clean build on erased disks. Concerned about my hardware, I rebuilt again from clean and the problem is the same. I do not have a graphics card. I have: Intel® Core™ i7-4790 CPU @ 3.60GHz × 8. Ram = 24g.

The gnome bug is now here : <https://bugzilla.gnome.org/show_bug.cgi?id=795940>

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

Hi,

In addition to my post #96 above, I downgraded gdm3 back to the release version - 3.28.0-0ubuntu1 and am able to confirm that switching users works perfectly between two users for me.

Therefore sounds like the fix for gdm3 - 3.28.2-0ubuntu1.1 - has introduced further issues.

Given that the same code has now been released in 18.10 (3.28.2-1ubuntu1), we should treat it as a new bug and maybe not complicate the discussion here.

Can someone please log a bug against 18.10?

Switching users sometimes hangs since gnome shell 3.22. The bug exists in debian stable. But it's not 100% reproducible.

Fresh install 18.04 gdm3 did succeed occasionally, but mostly froze
completely so that power button was only way out.
There was a fix that was available in proposed repository (or something)
that made things a bit different. Failure became a rule, but it was
possible to get back with ctrl+alt+F1/F2 (randomly pressing both)
Now this latest version is the first one that seems to work everytime. My
personal wish would be that please stop complicating the thing and put it
in production.

to 31. toukok. 2018 klo 6.55 Jehandan Jeyaseelan (<email address hidden>)
kirjoitti:

> Hi,
>
> In addition to my post #96 above, I downgraded gdm3 back to the release
> version - 3.28.0-0ubuntu1 and am able to confirm that switching users
> works perfectly between two users for me.
>
> Therefore sounds like the fix for gdm3 - 3.28.2-0ubuntu1.1 - has
> introduced further issues.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1768619).
> https://bugs.launchpad.net/bugs/1766137
>
> Title:
> [regression] Password accepted but login fails (blank purple screen
> and mouse pointer only)
>
> Status in gdm:
> Fix Released
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in gdm3 package in Ubuntu:
> Fix Released
> Status in gnome-shell package in Ubuntu:
> Invalid
> Status in gdm3 source package in Bionic:
> Fix Committed
> Status in gnome-shell source package in Bionic:
> Invalid
>
> Bug description:
> [ Description ]
>
> Due to a refcounting bug, a GDBusConnection was getting disposed when
> it was still required. The symptom of this was that you couldn't log
> in on the second attempt if you'd got your password wrong on the first
> attempt. All you'd see is a blank purple screen and mouse pointer
> only.
>
> [ Test case ]
>
> 1. Boot to GDM
> 2. Click your username
> 3. Type the wrong password a couple of times, pressing enter after each
> time
> 4. Type the right password
>
> If the bug is happening, after 4. the system hangs at a blank screen
> with the mouse cursor. If you then switch to a VT or otherwise connect
> to the machine, you can examine the journal and you'll see a
> G_IS_DBUS_CONNECTION failure.
>
> [ Fix ]
>
> Marco and I worked upstream on this fix. We found out that there was a
> problem like this-
>
> The GdmClient has a shared GDBusConnection for its operations. The
> first time someone calls for it, it is created and stored in the
> object's private structure. Subsequent calls return *a new reference*
> to this same object. It turned out that the asynchronous method to get
> the connection was accidentally unreferencing its object before giving
> it to the caller if it was returning an already-existing connection.
>
> For this to work properly, we need to nullify the pointer we stored
> when the connection goes away, so we know when to make a new one.
> There were some cases where we didn't add the weak references required
> to do that. Those are also fixed.
>
> [ Regression potential ]
>
> Now we share connections more than we did before. We also more
> carefully track when to clear our object. If we g...

So, the latest two commits of this branch:
 - https://gitlab.gnome.org/3v1n0/gdm/commits/client-connection-reference-fix-3-28

Should fix all the problems that I've tested so far.
Packaging will follow.

Hi, in response to Marco's post #101,

I was wondering if a package will be released for bionic proposed so we can test it out before it is released?

I can see that one is released for cosmic that is newer than the one for bionic.

gdm3_3.28.2-0ubuntu1.1_amd64.deb, gir1.2-gdm-1.0_3.28.2-0ubuntu1.1_amd64.deb, libgdm1-dbgsym_3.28.2-0ubuntu1.1_amd64.ddeb, gdm3-dbgsym_3.28.2-0ubuntu1.1_amd64.ddeb, libgdm1_3.28.2-0ubuntu1.1_amd64.deb, and libgdm-dev_3.28.2-0ubuntu1.1_amd64.deb do not fix these issues by themselves.

on a fresh install:

lightdm cannot log in (failed password over and over)
gdm3 can only log into a wayland UI, not any other

In progress again. See the "Related branches" links near the top of the bug.

This bug was fixed in the package gdm3 - 3.28.2-2ubuntu1

---------------
gdm3 (3.28.2-2ubuntu1) cosmic; urgency=medium

  [ Iain Lane ]
  * Merge with Debian. Remaining changes:
    + README.Debian: update for correct paths in Ubuntu
    + control.in:
      - Don't recommend desktop-base
      - Depend on bash for ubuntu_config_error_dialog.patch
      - Update Vcs field
    + rules:
      - Don't override default user/group
      - --enable-gdm-xsession to install upstream Xsession script
      - override dh_installinit with --no-start to avoid session being killed
    + rules, README.Debian, gdm3.8.pod:
      Use upstream custom.conf instead of daemon.conf
    + gdm3.{postinst,postrm}: rename user and group back to gdm
    + gdm3.postinst: don't kill gdm on upgrade
    + gdm3.*.pam: Make pam_env read ~/.pam_environment
    + gdm3.install:
      - Stop installing default.desktop. It adds unnecessary clutter
        ("System Default") to the session chooser.
      - Don't install debian/Xsession
    + Add ubuntu_run_xsession.d.patch
    + Add ubuntu_xresources_is_a_dir.patch
      - Fix loading from /etc/X11/Xresources/*
    + Add ubuntu_nvidia_prime.patch:
      - Add hook to run prime-offload (as root) and prime-switch if
        nvidia-prime is installed
    + Add revert_override_LANG_with_accountservices.patch:
      - On Ubuntu accountservices only stores the language and not the
        full locale as needed by LANG.
    + Add ubuntu_dont_set_language_env.patch:
      - Don't run the set_up_session_language() function, since it
        overrides variable values set by ~/.pam_environment
    + Add ubuntu_config_error_dialog.patch:
      - Show warning dialog in case of error in ~/.profile etc. and
        don't let a syntax error make the login fail
    + Add debian/default.pa
      - Disable Bluetooth audio devices in PulseAudio from gdm3.
    + debian/gdm3.install
      - Added details of the default.pa file
    + debian/gdm3.postinst
      - Added installation of default.pa and creation of dir if it doesn't
        exist.

  [ Marco Trevisan (Treviño) ]
  * debian/patches/ubuntu_nvidia_prime.patch:
    - Fix install file paths

gdm3 (3.28.2-2) unstable; urgency=medium

  * debian/patches/libgdm-drop-support-for-serializing-multiple-opens.patch,
    debian/patches/libgdm-fix-pointer-boolean-task-confusion.patch,
    debian/patches/libgdm-don-t-keep-manager-proxy-around-longer-than-we-nee.patch,
    debian/patches/libgdm-use-g_object_unref-instead-of-g_clear_object-for-w.patch,
    debian/patches/libgdm-get-connection-explicitly.patch,
    debian/patches/libgdm-Drop-weak-refs-on-the-GDBusConnection.patch,
    debian/patches/libgdm-Unref-the-manager-propagated-from-task.patch,
    debian/patches/libgdm-Don-t-double-ref-the-connection-got-from-task.patch,
    debian/patches/libgdm-Don-t-leak-connection-on-sync-re-authentication.patch,
    debian/patches/libgdm-Use-auto-pointers-and-cleanup-code.patch,
    debian/patches/libgdb-Try-to-reuse-connections-from-the-available-proxie.patch,
    debian/patches/libgdm-Don-t-save-manager-address.patch,
    debian/patches/libgdm-Return-NULL-on-invalid-client-instances.patch:
    - Cherry picks comm...

Hello Chris, or anyone else affected,

Accepted gdm3 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gdm3/3.28.2-0ubuntu1.2 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 and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. 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!

** Tag verification-done-bionic

tested the following:
gdm3/3.28.2-0ubuntu1.2/amd64

Tested multiple bad password followed with a good password. PASS
Tested switching from user A to user B; multiple bad password followed by good password. PASS
Tested switching from user B back to user A; multiple bad password followed by good password. PASS

I found no issues... everything worked as expected.

Ken

Can someone take time to explain to a newb how/where to read in this bug report when this fix will be pushed out?

Like, I see "Fix Released", but when does "sudo apt upgrade" see this fix?

"Fix Released" will always occur for the development release first (Ubuntu 18.10). Then existing stable versions after that.

You can see a fix for 18.04 is in proposed (not yet released) here:
  https://launchpad.net/ubuntu/+source/gdm3
So is only hours/days away from release.

Thanks Daniel!

So, my question is, how do I decipher (approximately) how many hours/days away from release for 18.04 this fix is?

It's probably very obvious to old hands, but it's totally illegible to a newb. Like, can I see what "branch" or "version" will have this fix? And then, how do I see when that "branch" or "version" hits the normal (18.04) distribution?

Nobody can predict the future exactly, but given that the fix for 18.04 has now been verified I would *expect* it to be fully released later today. Mainly waiting for Europe to wake up...

Tip: Make sure you're using the main archive to receive updates and not a mirror, as mirrors will take longer to update. See: Software & Updates > Download from = Main server.

Wow! So once status is Fix Released that means, probably, usually, hopefully, wait no more than 24 hours for the fix to hit your machine if you sudo apt upgrade daily?

That's not quite right. Fix Released means a fix has been released. The only question is in which Ubuntu release. Presently you can see:

gdm3 (Ubuntu) Fix Released <-- Ubuntu 18.10 release completed
       Bionic Fix Committed <-- Ubuntu 18.04 soon to be released

How long will it will be tested in "proposed"? A week? Two weeks, a month?

As already stated, I expect to see the release within hours (less than a day).

Do you know how to potentially unlock the situation even temporarily?

Yes. See "WORKAROUND" in the bug description.

Namely for my part to solve the connection problems via auto connection. However, it still freezes a few more times in use

Since it's still in proposed and a day is mostly over (and Europe is asleep again) - could somebody outline / point me to the conditions for a package to be moved from proposed to released?

This would be good to know to understand what is missing (and potentially help?) instead of entering a lengthy discussion here, with almost a 100 affected people and hence spamming lots of subscribers.

Hi,

Tested the fix again - 3.28.2-0ubuntu1.2 on a fresh install of Ubuntu 18.04 LTS.

I went through all scenarios:

a) Login initially with incorrect password then correct password - Pass
b) Login by entering incorrect password multiple times then correct password - Pass
c) Created a second user (User B) then switched to that user entering correct password - Pass
d) Switched back to User A entering correct password - Pass
e) Switch between User A and B multiple times - Pass
e) Switched to User B entering incorrect password first then correct password - Pass
f) Switched to User A entering incorrect password first then correct password - Pass
g) Performed logout of User A, then unlocked User B with correct password - Pass
h) Performed logout of User B, then logged in to User A with correct password - Pass.

Fix now works perfectly. All good.

Hi,

I'd like to test too - though being new here - can I (to avoid to switch to proposed repo) just download and install the AMD64 .deb files listed under proposed / 3.28.2-0ubuntu1.2 ?

thanks,
br, Koen

The conditions for the package to move to release are here: https://wiki.ubuntu.com/ProposedMigration#Migrating_packages_from_-proposed_to_release

It's possible that the update breaks something in release, though I'm not sure what. It's also possible that we _just need to be more patient_, it's only been a few days since it was put in proposed. I don't see how spamming this bug is going to help the situation.

@Ads20000 Thanks for the link. Sadly, gdm3 is neither in the autopkgtest-list, nor update-excuses, nor update-list, so it seems things are stuck at an earlier stage and the documentation does not clarify where to find out at which point help could be needed.

My intention was not to spam this report, but to find out where things are stuck (it's not obvious) and how to give support.
It's also not about my personal (im)patience, but we have >200 desktops and >2000 Ubuntu containers and have had to stop the migration after the first 10 desktops due to this bug (and three(!) other ones which all have been known *before* release and should either have been release blockers or been mentioned as "Known Issues" with the new LTS to prevent people from hopping onto the new supposedly-stable). For the other critical issues, QA apparently was even worse, since Debian and in one case also RHEL have already released fixes months or even a year ago, and there has been no reaction on Launchpad whatsoever yet. Since we are also still affected by critical bugs in 16.04 which have been open since 16.04's release and could only be solved by PPA (broken OpenAFS), this makes me wonder whether Ubuntu still is a valid choice for institutional use, but this discussion certainly goes off topic here.

Just let us know if there is something people could help with (testing etc.). As it stands, the status is completely unclear apart from the statement _to be patient_ - without indicating what the actual point is where things are stuck.

3.28.2-0ubuntu1.1 did work fine for login logout to another user (critical
in our environment). It has been few days since it was supposed to be
coming and I figured that it is safe now to start installing 18.04, but
fresh install 18.04 and I am still getting 3.28.0-Oubuntu1 - will not work.

su 10. kesäk. 2018 klo 17.25 OliFre (<email address hidden>) kirjoitti:

> @Ads20000 Thanks for the link. Sadly, gdm3 is neither in the
> autopkgtest-list, nor update-excuses, nor update-list, so it seems
> things are stuck at an earlier stage and the documentation does not
> clarify where to find out at which point help could be needed.
>
> My intention was not to spam this report, but to find out where things are
> stuck (it's not obvious) and how to give support.
> It's also not about my personal (im)patience, but we have >200 desktops
> and >2000 Ubuntu containers and have had to stop the migration after the
> first 10 desktops due to this bug (and three(!) other ones which all have
> been known *before* release and should either have been release blockers or
> been mentioned as "Known Issues" with the new LTS to prevent people from
> hopping onto the new supposedly-stable). For the other critical issues, QA
> apparently was even worse, since Debian and in one case also RHEL have
> already released fixes months or even a year ago, and there has been no
> reaction on Launchpad whatsoever yet. Since we are also still affected by
> critical bugs in 16.04 which have been open since 16.04's release and could
> only be solved by PPA (broken OpenAFS), this makes me wonder whether Ubuntu
> still is a valid choice for institutional use, but this discussion
> certainly goes off topic here.
>
> Just let us know if there is something people could help with (testing
> etc.). As it stands, the status is completely unclear apart from the
> statement _to be patient_ - without indicating what the actual point is
> where things are stuck.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1768619).
> https://bugs.launchpad.net/bugs/1766137
>
> Title:
> [regression] Password accepted but login fails (blank purple screen
> and mouse pointer only)
>
> Status in gdm:
> Fix Released
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in gdm3 package in Ubuntu:
> Fix Released
> Status in gnome-shell package in Ubuntu:
> Invalid
> Status in gdm3 source package in Bionic:
> Fix Committed
> Status in gnome-shell source package in Bionic:
> Invalid
>
> Bug description:
> [ Description ]
>
> Due to a refcounting bug, a GDBusConnection was getting disposed when
> it was still required. The symptom of this was that you couldn't log
> in on the second attempt if you'd got your password wrong on the first
> attempt. All you'd see is a blank purple screen and mouse pointer
> only.
>
> [ Test case ]
>
> 1. Boot to GDM
> 2. Click your username
> 3. Type the wrong password a couple of times, pressing enter after each
> time
> 4. Type the right password
>
> If the bug is happening, after 4. the system hangs at a blank screen
> with the mouse cursor. If you then switch to a VT or othe...

Release package is already unstable and isn't able to it's job.
I don't see any reasons not to deploy this excepting bureaucracy.

This is a blocker for deployment of 18.04 to ~200 workstations within my company. Any ETA on a release?

My steps to reproduce:
1. Boot Machine
2. Enter username
3. Enter incorrect password
4. Enter correct password
5. Stuck on purple screen

The policy for Stable Release Updates is to let them age a minimum of 7 days in the -proposed pocket before releasing them to the -updates pocket. Reading the comments here I've noticed that the automated SRU testing comment doesn't make any reference to that 7 day period nor does it point to the wiki page that documents the aging period. I'll work getting that fixed shortly.

Speaking with another SRU team member we've decided to waive the 7 day period and will release the fixed version of gdm3 today.

The verification of the Stable Release Update for gdm3 has completed successfully and the package has now been 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.

This bug was fixed in the package gdm3 - 3.28.2-0ubuntu1.2

---------------
gdm3 (3.28.2-0ubuntu1.2) bionic; urgency=medium

  * debian/patches/libgdm-drop-support-for-serializing-multiple-opens.patch,
    debian/patches/libgdm-fix-pointer-boolean-task-confusion.patch,
    debian/patches/libgdm-don-t-keep-manager-proxy-around-longer-than-we-nee.patch,
    debian/patches/libgdm-use-g_object_unref-instead-of-g_clear_object-for-w.patch,
    debian/patches/libgdm-get-connection-explicitly.patch,
    debian/patches/libgdm-Drop-weak-refs-on-the-GDBusConnection.patch,
    debian/patches/libgdm-Unref-the-manager-propagated-from-task.patch,
    debian/patches/libgdm-Don-t-double-ref-the-connection-got-from-task.patch,
    debian/patches/libgdm-Don-t-leak-connection-on-sync-re-authentication.patch,
    debian/patches/libgdm-Use-auto-pointers-and-cleanup-code.patch,
    debian/patches/libgdb-Try-to-reuse-connections-from-the-available-proxie.patch,
    debian/patches/libgdm-Don-t-save-manager-address.patch,
    debian/patches/libgdm-Return-NULL-on-invalid-client-instances.patch:
    - Cherry picks commits from upstream 3.28 branch to propely fix ref-counting
      issues on GdmClient (LP: #1766137)

gdm3 (3.28.2-0ubuntu1.1) bionic; urgency=medium

  * debian/gbp.conf: Add with 'bionic' configuration.
  * debian/control{,.in}: Update Vcs-* for git.
  * New upstream release (LP: #1773968):
    - Reference counting fixes for GdmClient (LP: #1766137)
    - ensure plymouth is quit properly even when local greeter is disabled
    - make sure GDM doesn't hang when called with unknown command line arguments
  * debian/patches/0001-libgdm-Don-t-unref-a-connection-that-s-in-use.patch,
    debian/patches/0002-libgdm-add-weak-pointer-for-connection-object.patch:
    Drop, included in this release.

gdm3 (3.28.0-0ubuntu1.1) bionic; urgency=medium

  * debian/patches/0001-libgdm-Don-t-unref-a-connection-that-s-in-use.patch,
    debian/patches/0002-libgdm-add-weak-pointer-for-connection-object.patch:
    Cherry-pick two patches from the 3.28 branch. These fix a refcounting bug
    in the GDM Client object, which had meant that the DBus connection was
    being disposed too early in some cases, particularly when logging in after
    a failed attempt. The symptom of that was that the system hung on a
    "blank" screen. (LP: #1766137)
  * debian/control{,.in}: Update for bionic

 -- Marco Trevisan (Treviño) <email address hidden> Tue, 05 Jun 2018 11:58:41 +0100

9-8-018 fresh install with updates .. some user switches work, some don't logout is also crashing with irresponsive black screen. When the user switch fails, the description is slightly different from above. If the mouse pointer comes in at lower right, the user switch works. If it comes in upper right, then the mouse fails, alt-F1 etc. all do nothing, and rather than blank purple screen, I have what appears to be a successful login, but the system is completely non-responsive.

dell optiplex 755
SSd
3.16 GHZ core 2 duo

gdm3 info. for above comment

matt@Wallace:~$ apt list gdm3
Listing... Done
gdm3/bionic-updates,bionic-security,now 3.28.2-0ubuntu1.4 amd64 [installed]
N: There is 1 additional version. Please use the '-a' switch to see it
matt@Wallace:~$ apt list gdm3 -a
Listing... Done
gdm3/bionic-updates,bionic-security,now 3.28.2-0ubuntu1.4 amd64 [installed]
gdm3/bionic 3.28.0-0ubuntu1 amd64

matt,

The fix is in gdm3 version 3.28.2-0ubuntu1.1 and later.

You only have version 3.28.0-0ubuntu1 installed.

If you can't easily update then you might have more luck installing version 18.04.1 directly (which might contain the fix if 18.04 didn't)...

https://www.ubuntu.com/download/desktop/thank-you?version=18.04.1&architecture=amd64

matt,

Please also note that a Core 2 Duo will suffer from bug 1727356 too. Please apply the workaround from that bug.

This bug affected me, but got past it by adding "nouveau.modeset=0" after the text "quiet splash" in the bootparameters for Ubuntu in the grub menu.

This bug is closed so please open a new bug if you have any problems at all.