Created attachment 1292993 [details] Excerpt from /var/log/messages covering an attempt to GDM login. Description of problem: Logging in via GDM, prompted for passwrd, then login screen reappears. Version-Release number of selected component (if applicable): seahorse-3.20.0-4.fc26.x86_64 How reproducible: Always, on one machine. On another machine, the update to FC26 beta worked fine. Steps to Reproduce: 1. Upgrade to FC26 beta 2. Log in via GDM 3. Actual results: Login fails after password prompt Expected results: Login succeeds. Additional info: Command-line or ssh logins succeed. I'm not sure if seahorse is in fact the right component, but the logs show that seahorse is terminating with a sig11, so I decided to start here. The log excerpt is attached.
Moving keyring files to .local/share/keyrings doesn't help. Deleting the keyring files login.keyring and user.keystore doesn't help.
seahorse isn't really the problem here. The logs show dozens of components crashing, and seahorse isn't actually the one that takes the session down either time.
(In reply to Adam Williamson from comment #2) > seahorse isn't really the problem here. The logs show dozens of components > crashing, and seahorse isn't actually the one that takes the session down > either time. Agreed, there are various required components that fail to (re)start. Now the reason *may* be that gnome-shell is failing without a trace (at least in the logs), but it's impossible to tell without further information. For now, let's reassign to gnome-settings-daemon, which is what shows up in the logs ...
Not enough info, please edit /etc/gdm/custom.conf and enable debug output then attach a full system log of a failed login attempt.
I thought it would be useful to see if a virgin userid exhibited the same problem, so I created one using system-config-users. Not only does that userid work fine (modulo a separate issue with the graphical display) but now so does my own userid. So unfortunately, the problem appears to no longer be reproducible. Maybe the fact that userid creation is correlated with the cure will provide some insight, but unfortunately, at this point, I can't add information on this issue. Will reopen or refile if I hit the issue again.
Created attachment 1299922 [details] Excerpt from /var/log/messages with GDM debug enabled.
I just upgraded another machine and encountered the same issue. I am attaching an excerpt of /var/log/messages with GDM debug enabled. I can also report that removing saved sessions in ~/.config/gnome-session/saved-session seems to have cleared the problem, so this may be related to Bug #775463.
(In reply to Matthew Saltzman from comment #6) > Created attachment 1299922 [details] > Excerpt from /var/log/messages with GDM debug enabled. This was either captured without gdm debug enabled or it's not a full log. You need to reboot or at least restart gdm.service after editing /etc/gdm/custom.conf to ensure the former and capture all the output of "sudo journalctl -b" for the latter.
(In reply to Rui Matos from comment #8) > (In reply to Matthew Saltzman from comment #6) > > Created attachment 1299922 [details] > > Excerpt from /var/log/messages with GDM debug enabled. > > This was either captured without gdm debug enabled or it's not a full log. > > You need to reboot or at least restart gdm.service after editing > /etc/gdm/custom.conf to ensure the former and capture all the output of > "sudo journalctl -b" for the latter. Ah, sorry, didn't have the instructions for getting the full log. Will see if I can get another example.
OK I am out of machines to upgrade and haven't hit the failure again. Is there a way to create an artificial .config/gnome-session/saved-session file that I could try?
See https://bugzilla.gnome.org/show_bug.cgi?id=775463 . Please follow up upstream.