Open candiedoperation opened 3 years ago
Found that someone else also has the same issue, check out issue https://github.com/elementary/gala/issues/1064.
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
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.
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.
Taking tty7
as the default GUI interface in eOS,
Ctrl + Alt + F6
to switch to tty6
tty6
, execute some command (I used htop
)tty7
and use the GUI to suspend (or close the laptop lid) [Do not type exit
or logout
in tty6
to close tty6
]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:
/usr/share/applications/gala.desktop
Exec=gala
line to:
Exec=env G_MESSAGES_DEBUG=all gala
journalctl | grep gala
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:
- Edit
/usr/share/applications/gala.desktop
- Change the
Exec=gala
line to:Exec=env G_MESSAGES_DEBUG=all gala
- Reboot the computer
- Reproduce the issue
- Gather logs again with
journalctl | grep gala
I forgot to mention something in step 6 (Steps to reproduce), writing them here again:
Taking tty7 as the default GUI interface in eOS,
tty6
and then to tty7
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.
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
@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:
So for anyone else wanting to test this; The prerequisites are:
To reproduce:
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)
This is still present in the final version You could focus here, it is a critical issue @danrabbit @cassidyjames
Happens on my Lenovo Yoga 370 as well. Core i5 7th Gen 8GB RAM
Happens on my MSI Creator 17m CPU: Intel i7-10750H GC: NVIDIA GeForce GTX 1660 Ti Mobile
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)
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.
Happening in my Dell Inspiron-15-3573.
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
sudo -i vim /etc/default/acpi-support
POST_VIDEO=true
to POST_VIDEO=false
SAVE_VBE_STATE=true
to SAVE_VBE_STATE=false
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
@ameyrk99 that didn't work for me unfortunately.
@JoseExposito Do you have any idea what might be going on here?
The steps described in https://github.com/elementary/switchboard-plug-power/issues/200 seem to consistently reproduce this problem on my machine (XPS 9500). Thanks @tomaswarynyca for pointing me at this issue.
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
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:
sudo journalctl > ~/log.txt
log.txt
from your home folder to this issue.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.
@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.
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.
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).
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.
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.
@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.
@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?
Yes, install and restart I will reinstall and see what happens, I will keep you updated.
Hi, case closed for my computer, I have new bugs (io.elementary.greeter not responding) but not this one ! Thanks a lot
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 !!
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 :)
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.
Reinstalling elementaryos
fixed the issue for me.
It seems I managed to "fix"(?) this for me by (finally) giving in and installing the nvidia drivers (via sudo ubuntu-drivers autoinstall
). :eyes: :thinking:
I'm on a Lenovo T25 (T470) w/ NVIDIA GeForce 940MX
alongside Intel HD Graphics 620
.
Anyone else with dual graphics seeing this?
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:
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:
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.
for all apps and processeces is quited ith an quit code 1x1
gala not respoding
tru ctrl alt f2 type gala
logind not responiidng
you require factory reset
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
What Happened
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
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
usinghtop
intty6
(Ctrl + Alt + F6) and retured totty7
. 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 intty7
due to the black screen on login nor did I try it using the CLI intty6
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:
Laptop Information: HP Pavilion x360