Description of problem: CentOS Stream 8 no longer allows you to login to an Xfce session from the gdm greeter, you are bounced back to gdm after a delay. Version-Release number of selected component (if applicable): xfce4-session-4.16.0-3.el8.x86_64 How reproducible: Always. Steps to Reproduce: 1. Update CentOS Stream 2. Try to login to Xfce 3. Actual results: You are bounced back to gdm after a delay. Expected results: Should login to Xfce. Additional info: This has happened after a recent wave of CentOS Stream updates. The update set that broke things is shown below (gleaned from the dnf.log file). NetworkManager x86_64 1:1.34.0-0.2.el8 baseos 2.7 M NetworkManager-adsl x86_64 1:1.34.0-0.2.el8 baseos 145 k NetworkManager-bluetooth x86_64 1:1.34.0-0.2.el8 baseos 171 k NetworkManager-libnm x86_64 1:1.34.0-0.2.el8 baseos 1.8 M NetworkManager-team x86_64 1:1.34.0-0.2.el8 baseos 149 k NetworkManager-tui x86_64 1:1.34.0-0.2.el8 baseos 341 k NetworkManager-wifi x86_64 1:1.34.0-0.2.el8 baseos 191 k NetworkManager-wwan x86_64 1:1.34.0-0.2.el8 baseos 177 k anaconda-core x86_64 33.16.6.1-1.el8 appstream 2.4 M anaconda-gui x86_64 33.16.6.1-1.el8 appstream 572 k anaconda-tui x86_64 33.16.6.1-1.el8 appstream 287 k anaconda-widgets x86_64 33.16.6.1-1.el8 appstream 222 k annobin x86_64 10.06-1.el8 appstream 126 k bash x86_64 4.4.20-3.el8 baseos 1.5 M cpio x86_64 2.12-11.el8 baseos 266 k dracut x86_64 049-191.git20210920.el8 baseos 374 k dracut-config-rescue x86_64 049-191.git20210920.el8 baseos 61 k dracut-network x86_64 049-191.git20210920.el8 baseos 108 k dracut-squash x86_64 049-191.git20210920.el8 baseos 61 k evolution-data-server x86_64 3.28.5-18.el8 appstream 2.1 M evolution-data-server-langpacks noarch 3.28.5-18.el8 appstream 1.4 M firefox x86_64 91.2.0-1.el8_4 appstream 107 M gupnp x86_64 1.0.6-2.el8_4 appstream 106 k java-1.8.0-openjdk x86_64 1:1.8.0.312.b02-0.1.ea.el8 appstream 341 k java-1.8.0-openjdk-headless x86_64 1:1.8.0.312.b02-0.1.ea.el8 appstream 34 M kpatch noarch 0.9.4-1.el8 baseos 17 k kpatch-dnf noarch 0.4-1.el8 baseos 18 k libqmi x86_64 1.30.2-1.el8 baseos 949 k libqmi-utils x86_64 1.30.2-1.el8 baseos 225 k open-vm-tools x86_64 11.3.0-1.el8 appstream 861 k open-vm-tools-desktop x86_64 11.3.0-1.el8 appstream 201 k policycoreutils x86_64 2.9-16.el8 baseos 373 k policycoreutils-dbus noarch 2.9-16.el8 baseos 188 k policycoreutils-devel x86_64 2.9-16.el8 baseos 292 k policycoreutils-gui noarch 2.9-16.el8 appstream 465 k policycoreutils-python-utils noarch 2.9-16.el8 baseos 252 k python3-policycoreutils noarch 2.9-16.el8 baseos 2.2 M rsync x86_64 3.1.3-13.el8 baseos 405 k setroubleshoot x86_64 3.3.24-4.el8 appstream 135 k setroubleshoot-plugins noarch 3.3.14-1.el8 appstream 358 k setroubleshoot-server x86_64 3.3.24-4.el8 appstream 388 k systemd x86_64 239-51.el8 baseos 3.6 M systemd-container x86_64 239-51.el8 baseos 751 k systemd-libs x86_64 239-51.el8 baseos 1.1 M systemd-pam x86_64 239-51.el8 baseos 476 k systemd-udev x86_64 239-51.el8 baseos 1.6 M tzdata noarch 2021b-1.el8 baseos 473 k tzdata-java noarch 2021b-1.el8 appstream 190 k webkit2gtk3 x86_64 2.32.4-1.el8 appstream 17 M webkit2gtk3-jsc x86_64 2.32.4-1.el8 appstream 6.3 M I have this problem on 2 VirtualBox VMs and 1 QEMU/KVM VM. I was able to confirm Xfce logins on the QUEMU/KVM VM were working before the above list of updates was applied.
Just to be clear - There was no issues prior to this batch of updates, correct?
Yes correct. To me nothing in the update set seemed like it could do such a thing, hence I posted it. This happened 3 times, the first two happened before I realized the damage. On the third VM I confirmed I could login *before* I ran updates, and that I couldn't *after*. I have another VM at another location which may not yet have the problem. I'll check it later today and report back. It may be useful to help diagnose the problem if you tell me which files to 'capture' before and after the event.
Unfortunately the two VMs at the second location already exhibit the problem.
I think I have a better understanding of the problem. On CentOS Stream 8 with all updates applied, gdm won't allow you to login to Xfce after a fresh boot. However if you login to GNOME and log out, from gdm you can select Xfce and login OK (but you must have first logged into GNOME). You can login and logout to Xfce as often as you like until you reboot. At that point you have to login to GNOME again, at least once after the reboot, before Xfce logins will work. This is why I was misled in my original report (sorry about that), I must have logged into GNOME first (the system already had the problem but was masked by me logging into GNOME first). I believe (based on playing with an old backed up VM that doesn't yet have this problem) that gdm updating has caused this. STEPS ===== 1. I cloned the old working VM and upgraded *only* gdm in the clone from gdm-40.0-12.el8.x86_64 to gdm-40.0-16.el8.x86_64. 2. I rebooted. 3. At gdm I tried to login to Xfce, I was bounced back to gdm. 4. Logged into and out of GNOME OK. 5. Was able to login to Xfce. 6. I rebooted. 7. Sequence repeats from step 3 I then updated this clone VM to the latest package set (so making it the same as all my other VMs) but the problem persists.
More testing... Looks like there was a version of gdm between the versions I was using. Downgrading the test VM in Comment #4 to gdm-40.0-13.el8.x86_64 doesn't fix the problem. Downgrading to gdm-40.0-12.el8.x86_64 does fix the problem.
This is excellent troubleshooting. Thank you. It sounds like there is some housekeeping that GDM needs to do or Xfce is expecting something from the login manager. When you have 40.0-13 installed, what does journalctl say about the login failure? I can start VMs to try tonight but I do not have one ready at the moment.
Created attachment 1834188 [details] journalctl log of event
Updated gdm to 40.0-13. I logged in at exactly 21:54. The log shows everything that happened up to the point where I logged into GNOME to capture the log from journalctl which was at 21:55 (the GNOME login is not in the log file).
The sequence in Comment #4 is correct as it is stated, but there is yet another weird dimension to this. It seems if the last session was GNOME, you can login to Xfce after a reboot. At least sometimes. If the last session was Xfce you must login to GNOME first.
Sorry for the delay. This is taking me a while since I have been busy with other things outside of fedora/epel.
So the log shows a concerning thing: > Oct 18 21:54:03 adric /usr/libexec/gdm-wayland-session[2302]: /usr/bin/startxfce4: Starting X server it's trying to run xfce as a wayland session. Given xfce doesnt have a wayland mode as far as I know, GDM must be screwing up. It's probably bug 2009045. Can you try the test builds here http://people.redhat.com/rstrode/2009045/ and confirm they fix your issue? If so, I think we can just close this as a duplicate of 2009045
I DLed the test build, in approx 10 hours I will be at the location to test.
This didn't quite go as I expected. I commented out my block to gdm updates in my dnf.conf file, then did general updates, and in the wave of downloads got gdm-40.0-23.el8.x86_64 which is the same version ID as your scratch build (don't know if the content is the same). Test results: gdm-40.0-23.el8.x86_64 from the repo did NOT have the problem. I then got the previous one from the repo (gdm-40.0-22.el8.x86_64) and found it also did NOT have the problem. Then for the sake of my sanity, I went back to gdm-40.0-13.el8.x86_64 (a version I knew had the issue) to re-observe the problem, and indeed on the very first boot I observed the problem of this bug report. I then installed one by one each and every version from -13 to see where the problem went away, and it was with -22. So gdm-40.0-22.el8.x86_64 fixes the problem of this bug report.
odd, i would have expected -21.el8 to work as well. Anyway, thanks for the confirmation the problem is resolved *** This bug has been marked as a duplicate of bug 2009045 ***
I just checked my paperwork from late last night.... looks like I missed 21. I did 13, 16, 17, 20, 22 & 23. Must have missed DLing it from my browser.