gnome lock screen does not permit reentering password

[Jeff Burdges]

Initially, only the mouse works in the gnome lock screen, without any way to get a password prompt. It's likely only happening when returning from suspend with lid open.

It's possible to ssh into the machine or to press Fn+Ctrl+Alt+F?? and login without gnome. After this, Fn+Ctrl+Alt+F1 brings up a purple ubuntu login screen, but then after login you simply return to the lock screen with no working keyboard. I never found any method to force unlock from ssh or another vt though, so this always still required a reboot, or killing all of gnome.

I've randomly tried some solutions from https://askubuntu.com/questions/1242110/after-upgrading-to-ubuntu-20-04-lockscreen-not-working including reinstalling many gnome components. After this, the behavior initially disappeared by returning from suspend merely took a long time, like 30 seconds or 1 minute. It's possible the delay stems from memory size, but a previous identical lenovo x1 had no such problems.

I've now a worse problem just a few hours later where unsuspend went directly to a purple ubuntu login screen, but neither the mouse nor keyboard worked. I've not yet been able to test ssh on this problem.

It's possibly all connected to recent firmware upgrades, so I'm happy to try downgrading the firmware, but I've not found any instructions on doing so, or even identifying the firmware upgrade log.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.14.0-1027.30-oem 5.14.21
Uname: Linux 5.14.0-1027-oem x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 17 03:44:49 2022
DistUpgraded: Fresh install
DistributionChannelDescriptor:
 # This is the distribution channel descriptor for the OEM CDs
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-sutton-focal-amd64-20210412-218+sutton-newell-focal-amd64+X00
DistroCodename: focal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GpuHangFrequency: Several times a day
GpuHangReproducibility: Occurs more often under certain circumstances
GpuHangStarted: Within the last week or two
GraphicsCard:
 Intel Corporation Device [8086:9a49] (rev 01) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:22d5]
InstallationDate: Installed on 2021-04-15 (335 days ago)
InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20210412-22:07
MachineType: LENOVO 20XWCTO1WW
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.14.0-1027-oem root=UUID=6a411137-06bb-4de1-be93-c2fcd4f44a5a ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
Title: Xorg freeze
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/02/2021
dmi.bios.release: 1.51
dmi.bios.vendor: LENOVO
dmi.bios.version: N32ET75W (1.51 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20XWCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.32
dmi.modalias: dmi:bvnLENOVO:bvrN32ET75W(1.51):bd12/02/2021:br1.51:efr1.32:svnLENOVO:pn20XWCTO1WW:pvrThinkPadX1CarbonGen9:rvnLENOVO:rn20XWCTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20XW_BU_Think_FM_ThinkPadX1CarbonGen9:
dmi.product.family: ThinkPad X1 Carbon Gen 9
dmi.product.name: 20XWCTO1WW
dmi.product.sku: LENOVO_MT_20XW_BU_Think_FM_ThinkPad X1 Carbon Gen 9
dmi.product.version: ThinkPad X1 Carbon Gen 9
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.107-8ubuntu1~20.04.2
version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1~20.04.2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

[Daniel van Vugt (vanvugt)]

Thanks for the bug report.

Please open the 'Extensions' app and ensure no more than the three built-in Ubuntu extensions are enabled. If any others are listed then please disable/uninstall them and log in again.

Also next time the problem happens, after rebooting please run:

  journalctl -b-1 > prevboot.txt

and attach the resulting text file here.

[Daniel van Vugt (vanvugt)]

Actually if you're using a Xorg session and only the mouse is working then it's likely the gnome-shell process alone is hung or crashed. Because the mouse movement is handled by Xorg, not gnome-shell.

Please:

1. Look in /var/crash for crash files and if found run:

    ubuntu-bug YOURFILE.crash

   Then tell us the ID of the newly-created bug.

2. If step 1 failed then look at https://errors.ubuntu.com/user/ID where ID is the content of file /var/lib/whoopsie/whoopsie-id on the machine. Do you find any links to recent problems on that page? If so then please send the links to us.

[Jeff Burdges (jeffburdges)]

It's only the three built in extensions installed.

Thanks I'll run journalctl -b-1 > prevboot.txt next time.

ls /var/crash/ says

_usr_lib_systemd_systemd-timesyncd.102.crash
_usr_lib_systemd_systemd-timesyncd.102.upload
_usr_lib_systemd_systemd-timesyncd.102.uploaded

I only see a similar error on

https://errors.ubuntu.com/user/f1e063bb5e8c4439fa13d51f06f02ce6ad03d098946e7597fd170a17325d98a76475f94a90f27677619cb85b6c0bd1cc406eece2601001754138f20d7209c37a

Is the lock screen handled by gnome-shell itself or some outside process like gdm3? If there some signal or whatever I can send to gnome-shell

[Daniel van Vugt (vanvugt)]

The lock screen is rendered by the gnome-shell process (which then sends the image to Xorg for display in the case of a Xorg session). gdm3 does nothing graphical, only launches other programs. Even the login screen is rendered by a gnome-shell process.

[Daniel van Vugt (vanvugt)]

You might be able to recover with something like:

  killall gnome-shell

or

  killall -9 gnome-shell

[Jeff Burdges (jeffburdges)]

It now manifests as a black screen with the same behavior, mouse works but no keyboard, except for Fn+Alt+Ctrl+F?? working.

I've attacked the output of journalctl but from the current boot since I used killall -HUP gnome-shell, which yes leave some applications running, but not firefox (or tor browser). It's much less common now but this one happened on suspend trigger by the lid being closed.

Thanks! :)

[Jeff Burdges (jeffburdges)]

Is it normal that gnome-session-bin is installed but gnome-session is not installed?

I believe this black screen version is different because when switching back with Fn+Ctrl+Alt+F1 it simply returns to the black screen, without any purple password prompt. I suppose another problem must be causing both versions.

[Daniel van Vugt (vanvugt)]

A log file covering 15 days (comment #7) is probably too long. Please be sure to follow the instructions in comment #2 when collecting a log file.

Please also repeat the steps in comment #3 in case a crash has happened recently.

[Jeff Burdges (jeffburdges)]

oops alright. I've no gnome-shell reports in /var/crash only another systemd-timesyncd report.

I don't think gnome-ghell is crashing, but sometimes just stuck when emerging from suspend.

[Daniel van Vugt (vanvugt)]

In that case, next time the problem happens please reboot and then run:

  journalctl -b-1 > prevboot.txt

and attach the resulting text file here.

[Jeff Burdges (jeffburdges)]

I'd something new this time, after sleep/suspend it returned to the purple login screen, but now nothing worked, no mouse or keyboard. It ran the fan for a little while, so I give it some time to return, but no luck.

[Jeff Burdges (jeffburdges)]

Also the Fn+Ctrl+Alt+F?? keys no longer worked here.

[Jeff Burdges (jeffburdges)]

I've also found folks fixed similar issues by downgrading the kernel to 5.11.0.38:
https://askubuntu.com/questions/1384450/ubuntu-20-04-wont-wake-from-suspend-or-completely-shutdown

[Daniel van Vugt (vanvugt)]

Thanks for that. The log in comment #12 shows these errors which may explain it:

--------
Mär 22 01:57:12 aletheia systemd[1]: systemd-logind.service: Watchdog timeout (limit 3min)!
Mär 22 01:57:12 aletheia systemd[1]: systemd-logind.service: Killing process 1501 (systemd-logind) with signal SIGABRT.
...
Mär 22 01:57:12 aletheia systemd[1]: systemd-logind.service: Main process exited, code=killed, status=6/ABRT
...
Mär 22 01:57:13 aletheia /usr/lib/gdm3/gdm-x-session[2486]: (EE)
Mär 22 01:57:13 aletheia /usr/lib/gdm3/gdm-x-session[2486]: Fatal server error:
Mär 22 01:57:13 aletheia /usr/lib/gdm3/gdm-x-session[2486]: (EE) systemd-logind disappeared (stopped/restarted?)
...
Mär 22 01:57:13 aletheia systemd-logind[95934]: Failed to restore VT, ignoring: Bad file descriptor
--------

And yes we expect "Fn+Ctrl+Alt+F??" to fail in this case because the processes which implement that combo have failed.

To be sure we're on the right track, please reboot, wait for the bug to occur again, and then redo:

  journalctl -b-1 > prevboot.txt

[Jeff Burdges (jeffburdges)]

I've also found folks fixed similar issues by downgrading the kernel to 5.11.0.38:
https://askubuntu.com/questions/1384450/ubuntu-20-04-wont-wake-from-suspend-or-completely-shutdown

[Daniel van Vugt (vanvugt)]

Sure, try a different kernel if you know how. There's a selection at:
https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D

Note that the current HWE kernel for 20.04 is version 5.13, not 5.11 anymore.

[Jeff Burdges (jeffburdges)]

It's related to during being suspended: It does not trigger on pressing suspend from the menu bar, waiting briefly, and then pressing keys to wake. It also does not trigger if I close and open the lid less than a minute later. It can now trigger if I close the lid and then reopen the lid 10 minutes later. At this point it arrives at a purple ubuntu login screen, but no responses to keyboard or mouse, and not network presence.

Could this be caused by the system changing sleep/suspend mode while sleeping/suspended?

Could this be related to /swapfile being only 4 gigs, while main memory is 16 gigs?

It's a ThinkPad X1 Carbon Gen 11 running a kernel 5.14.0-1027-oem for a Gen 9 (nothing else exists afaik). I've no idea what OEM kernels change of course, but I can try to figure out changing the kernel. I'll likely need to change something in /etc/default/grub to get access to a grub boot menu to choose kernels.

[Jeff Burdges (jeffburdges)]

I've found some lenovo firmware oddities too https://github.com/fwupd/firmware-lenovo/issues/210 so I'll poke around there too.

[Jeff Burdges (jeffburdges)]

Appears nope I've purely a sleep problem, unless all this fwupd playing turnned off hibernate:
```
root@aletheia:/home/jeff/Downloads# systemctl status hibernate.target
● hibernate.target - Hibernate
     Loaded: loaded (/lib/systemd/system/hibernate.target; static; vendor prese>
     Active: inactive (dead)
       Docs: man:systemd.special(7)
root@aletheia:/home/jeff/Downloads# systemctl status hybrid-sleep.target
● hybrid-sleep.target - Hybrid Suspend+Hibernate
     Loaded: loaded (/lib/systemd/system/hybrid-sleep.target; static; vendor pr>
     Active: inactive (dead)
       Docs: man:systemd.special(7)
```

[Jeff Burdges (jeffburdges)]

It's again waking with a black screen in which only mouse and Fn+Ctrl+Alt+F?? keys work. I've attached the jountalctl -b0 output from prior to reboot, probably more relevant than grabbing the actual reboot.

Mär 23 07:09:16 aletheia kernel: Restarting tasks ... done.
Mär 23 07:09:16 aletheia systemd-logind[1556]: Lid opened.
Mär 23 07:09:16 aletheia Tor[1683]: Tor has been idle for 26589 seconds; assuming established circuits no longer work.
Mär 23 07:09:16 aletheia rtkit-daemon[1766]: The canary thread is apparently starving. Taking action.
Mär 23 07:09:16 aletheia rtkit-daemon[1766]: Demoting known real-time threads.
Mär 23 07:09:16 aletheia rtkit-daemon[1766]: Demoted 0 threads.
Mär 23 07:09:16 aletheia Tor[1683]: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've sent 0 kB and received 0 kB.
Mär 23 07:09:16 aletheia systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Mär 23 07:09:16 aletheia kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Mär 23 07:09:16 aletheia kernel: thermal thermal_zone6: failed to read out thermal zone (-61)
Mär 23 07:09:16 aletheia systemd[1]: Starting Daily apt download activities...
Mär 23 07:09:16 aletheia systemd[1]: Starting Refresh fwupd metadata and update motd...
Mär 23 07:09:16 aletheia systemd[1]: Starting Message of the Day...
Mär 23 07:09:16 aletheia systemd[1]: Starting Ubuntu Advantage Timer for running repeated jobs...
Mär 23 07:09:16 aletheia systemd[1]: motd-news.service: Succeeded.
Mär 23 07:09:16 aletheia systemd[1]: Finished Message of the Day.
Mär 23 07:09:16 aletheia upowerd[1864]: treating change event as add on /sys/devices/pci0000:00/0000:00:14.0/usb3/3-3
Mär 23 07:09:16 aletheia upowerd[1864]: treating change event as add on /sys/devices/pci0000:00/0000:00:14.0/usb3/3-3
Mär 23 07:09:16 aletheia systemd-sleep[34855]: System resumed.
Mär 23 07:09:16 aletheia kernel: PM: suspend exit
Mär 23 07:09:16 aletheia gsd-power[2839]: Error calling suspend action: GDBus.Error:org.freedesktop.login1.OperationInProgress: There's already a shutdown or sleep operation in progress
Mär 23 07:09:16 aletheia fwupd[3148]: 06:09:16:0867 FuEngine failed to record HSI attributes: failed to get historical attr: json-glib version too old
Mär 23 07:09:16 aletheia systemd[1]: systemd-suspend.service: Succeeded.
Mär 23 07:09:16 aletheia systemd[1]: Finished Suspend.

We compare this semi-locked gnome-shell with a working unsleep from a brief lid close:

Mär 23 07:42:19 aletheia kernel: Restarting tasks ...
Mär 23 07:42:19 aletheia kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Mär 23 07:42:19 aletheia systemd-logind[1529]: Lid opened.
Mär 23 07:42:19 aletheia kernel: done.
Mär 23 07:42:19 aletheia upowerd[1838]: treating change event as add on /sys/devices/pci0000:00/0000:00:14.0/usb3/3-3
Mär 23 07:42:19 aletheia kernel: thermal thermal_zone6: failed to read out thermal zone (-61)
Mär 23 07:42:19 aletheia upowerd[1838]: treating change event as add on /sys/devices/pci0000:00/0000:00:14.0/usb3/3-3
Mär 23 07:09:16 aletheia systemd-sl...

[Jeff Burdges (jeffburdges)]

I'd another crash with a purple screen and no mouse movement, but this time only a 10 minute lid close caused the crash. Awful lot of gdm and gnome-shell errors this time, but not clear the source.

[Jeff Burdges (jeffburdges)]

It's growing kinda worst with 5.14.0-1031-oem in that gnome-shell now more reliably fails unsleep, but I've not yet seen any real crash under 5.14.0-1031-oem.

I've still not tried non OWM kernels.

[Jeff Burdges (jeffburdges)]

I've still not tried other kernels, in part because ubuntu keeps pushing out new OEM kernels, so I give them all a try, but the same basic problem persist, either gnome-shell gives only a black screen, or else the whole system hangs on the purple screen.

I've far more diverse crashes with the latest kernels and the bolt upgrade: https://errors.ubuntu.com/user/f1e063bb5e8c4439fa13d51f06f02ce6ad03d098946e7597fd170a17325d98a76475f94a90f27677619cb85b6c0bd1cc406eece2601001754138f20d7209c37a

[Jeff Burdges (jeffburdges)]

Another purple screen lockup. It's now also more common the system runs how while closed.

[Jeff Burdges (jeffburdges)]

This one seemed like it refused to wake even enough to draw a black scree, just stayed asleep. I've no idea if this is hlepful

[Jeff Burdges (jeffburdges)]

It's seemingly much less bad if I disable suspend when plugged into power, and maybe the remaining problems come from plugging in power before resume.

[Stefano Rivera (stefanor)]

Seeing exactly the same symptoms on a machine upgraded to 22.04, with wayland. Definitely seems suspend-related, but I haven't figured out what the problem is, yet.

[Raphaël Droz (raphael-droz)]

Same behavior with an Entroware laptop on 5.15.0-52-generic (both touchpad and internal keyboard, function keys work)

Hard to tell who's the culprit among the kernel, libusb, udev and gdm

One weird thing in the context of resuming : The Xorg.log generated by gdm shows:

(II) UnloadModule: "libinput" message
[...]
(II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 6)
[...]
(II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD, id 7)
[...]
(II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD, id 8)
(II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 9)
(II) XINPUT: Adding extended input device "Sleep Button" (type: KEYBOARD, id 10)

Typically:

[ 79.317] (II) config/udev: Adding input device Chicony USB2.0 Camera: Chicony (/dev/input/event9)
[ 79.317] (**) Chicony USB2.0 Camera: Chicony : Applying InputClass "libinput keyboard catchall"
[ 79.317] (II) Using input driver 'libinput' for 'Chicony USB2.0 Camera: Chicony '
[ 79.317] (II) systemd-logind: got fd for /dev/input/event9 13:73 fd 43 paused 0
[ 79.317] (**) Chicony USB2.0 Camera: Chicony : always reports core events
[ 79.317] (**) Option "Device" "/dev/input/event9"
[ 79.319] (II) event9 - Chicony USB2.0 Camera: Chicony : is tagged by udev as: Keyboard
[ 79.319] (II) event9 - Chicony USB2.0 Camera: Chicony : device is a keyboard
[ 79.319] (II) event9 - Chicony USB2.0 Camera: Chicony : device removed
[ 79.319] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input17/event9"
[ 79.319] (II) XINPUT: Adding extended input device "Chicony USB2.0 Camera: Chicony " (type: KEYBOARD, id 12)
[ 79.319] (**) Option "xkb_model" "pc105"
[ 79.319] (**) Option "xkb_layout" "fr"
[ 79.319] (**) Option "xkb_variant" "azerty"
[ 79.320] (II) event9 - Chicony USB2.0 Camera: Chicony : is tagged by udev as: Keyboard
[ 79.320] (II) event9 - Chicony USB2.0 Camera: Chicony : device is a keyboard

(a webcam tagged keyboard?)

I don't know if it's related, but if it is it could be a problem with udev rules during resume?