Only Cursor Visible on Log In after suspend

[candiedoperation]

What Happened

The following behavior does not happen always. It happens approximately once in five times even in a clean install.

On closing the laptop lid, elementary OS (referred to as eOS hereafter) is set to suspend (default). On closing the lid, eOS suspends normally. On opening the lid, the eOS resumes and shows me the login greeter.

On logging in, I am greeted with a black screen with the mouse pointer moving when I use the trackpad. None of the windows are visible, no wingpanel, no plank, nothing but only a black screen with a Mouse Pointer.

When I use three-finger up gesture, I see the multitasking view open, all the windows are displayed as usual in multitasking view. Once I close multitasking view (three-finger down) again the screen turns black with only the mouse pointer visible.

Keyboard shortcuts like ⌘ + S for multitasking view also do not work

Expected Behavior

On logging in, I am greeted with a black screen with the mouse pointer moving when I use the track-pad. None of the windows are visible, no wingpanel, no plank, nothing but only a black screen with a Mouse Pointer instead of how eOS normally works.

No such issue persisted in Elementary OS 5 (Hera)

Steps to Reproduce

The following behavior does not happen always. It happens approximately once in five times even in a clean install.

1. Close the lid, eOS automatically suspends
2. Open the lid, Login Greeter is displayed
3. Enter your credentials and login, A Black screen with only a mouse pointer is visible and only track-pad gestures work

On logging in,

On using three-finger up touchpad gesture, (⌘ + S does not work)

On closing multitasking view (three finger down),

I tried killing gala using htop in tty6 (Ctrl + Alt + F6) and retured to tty7. On doing this, I observed that all windows were visible no black screen (Of course, the windows were misaligned and I could not use the apps as I killed gala). I did not try restarting gala as I neither could open a terminal in tty7 due to the black screen on login nor did I try it using the CLI in tty6 as I did not know how to.

Logs

Trying to fetch gala logs.

Platform Information

Operating System: elementary OS 6
Edition: (Public Beta)
Hardware Information:

• Quad-Core Intel® Core™ i5-8250U CPU @ 1.60GHz
• Intel® UHD Graphics 620 (Kabylake GT2)
• 7.7 GiB memory
• 467.2 GB storage (SSD)

Laptop Information: HP Pavilion x360

[candiedoperation]

Found that someone else also has the same issue, check out issue #1064.

[davidmhewitt]

Thanks for the report! This is something I haven't been able to reproduce, but hopefully you'll be able to gather some more info to help track it down.

It should be possible to restart gala from the TTY after killing it by running:

DISPLAY=:0 gala &

Next time this happens, could you gather some logs with:

journalctl | grep gala

[candiedoperation]

Sure @davidmhewitt, I am glad to help and I will gather the logs and post it here the next time this issue occurs.
The issue does not occur every time I suspend but, in 2 days (after Clean Install eOS 6 Public Beta) the issue persisted 5 times.

Approximately, On suspending 15 times, the issue occurs at least 5 times.

[candiedoperation]

Thanks for the report! This is something I haven't been able to reproduce, but hopefully you'll be able to gather some more info to help track it down.

It should be possible to restart gala from the TTY after killing it by running:

DISPLAY=:0 gala &

Next time this happens, could you gather some logs with:

journalctl | grep gala

Hi there @davidmhewitt,
There's a stunning discovery I've made in regards to this issue.

• This issue as mentioned above does not happen randomly
• The steps to reproduce the issue is listed again below

Steps to Reproduce

Taking tty7 as the default GUI interface in eOS,

1. Turn On your computer running elementary OS 6 (Public Beta)
2. Login when the greeter is displayed, everything works as expected
3. Now Ctrl + Alt + F6 to switch to tty6
4. Login to tty6, execute some command (I used htop)
5. Switch to tty7 and use the GUI to suspend (or close the laptop lid) [Do not type exit or logout in tty6 to close tty6]
6. On opening the lid, the login greeter displays, Login with your credentials
7. Boom! You will be seeing the issue now

Logs

Download the Log File Here

[davidmhewitt]

I can't reproduce the issue by following those steps exactly. I tried both suspending from the GUI and by closing the laptop lid. The system resumed correctly in both cases.

There's nothing obvious in your logs either.

You could try the following to get some more in-depth debug logs:

1. Edit /usr/share/applications/gala.desktop
2. Change the Exec=gala line to:

Exec=env G_MESSAGES_DEBUG=all gala

3. Reboot the computer
4. Reproduce the issue
5. Gather logs again with journalctl | grep gala

[candiedoperation]

I can't reproduce the issue by following those steps exactly. I tried both suspending from the GUI and by closing the laptop lid. The system resumed correctly in both cases.

There's nothing obvious in your logs either.

You could try the following to get some more in-depth debug logs:

1. Edit /usr/share/applications/gala.desktop
2. Change the Exec=gala line to:

Exec=env G_MESSAGES_DEBUG=all gala

1. Reboot the computer
2. Reproduce the issue
3. Gather logs again with journalctl | grep gala

I forgot to mention something in step 6 (Steps to reproduce), writing them here again:

Steps to reproduce

Taking tty7 as the default GUI interface in eOS,

1. Turn On your computer running elementary OS 6 (Public Beta)
2. Login when the greeter is displayed, everything works as expected
3. Now Ctrl + Alt + F6 to switch to tty6
4. Login to tty6, execute some command (I used htop)
5. Switch to tty7 and use the GUI to suspend (or close the laptop lid) [Do not type exit or logout in tty6 to close tty6]
6. On opening the lid, the login greeter displays, Login with your credentials Switch to tty6 and then to tty7
7. Boom! You will be seeing the issue now

[davidmhewitt]

Thanks, I can reproduce this now. There are definitely some broken things, but seeing a black screen on tty7 before unlocking is kind of expected.

The greeter runs on tty8, so tty7 should be "locked" until you put your password in. It's clearly not locked well enough since you can use gestures and hotcorners etc.

But also, after I unlocked the session in tty8, the unlocked session in tty7 was kind of broken too.

Thanks for this, at least I can now reproduce these issues for testing and development. I'll keep this updated as I find/fix things.

[candiedoperation]

Thanks, I can reproduce this now. There are definitely some broken things, but seeing a black screen on tty7 before unlocking is kind of expected.

The greeter runs on tty8, so tty7 should be "locked" until you put your password in. It's clearly not locked well enough since you can use gestures and hotcorners etc.

But also, after I unlocked the session in tty8, the unlocked session in tty7 was kind of broken too.

Thanks for this, at least I can now reproduce these issues for testing and development. I'll keep this updated as I find/fix things.

Welcome @davidmhewitt

[candiedoperation]

@davidmhewitt, Another additional piece of information related to this problem. After the display in elementary OS 6 dims automatically on timeout, the greeter is displayed on cursor movement. When I log in the same issue of a black screen with a cursor occurs.

By Auto-Dimming, I refer to the turn off display when inactive for setting Switchboard Power Plugin:

[hanaral]

So for anyone else wanting to test this;
The prerequisites are:

• System Settings > Power > 'Turn display off when inactive for' has to be set to something lower than the suspend time
• System Settings > Security & Privacy > Locking > 'Lock after screen turns off' has to be on

To reproduce:

1. Wait until the display turns off from inactivity
2. Wake the display and log in

You now should be stuck in a session where the normal desktop view is blocked, apart from when using the multitasking view gesture. I haven't been able to get it to recognise keyboard input (incl. power or suspend)

Edit: @candiedoperation are you also able to reproduce this by locking manually with ctrl+L?

---

@davidmhewitt From some speculation I already had on this issue over the last half-year (?) before seeing this issue and realising its cause, I may have an idea of the logical problem causing it;
the issue seems to be the fading to black effect being 'frozen' because the system locks itself in sync with that effect, meaning that it never 'resets' its opacity and function - so maybe anyone willing could take a look at how the fade-out effect starts and stops
nevermind it seems to be linked to the screen shield directly, since locking manually and closing the lid can trigger it too (albeit inconsistently)

[alfredit]

Problem seen on a thinkpad x1
log.txt

[sjlua]

Happens on my Lenovo Yoga 370 as well.
Core i5 7th Gen
8GB RAM

[btazi]

Happens on my MSI Creator 17m
CPU: Intel i7-10750H
GC: NVIDIA GeForce GTX 1660 Ti Mobile

[kapiljhajhria]

I faced the exact same issue on the latest odin stable build as well. Had to force reboot my laptop

My laptop

MSI GF63 thin 9SC
9th gen intel i5
NVIDIA GeForce GTX 16650 Max Q
Nvidia Drivers 470 (latest)

[shawn1thompson]

When afflicted by this issue, I discovered I can mouse to the top-right corner (assuming the gesture is setup) and reveal Multi-tasking view which allows me to close applications. Then Ctrl+Alt F2 for a terminal login, login, and sudo reboot instead of forcing a shutdown. This should reduce chances of disk corruption.

[joajimenez]

Happening in my Dell Inspiron-15-3573.

[ameyrk99]

So, it seems that the steps I gave below are not working for all the people; Hence I have crossed it out. I did not change anything but this to fix the issue but I will check and see if that isn’t the case and update it here.

Experiencing the same issue with my HP Envy x360.

But I wanted a temporary fix and found this thread regarding Freya https://elementaryos.stackexchange.com/a/591

• Run sudo -i vim /etc/default/acpi-support
• Find and change POST_VIDEO=true to POST_VIDEO=false
• Find and change SAVE_VBE_STATE=true to SAVE_VBE_STATE=false
• Restart your laptop, issue should be solved.
  So far, after updating the above values, I have not encountered the issue again. Hopefully, it is fixed within gala itself.

Before someone tries the above method, I am basing the result solely of my experience; I am not sure how the issue is related to warm-booting video hardware or VESA BIOS extentions never having worked on gala

[btazi]

@ameyrk99 that didn't work for me unfortunately.

[tomaswarynyca]

@JoseExposito Do you have any idea what might be going on here?

[alfredit]

Experiencing the same issue with my HP Envy x360.

But I wanted a temporary fix and found this thread regarding Freya https://elementaryos.stackexchange.com/a/591

* Run `sudo -i vim /etc/default/acpi-support`

* Find and change `POST_VIDEO=true` to `POST_VIDEO=false`

* Find and change `SAVE_VBE_STATE=true` to `SAVE_VBE_STATE=false`

* Restart your laptop, issue should be solved.

So far, after updating the above values, I have not encountered the issue again. Hopefully, it is fixed within gala itself.

Before someone tries the above method, I am basing the result solely of my experience; I am not sure how the issue is related to warm-booting video hardware or VESA BIOS extentions never having worked on gala

Not working for me (X1 carbon), bug still here

[davidmhewitt]

I identified an issue within the power settings pane that meant if you opened that and changed a setting within there, the next unlock would result in these symptoms. However, I'm still struggling to reproduce this issue under "normal" circumstances.

Anyone that can reproduce this reliably, please do the following:

• Reboot
• Without doing anything else first, trigger the issue (i.e. try to unlock and see the blank screen with cursor)
• Switch to a TTY with Ctrl+Alt+F1
• Login
• Run sudo journalctl > ~/log.txt
• Reboot
• Upload log.txt from your home folder to this issue.

[alfredit]

log.txt
log2.txt
Hi,

Log1 :
Here are my log. Opened my computer at 22:32 after a day of working. It was in sleep and crashed. Did ctrl alt F1 and ctrl alt suppr to reboot directly after. on this crash I was with this options still on : " POST_VIDEO=true to POST_VIDEO=false..."
I changed my power settings after the clean install of the OS, but I do not remember the default settings to test.

I have :
*Auto brightness on,
*sleep when closing the lid
*when closed with external screen : no action (very clever setting!)
*on battery and AC : 30min sleep if in active

Log2 : after testing the brightness bug (brightness up and down till no change possible on the screen) , I closed my laptop and opened it. This reproduced the sleep bug.

[davidmhewitt]

@alfredit Thanks!

Have you cut the end of the first log in some way, or is that where it ended? From the first one, it looks like you didn't attempt to unlock? Did the system crash before you could unlock? Because that's different again.

I also don't need logs when the bug happens immediately after changing settings/brightness in the power settings, as that will soon be fixed.

I need logs from when you wake the system, unlock by entering password and then the screen is blank (except the mouse cursor), like the issue description.

[alfredit]

Hi,

*Log1, In fact I remember telling me "oh crap" and rebooted the coputer too quickly before the big black screen. My journalctl is
kind of big and with too much personal stuff so I grep it on the good dates.

*log2 , did the unlock, seen the black screen with "expose" bug, exported log via journalctl and rebooted. Think log 2 is way more clean to check

*I have installed the patch about the brightness bug released 2 min ago on my repo (the power setting update) and since those 2 are linked together, I will check if I can reproduce the sleep bug or if it is resolved.

[nathanaelg]

I can't reproduce this all the time but it does happen reasonably often. I collected the journalctl log and just limited it to the bit after Lid closed. I hadn't set gala to log debug messages so not sure if there's anything useful. Killing gala from tty1 made things mostly come back (it restarted by itself).

[alfredit]

Hi @davidmhewitt , for me the latest update resolved the issue (or I cannot manage to reproduce it anymore). Thanks for your help.

@nathanaelg , can you check for the latest updates and see if it is okay now? looking for this one : switchboard-plug-power:amd64.

[davidmhewitt]

I can't reproduce this all the time but it does happen reasonably often. I collected the journalctl log and just limited it to the bit after Lid closed. I hadn't set gala to log debug messages so not sure if there's anything useful. Killing gala from tty1 made things mostly come back (it restarted by itself).

@nathanaelg Thanks, that's an interesting log. Near the top you have:

Aug 25 13:24:19 chiron gala[1554]: ScreenShield.vala:421: Unable to set locked hint on login session: GDBus.Error:org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/c2'.

So it looks like your login session has died somehow. If you still have the logs from that boot, can you scour further up for any reference to session "c2" dying or logind stopping/restarting and why it might have happened. Searching for "c2" or "logind" is probably a good start.

This is what was happening with the Switchboard power plug. Changing settings in there was causing an issue with logind, which then broke the session, but if you hadn't done anything with the Power plug in that session, there may be another cause somewhere else that we need to track down.

[tomaswarynyca]

@davidmhewitt after installing the patch it doesn't happen so often, but it just happened to me, so there is another problem here too. I attach log.txt so you can see what might be going on.

[davidmhewitt]

@tomaswarynyca Thanks for the log. I see the same message as what was in @nathanaelg 's log at 11:00 :

ago 25 11:00:34 ASUS-X512DA gala[41138]: ScreenShield.vala:421: Unable to set locked hint on login session: GDBus.Error:org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/c8'

logind restarts at 10:26 which is what causes the issue at 11:00.

ago 25 10:26:20 ASUS-X512DA dbus-daemon[1287]: [system] Activating service name='io.elementary.logind.helper' requested by ':1.434' (uid=1000 pid=52089 comm="/usr/bin/io.elementary.switchboard ") (using servicehelper)
ago 25 10:26:20 ASUS-X512DA dbus-daemon[1287]: [system] Successfully activated service 'io.elementary.logind.helper'
ago 25 10:26:20 ASUS-X512DA io.elementary.s[52089]: Attempting to add a widget with type GtkGrid to a container of type PowerBehaviorView, but the widget is already inside a container of type GtkGrid, please remove the widget from its existing container first.
ago 25 10:26:20 ASUS-X512DA dbus-daemon[1287]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.434' (uid=1000 pid=52089 comm="/usr/bin/io.elementary.switchboard ")
ago 25 10:26:20 ASUS-X512DA systemd[1]: Starting Hostname Service...
ago 25 10:26:20 ASUS-X512DA dbus-daemon[1287]: [system] Successfully activated service 'org.freedesktop.hostname1'
ago 25 10:26:20 ASUS-X512DA systemd[1]: Started Hostname Service.
ago 25 10:26:25 ASUS-X512DA systemd[1]: Stopping Login Service...
ago 25 10:26:25 ASUS-X512DA dbus-daemon[1287]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service' requested by ':1.330' (uid=1000 pid=41138 comm="gala ")
ago 25 10:26:25 ASUS-X512DA systemd[1]: systemd-logind.service: Succeeded.
ago 25 10:26:25 ASUS-X512DA systemd[1]: Stopped Login Service.
ago 25 10:26:25 ASUS-X512DA systemd[1]: Condition check resulted in Load Kernel Module drm being skipped.
ago 25 10:26:25 ASUS-X512DA systemd[1]: Starting Login Service...
ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: New seat seat0.
ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: Failed to add user by file name 1000, ignoring: Invalid argument
ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: User enumeration failed: Invalid argument
ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: User of session c8 not known.
ago 25 10:26:26 ASUS-X512DA systemd-logind[52108]: User of session c1 not known.

Those log lines look exactly like what would happen with the old version of the Switchboard Power plug before it was fixed. When did you install the new version and was Switchboard restarted to ensure the new version was loaded?

[tomaswarynyca]

Yes, install and restart
I will reinstall and see what happens, I will keep you updated.

[alfredit]

Hi, case closed for my computer, I have new bugs (io.elementary.greeter not responding) but not this one ! Thanks a lot

[tomaswarynyca]

I reinstalled the package by doing "--purge" and so far so good @davidmhewitt
If you agree @candiedoperation this issue is resolved and we can close it !!

[alx242]

This happened to me on the latest Odin release and I could fix it by doing the uninstall and then reinstall of the switchboard-plug-power package.

But why did it even happen to begin with? I might have done some modification to the settings of the power but it seems pretty fragile if that was the cause of it?

Hopefully this can be fixed to make things a bit more stable.

--edit--

Guess this issue still exists for me.

Here is my log.txt from when this happened again this morning. I should probably turn on the debug flag also but didn't have that active when I ran into the issue again. I will supply this next time I run into it :)

[alx242]

Here is the full log.txt of my reproduction.

I just need to activate suspend and then this happens instantly upon resume. I have tried to reinstall the switchboard-plug-power package but that didn't fix the problem.

-- edit --

I just replicated the issue by only locking my screen. Is this handled by lightdm or? In that case it might be the culprit...

-- follow up --

Since it felt like lightdm was acting up I decided to install lightdm-settings and add myself to the lightdm group to run that tool. Now my machine can lock and suspend again without problem. Perhaps the issue is somewhere in the stack of lightdm/greeter/gala. I don't use the installed greeter by elementary any longer but at least my system isn't going bonkers with these issues atm.

[abbazs]

Reinstalling elementaryos fixed the issue for me.

[matthiasjg]

It seems I managed to "fix"(?) this for me by (finally) giving in and installing the nvidia drivers (via sudo ubuntu-drivers autoinstall). 👀 🤔

I'm on a Lenovo T25 (T470) w/ NVIDIA GeForce 940MX alongside Intel HD Graphics 620.

Anyone else with dual graphics seeing this?

[rreina]

This issue is still happening under Elementary OS 7.
Please see below for more info and a workaround:

MacBook Pro 15” mid 2015. Intel HD graphics (no dual graphics)

Tested kernels:

• Linux 5.15.0-60-generic (latest update from stable channels)
• Linux 5.19.0-32-generic
• Packages: Greeter 6.1.1 & Gala 7.0.0

It is not necessary to suspend the system. It happens every time the screen locks by closing the lid or even locking from the power icon indicator. After login back to your account you get the black screen with cursor.

This bug is a duplicate of Elementary - Greeter #525. All points to Pantheon Greeter in need of a fix.

Workaround:

1. Turn-on suspend when closing the lid in power settings:
   
2. Fully disable locking the screen in the security & privacy settings:
   

Result: your laptop suspends when closing the lid, hence saving power, and when your open it back you're logged in skipping the black screen bug.

[ghost]

for all apps and processeces is quited ith an quit code 1x1

[ghost]

gala not respoding

[ghost]

tru ctrl alt f2 type gala

[ghost]

logind not responiidng

[ghost]

you require factory reset

[AlexFBP]

Thanks for the report! This is something I haven't been able to reproduce, but hopefully you'll be able to gather some more info to help track it down.

It should be possible to restart gala from the TTY after killing it by running:

DISPLAY=:0 gala &

Next time this happens, could you gather some logs with:

journalctl | grep gala

Just in case, this just happened to me. As this happened to me some other times in the past, I found again this issue to attempt the DISPLAY=:0 gala & with no success, I also tried gala with --replace as suggested after failed, but failed too...

So i decided to just reboot but first I dumped the logs below with:

journalctl -g gala --no-pager > gala.log

gala.log - "Normal" (without sudo)
gala-adm.log - With sudo

My setup: elementary OS 6.1, Intel® Core™ i7-6700T CPU @ 2.80GHz quad core, Intel® HD Graphics 530 (Skylake GT2), 31.2GiB RAM