Bug 1168992 - GNOME X11 fails to get out of "Guest disable display" screen on graphical tty2 with mouse or keyboard
GNOME X11 fails to get out of "Guest disable display" screen on graphical tty...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: GNOME
Current
aarch64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
https://openqa.opensuse.org/tests/122...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-08 13:43 UTC by Guillaume GARDET
Modified: 2020-10-14 05:11 UTC (History)
11 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
full journal.log (213.50 KB, text/plain)
2020-04-08 13:43 UTC, Guillaume GARDET
Details
journal.log with gdb debug enabled for the lockscreen test (change_password) (413.80 KB, text/plain)
2020-04-29 08:49 UTC, Guillaume GARDET
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume GARDET 2020-04-08 13:43:58 UTC
Created attachment 835225 [details]
full journal.log

In snapshot 20200405, GNOME X11 has problems when switching from tty6 (command line) to graphical tty2.

openQA tests which fail:
* create_hdd_gnome-x11: https://openqa.opensuse.org/tests/1227758#step/shutdown/19
* update_Leap_15.0_gnome: https://openqa.opensuse.org/tests/1226540#step/consoletest_finish/29
* update_Leap_15.1_gnome: https://openqa.opensuse.org/tests/1226516#step/consoletest_finish/29

The relevant jounal.log part seems to be:
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) systemd-logind: got resume for 13:64
Apr 08 03:22:24 susetest kernel: rfkill: input handler disabled
Apr 08 03:22:24 susetest gsd-color[2012]: unable to get EDID for xrandr-Virtual-1: unable to get EDID for output
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) systemd-logind: got resume for 13:65
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) systemd-logind: got resume for 13:66
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) systemd-logind: got resume for 226:0
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) event0  - Power Button: is tagged by udev as: Keyboard
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) event0  - Power Button: device is a keyboard
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) event1  - QEMU QEMU USB Tablet: is tagged by udev as: Mouse
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) event1  - QEMU QEMU USB Tablet: device is a pointer
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) event2  - QEMU QEMU USB Keyboard: is tagged by udev as: Keyboard
Apr 08 03:22:24 susetest /usr/lib/gdm/gdm-x-session[1613]: (II) event2  - QEMU QEMU USB Keyboard: device is a keyboard
Apr 08 03:23:33 susetest gdm-password][4294]: gkr-pam: couldn't get the password from user: Conversation error
Apr 08 03:23:33 susetest gdm-password][4294]: pam_unix(gdm-password:auth): conversation failed
Apr 08 03:23:33 susetest gdm-password][4294]: pam_unix(gdm-password:auth): auth could not identify password for [bernhard]
Apr 08 03:24:21 susetest gdm-password][4310]: gkr-pam: couldn't get the password from user: Conversation error
Apr 08 03:24:21 susetest gdm-password][4310]: pam_unix(gdm-password:auth): conversation failed
Apr 08 03:24:21 susetest gdm-password][4310]: pam_unix(gdm-password:auth): auth could not identify password for [bernhard]
Apr 08 03:25:09 susetest gdm-password][4325]: gkr-pam: couldn't get the password from user: Conversation error
Apr 08 03:25:09 susetest gdm-password][4325]: pam_unix(gdm-password:auth): conversation failed
Apr 08 03:25:09 susetest gdm-password][4325]: pam_unix(gdm-password:auth): auth could not identify password for [bernhard]
Apr 08 03:25:57 susetest gdm-password][4342]: gkr-pam: couldn't get the password from user: Conversation error
Apr 08 03:25:57 susetest gdm-password][4342]: pam_unix(gdm-password:auth): conversation failed
Apr 08 03:25:57 susetest gdm-password][4342]: pam_unix(gdm-password:auth): auth could not identify password for [bernhard]
Comment 1 Guillaume GARDET 2020-04-09 06:41:52 UTC
It may be related to the fix in place for https://bugzilla.opensuse.org/show_bug.cgi?id=1163262 ?
Comment 2 Stefan Dirsch 2020-04-09 07:23:13 UTC
Hmm. This sounds unrelated, but feel free to remove

  GDK_BACKEND=x11

from /etc/X11/xinit/xinitrc.common in order to verify.
Comment 4 Stefan Dirsch 2020-04-24 08:32:08 UTC
Guillaume? ping...
Comment 5 Guillaume GARDET 2020-04-24 14:42:02 UTC
I did some testing. There is no X11 crash and I am able to switch from tty6 to tty2 manually.

The problem is we _are_ already in tty2, but with a "Guest disabled display".
Moving the mouse or hitting random keys does not bring back the screenlock. I need to switch to another tty (tty1 or tty6) and then get back to tty2 to show the unlock screen.

It seems that tty2 session does not receive any event (neither mouse, nor keyboard).
Comment 6 Guillaume GARDET 2020-04-24 14:44:03 UTC
Update title to match the actual problem
Comment 7 Stefan Dirsch 2020-04-24 14:57:41 UTC
Hmm. And this issue does not happen when removing 

 GDK_BACKEND=x11

from /etc/X11/xinit/xinitrc.common again?
Comment 8 Guillaume GARDET 2020-04-24 15:03:58 UTC
(In reply to Stefan Dirsch from comment #7)
> Hmm. And this issue does not happen when removing 
> 
>  GDK_BACKEND=x11
> 
> from /etc/X11/xinit/xinitrc.common again?

GDK_BACKEND=x11 is not part of /etc/X11/xinit/xinitrc.common with Snapshot 20200421.
Comment 9 Guillaume GARDET 2020-04-24 15:06:35 UTC
(In reply to Guillaume GARDET from comment #8)
> (In reply to Stefan Dirsch from comment #7)
> > Hmm. And this issue does not happen when removing 
> > 
> >  GDK_BACKEND=x11
> > 
> > from /etc/X11/xinit/xinitrc.common again?
> 
> GDK_BACKEND=x11 is not part of /etc/X11/xinit/xinitrc.common with Snapshot
> 20200421.

Would it be XDG_SESSION_TYPE=X11?
Comment 10 Stefan Dirsch 2020-04-24 15:09:59 UTC
(In reply to Guillaume GARDET from comment #9)
> (In reply to Guillaume GARDET from comment #8)
> > (In reply to Stefan Dirsch from comment #7)
> > > Hmm. And this issue does not happen when removing 
> > > 
> > >  GDK_BACKEND=x11
> > > 
> > > from /etc/X11/xinit/xinitrc.common again?
> > 
> > GDK_BACKEND=x11 is not part of /etc/X11/xinit/xinitrc.common with Snapshot
> > 20200421.
> 
> Would it be XDG_SESSION_TYPE=X11?

Yes, you're right. I mixed this up for some reason.  :-(
Comment 11 Guillaume GARDET 2020-04-24 19:41:01 UTC
(In reply to Stefan Dirsch from comment #7)
> Hmm. And this issue does not happen when removing 
> 
>  GDK_BACKEND=x11
> 
> from /etc/X11/xinit/xinitrc.common again?

Removing 'XDG_SESSION_TYPE=X11' does not change the behavior.
Comment 12 Yifan Jiang 2020-04-26 02:48:42 UTC
Hi Guillaume,

Thanks for reporting, am I right the issue happens on aarch64 only?

Except for the XDG_SESSION_TYPE environment, to fully exam the "culprits" you mentioned, would you like to try to add the string "org.gnome.SettingsDaemon.XSettings;" back to the right hand side of the "RequiredComponents" field in these two files:

> /usr/share/gnome-session/sessions/gnome.session
> /usr/share/gnome-session/sessions/gnome-classic.session

Namely, make the last line of the files look like:

> RequiredComponents=org.gnome.Shell;org.gnome.SettingsDaemon.A11ySettings;org.gnome.SettingsDaemon.Color;org.gnome.SettingsDaemon.Datetime;org.gnome.SettingsDaemon.Housekeeping;org.gnome.SettingsDaemon.Keyboard;org.gnome.SettingsDaemon.MediaKeys;org.gnome.SettingsDaemon.Power;org.gnome.SettingsDaemon.PrintNotifications;org.gnome.SettingsDaemon.Rfkill;org.gnome.SettingsDaemon.ScreensaverProxy;org.gnome.SettingsDaemon.Sharing;org.gnome.SettingsDaemon.Smartcard;org.gnome.SettingsDaemon.Sound;org.gnome.SettingsDaemon.Wacom;org.gnome.SettingsDaemon.XSettings;


Does it help to work around?
Comment 13 Guillaume GARDET 2020-04-27 09:33:06 UTC
(In reply to Yifan Jiang from comment #12)
> Hi Guillaume,
> 
> Thanks for reporting, am I right the issue happens on aarch64 only?

Yes, that's right.

> 
> Except for the XDG_SESSION_TYPE environment, to fully exam the "culprits"
> you mentioned, would you like to try to add the string
> "org.gnome.SettingsDaemon.XSettings;" back to the right hand side of the
> "RequiredComponents" field in these two files:
> 
> > /usr/share/gnome-session/sessions/gnome.session
> > /usr/share/gnome-session/sessions/gnome-classic.session
> 
> Namely, make the last line of the files look like:
> 
> > RequiredComponents=org.gnome.Shell;org.gnome.SettingsDaemon.A11ySettings;org.gnome.SettingsDaemon.Color;org.gnome.SettingsDaemon.Datetime;org.gnome.SettingsDaemon.Housekeeping;org.gnome.SettingsDaemon.Keyboard;org.gnome.SettingsDaemon.MediaKeys;org.gnome.SettingsDaemon.Power;org.gnome.SettingsDaemon.PrintNotifications;org.gnome.SettingsDaemon.Rfkill;org.gnome.SettingsDaemon.ScreensaverProxy;org.gnome.SettingsDaemon.Sharing;org.gnome.SettingsDaemon.Smartcard;org.gnome.SettingsDaemon.Sound;org.gnome.SettingsDaemon.Wacom;org.gnome.SettingsDaemon.XSettings;
> 
> 
> Does it help to work around?

Do you want I try with or without the XDG_SESSION_TYPE=X11?
Comment 14 Yifan Jiang 2020-04-27 09:49:48 UTC
> Do you want I try with or without the XDG_SESSION_TYPE=X11?

I think it makes sense to try both with and without the variable, if it's convenient. Thank you.
Comment 15 Guillaume GARDET 2020-04-27 13:59:47 UTC
(In reply to Yifan Jiang from comment #14)
> > Do you want I try with or without the XDG_SESSION_TYPE=X11?
> 
> I think it makes sense to try both with and without the variable, if it's
> convenient. Thank you.

Adding "org.gnome.SettingsDaemon.XSettings;" back to the right hand side of the "RequiredComponents" field in these two files:
  /usr/share/gnome-session/sessions/gnome.session
  /usr/share/gnome-session/sessions/gnome-classic.session

and keeping XDG_SESSION_TYPE=X11 fixed the current problem.
Comment 16 Yifan Jiang 2020-04-28 00:51:38 UTC
Hi Guillaume,

Thank you for the information. When the issue is reproduced, would you help to gather the journal log again with the debug option opened:

  /etc/gdm/custom.conf
  [debug]
  # Uncomment the line below to turn on debugging
  Enable=true
Comment 17 Yifan Jiang 2020-04-28 00:52:53 UTC
I am appending this to Xiaoguang's expertise queue, thanks!
Comment 18 Guillaume GARDET 2020-04-28 14:09:29 UTC
(In reply to Yifan Jiang from comment #16)
> Hi Guillaume,
> 
> Thank you for the information. When the issue is reproduced, would you help
> to gather the journal log again with the debug option opened:
> 
>   /etc/gdm/custom.conf
>   [debug]
>   # Uncomment the line below to turn on debugging
>   Enable=true

When I set the debug to true, I have no problem anymore...
Comment 19 Guillaume GARDET 2020-04-28 14:44:43 UTC
The problem seems to be with a power saving mode.

If I run the test on a faster system (or if I drop a test module to be faster between tty2=>tty6 and tty6=>tty2 switches), the lockscreen is shown, but no power saving mode starts (probably due to the small amount of time in non graphical mode) and the switch from tty6 to tty2 is working properly. See: https://openqa.opensuse.org/tests/1247812#step/shutdown/1

The problem also appears when screenlock is explicitly triggered (and probably also triggers some power saving mode) and 'esc' key is sent to try to get out of the 'Guest disabled display' screen. See: https://openqa.opensuse.org/tests/1247871#step/change_password/33
Comment 20 xiaoguang wang 2020-04-29 02:17:36 UTC
(In reply to Guillaume GARDET from comment #19)

> The problem also appears when screenlock is explicitly triggered (and
> probably also triggers some power saving mode) and 'esc' key is sent to try
> to get out of the 'Guest disabled display' screen. See:
> https://openqa.opensuse.org/tests/1247871#step/change_password/33

There is some error when you want to trigger the unlock screen.

> Apr 28 09:48:53 susetest gdm-password][2754]: pam_unix(gdm-password:auth): auth could not identify password for [bernhard]
> Apr 28 09:50:15 susetest gdm-password][2766]: gkr-pam: couldn't get the password from user: Conversation error
> Apr 28 09:50:15 susetest gdm-password][2766]: pam_unix(gdm-password:auth): conversation failed
> Apr 28 09:50:15 susetest gdm-password][2766]: pam_unix(gdm-password:auth): auth could not identify password for [bernhard]
> Apr 28 09:51:37 susetest gdm-password][2794]: gkr-pam: couldn't get the password from user: Conversation error
> Apr 28 09:51:37 susetest gdm-password][2794]: pam_unix(gdm-password:auth): conversation failed
> Apr 28 09:51:37 susetest gdm-password][2794]: pam_unix(gdm-password:auth): auth could not identify password for [bernhard]

Could you open the gdm debug info, and do the up test again?

  /etc/gdm/custom.conf
  [debug]
  # Uncomment the line below to turn on debugging
  Enable=true

The change takes effect after system restarts.
Comment 21 Guillaume GARDET 2020-04-29 08:49:30 UTC
Created attachment 837049 [details]
journal.log with gdb debug enabled for the lockscreen test (change_password)

Here is the journal.log with gdb debug enabled for the lockscreen test (change_password).
Comment 22 xiaoguang wang 2020-04-30 07:06:18 UTC
I can reproduce the issue on my virtual machine.

Arch: X86_64
Host: Tumbleweed snapshot 20200425
Guest: Tumbleweed snapshot 20200425

virtual gpu: virtio

change guest to let guest work on X:
  /etc/gdm/custom.conf
  [daemon]
  # Uncomment the line below to force the login screen to use Xorg
  WaylandEnable=false

After you input the user password, screen shows 'Guest disabled display'. Now if you change tty to tty1, and then change back to tty2, you can see normal desktop. Now you lock the screen, you see the 'Guest disabled display' again, press the key or move the mouse, screen still shows 'Guest disabled display'. Then you change tty to tty1 and change back to tty2, you can see the unlock screen.

If I change virtual gpu to VGA or QXL, I can't meet this issue.
So I guess the issue relates with virtio.
Comment 23 xiaoguang wang 2020-04-30 08:24:38 UTC
Do more tests:
 Guest works on wayland with virtio, QXL and VGA, no issue.
 Guest works on X with QXL and VGA, no issue.
 Guest works on X with virtio, issue happens.

So maybe the issue relates with virtio or X.
Comment 24 Stefan Dirsch 2020-04-30 14:15:31 UTC
This bug remindes me to another similar or possibly identical bug, where I suggested to disable Wayland on aarch64 with virtio. Unfortunately I can't find it any more. Thomas, could you help me here? We both discussed it lately.
Comment 25 Guillaume GARDET 2020-05-11 12:12:46 UTC
(In reply to Stefan Dirsch from comment #24)
> This bug remindes me to another similar or possibly identical bug, where I
> suggested to disable Wayland on aarch64 with virtio. Unfortunately I can't
> find it any more. Thomas, could you help me here? We both discussed it
> lately.

IMHO, ignoring a bug is not a solution.
Comment 26 Stefan Dirsch 2020-05-11 12:32:22 UTC
(In reply to Guillaume GARDET from comment #25)
> (In reply to Stefan Dirsch from comment #24)
> > This bug remindes me to another similar or possibly identical bug, where I
> > suggested to disable Wayland on aarch64 with virtio. Unfortunately I can't
> > find it any more. Thomas, could you help me here? We both discussed it
> > lately.
> 
> IMHO, ignoring a bug is not a solution.

You're right. It is not. And this wasn't my attention either. @Thomas, could you help here? Unfortunately I really can't find the other bug any longer. :-(
Comment 27 Thomas Zimmermann 2020-05-11 12:49:54 UTC
(In reply to Stefan Dirsch from comment #26)
> (In reply to Guillaume GARDET from comment #25)
> > (In reply to Stefan Dirsch from comment #24)
> > > This bug remindes me to another similar or possibly identical bug, where I
> > > suggested to disable Wayland on aarch64 with virtio. Unfortunately I can't
> > > find it any more. Thomas, could you help me here? We both discussed it
> > > lately.
> > 
> > IMHO, ignoring a bug is not a solution.
> 
> You're right. It is not. And this wasn't my attention either. @Thomas, could
> you help here? Unfortunately I really can't find the other bug any longer.
> :-(

Do you mean bug 1169203?
Comment 28 Stefan Dirsch 2020-05-11 13:03:58 UTC
(In reply to Thomas Zimmermann from comment #27)
> (In reply to Stefan Dirsch from comment #26)
> > (In reply to Guillaume GARDET from comment #25)
> > > (In reply to Stefan Dirsch from comment #24)
> > > > This bug remindes me to another similar or possibly identical bug, where I
> > > > suggested to disable Wayland on aarch64 with virtio. Unfortunately I can't
> > > > find it any more. Thomas, could you help me here? We both discussed it
> > > > lately.
> > > 
> > > IMHO, ignoring a bug is not a solution.
> > 
> > You're right. It is not. And this wasn't my attention either. @Thomas, could
> > you help here? Unfortunately I really can't find the other bug any longer.
> > :-(
> 
> Do you mean bug 1169203?

Yes, exactly! Thanks a lot! Guillaume is already included there as well ...
Comment 36 Guillaume GARDET 2020-09-15 09:42:48 UTC
How could we move forward here? This problem blocks a number of tests in openQA for a long time now.
Comment 37 Oliver Kurz 2020-09-15 09:47:34 UTC
I would have hoped that the assignee, i.e. gnome-bugs@suse.de would react here. Unfortunately did not happen so far.
Comment 38 Yifan Jiang 2020-09-16 07:35:57 UTC
I am a bit not sure how is this bug related with bsc#1169203, which literally reported a performance issue when GNOME runs over Wayland. However this bug was analyzed as happened on X11 (see comment#23).
Comment 39 xiaoguang wang 2020-09-16 07:53:57 UTC
The tests in comment#23 was on X86.
Comment 40 Guillaume GARDET 2020-09-24 06:36:46 UTC
Last Tumbleweed snapshot (20200922) was successful: https://openqa.opensuse.org/tests/1403835

One candidate for the fix is the kernel with 'drm/virtio: fix unblank': https://patchew.org/QEMU/20200807105429.24208-1-kraxel@redhat.com/

Let's see if next runs are fine as well.
Comment 41 Guillaume GARDET 2020-09-29 13:02:26 UTC
The last runs confirm the problem is gone.