Description of problem:
This has happened in both RHEL 7.6 as well as Fedora 31. Started happening with Cinnamon Desktop (4.4), but also tested with Gnome3 (3.34) and MATE (1.22). Starting any of these desktop environments from the DM (RHEL 7.6) or LightDM display managers will start loading he desktop environment, then drop back to the display manager/login screen.
Logging in as OpenBox (on RHEL 7.6) LXQt (0.14) or KDE Plasma (5.17) will load those desktops/shells with no problem.
Have installed Fedora 31 on the system that used to have RHEL 7.6, so that particular test environment is not available anymore.
Also, to verify this isn't an issue with my particular hardware, I copied the home directory from the primary machine (Lenovo ThinkPad P50) to another machine (Lenovo ThinkPad T430). Previously this method of copying the home directory had worked (testing a mogration from RHEL to Fedora), so it should be a comparable environment.
As this happens in three desktops, I will be pasting this note to those reports as well.
Version-Release number of selected component:
runlevel: N 5
Thread no. 0 (1 frames)
#0 match at pcre_exec.c:522
Created attachment 1669276 [details]
Created attachment 1669277 [details]
Created attachment 1669278 [details]
Created attachment 1669279 [details]
Created attachment 1669280 [details]
Created attachment 1669281 [details]
Created attachment 1669282 [details]
Created attachment 1669283 [details]
Created attachment 1669284 [details]
Created attachment 1669285 [details]
Created attachment 1669286 [details]
epel7 use MATE 1.16 (gtk2) and not 1.22.
If you run 1.22 from an unofficial copr repo for rhel7 you should file out a report there.
It has a reason that i never updated stable 1.16 (gtk2) to a gtk3 version for rhel7.
Please use only official version from epel7 repos.
Btw. i never run into this crash with mate-1.22/24 in f30/31/32.
Sorry, I wasn't clear on that. The versions I reported were for the Fedora 31 install. I didn't have Mate or KDE installed on the RHEL 7.6 environment, but the login failure occurs on two different machines with Fedora 3.1 (same profile). The profile was only ever copied one direction (P50 to T430) so it wouldn't be a matter of the T430 env contaminating the P50 (and doing this had worked before).
Also, as mentioned above, similar behavior was seen in https://bugzilla.redhat.com/show_bug.cgi?id=1812503 and https://bugzilla.redhat.com/show_bug.cgi?id=1794684, where the common factor is that they are all GTK-based environments. Whether that is relevant I couldn't say.
> Starting any of these desktop environments from the DM (RHEL 7.6) or LightDM display managers will start loading he desktop environment, then drop back to the display manager/login screen.
Which DM (desktop-manger) you mean with `DM (RHEL 7.6)` , GDM ?
Which frontend for lightdm (backend) are you using? lightdm-gtk or slick-greeter ?
The default for MATE in fedora is using lightdm with slick-greeter.
And very important question. Does it happen with a new fresh account?
"GDM" was the display manager on RHEL 7.6. (that system, Lenovo ThinkPad P50, has been reloaded with Fedora 31)
debug data above was gathered from the P50
On both Fedora 31 systems (one being the P50 above, plus another ThinkPad, a T430) the only file in /usr/share/xgreeters/ is slick-greeter.desktop, so thatt would presumably be what it's running, as the commented-out line in /etc/lightdm/lightdm.conf for greeter-session has "#greeter-session=example-gtk-gnome" (and I didn't' set anything manually)
also, a fresh account has no problem logging in
(In reply to James E. LaBarre from comment #17)
> "GDM" was the display manager on RHEL 7.6. (that system, Lenovo ThinkPad
> P50, has been reloaded with Fedora 31)
> debug data above was gathered from the P50
> On both Fedora 31 systems (one being the P50 above, plus another ThinkPad, a
> T430) the only file in /usr/share/xgreeters/ is slick-greeter.desktop, so
> thatt would presumably be what it's running, as the commented-out line in
> /etc/lightdm/lightdm.conf for greeter-session has
> "#greeter-session=example-gtk-gnome" (and I didn't' set anything manually)
good, this confirmed that you're running stick-greeter.
(In reply to James E. LaBarre from comment #18)
> also, a fresh account has no problem logging in
But with your default account it failed to login?
Sounds there is something in you config of the default account which prevent you from login, or not?
Not sure how i can help you more to find the culprit?
> good, this confirmed that you're running stick-greeter.
error, good, this confirmed that you're running slick-greeter.
wtf, that bugzilla don't allow editing comments in the 20th.
Are you using a VM and maybe qemu-kvm?
If yes, which graphic driver are you using?
During testing Fedora-MATE_Compiz-Live-x86_64-32_Beta-1.2.iso live-image i noticed a problem with virtio graphic driver, i had to switch to QXL driver for login to session.
So I went through the steps I had done to migrate my profile to a fresh install, and came across the setting for customizing the colors for the "ls" command (which had been in my old .bashrc file but not the default one created by the install. Removed this and the login failure went away.
Hadn't changed any of it's default settings yet, so it would be whatever values the sample file has. Can't understand why a settings file for LS would mess up a login, unless it's because the variable would be large.
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 31 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.