I’m using Fedora as a VM with VirtualBox on a Windows host, and after upgrading from F42 to F44 the system no longer lets me login with the GUI. I’m able to Ctrl+Alt+F3 into a console shell, but so far I haven’t found anything out of place. I tried moving my .config to .config.bak as some suggestions I’d seen but that doesn’t seem to be working. I’ve attached the output from journalctl -b -1 to see if anyone notices anything out of place. Any help is greatly appreciated, as I use this for work and it’s a major blocker currently.
I guess it won’t let me attach the log file, but this is Workstation. This should be a link to the boot log: https://pastebin.com/BcbbUhTV
After doing a little digging, I found that restarting the gdm service allowed me to login, but that only works for the current boot. Once I restart the VM again, it fails to login without restarting the service. I’m wondering if it’s something to do with PAM, as I see this in the service status:
It’s been around a while, at least since F41 I believe. I’d much prefer to keep this machine active if possible, as I don’t know how well migrating SSH keys would work and we don’t have a good system for distributing keys in place at the moment. I’ll dig into that and see if it helps.
Unfortunately it doesn’t look like the authselect profile was the issue, as I still get the hang when trying to login after updating the profile. It does reliably work after restarting the gdm service, so it does appear to be related to that but I’m not sure what specific part is breaking down. journalctl -u gdm doesn’t give me very much to go on, it just “works” after a restart:
I tried removing Guest Additions, but still the same hang when trying to login. Running systemctl restart gdm still works, but I’m not any closer to understanding why that works so far. I can’t seem to find any related processes/services that might be causing it to hang.
Based on some other posts, I tried creating a new account and that one is able to login without issue so it’s pointing more to a profile issue. I’ve already moved the .config, .local, and .cache folders, are there any other folders I can try moving/migrating to see if I can narrow down the issue?
I may have narrowed down the issue finally, it seems that having these lines in my .bashrc file is causing it to crash when trying to login:
#ssh-add -l &>/dev/null
#if [ "$?" == 2 ]; then
# # Could not open a connection to your authentication agent.
#
# # Load stored agent connection info.
# test -r ~/.ssh-agent && \
# eval "$(<~/.ssh-agent)" >/dev/null
#
# ssh-add -l &>/dev/null
# if [ "$?" == 2 ]; then
# # Start agent and store agent connection info.
# (umask 066; ssh-agent > ~/.ssh-agent)
# eval "$(<~/.ssh-agent)" >/dev/null
# fi
#fi
#
## Load identities
#ssh-add -l &>/dev/null
#if [ "$?" == 1 ]; then
# # The agent has no identities.
# # Time to add one.
# ssh-add -t 4h
#fi
I don’t know what specifically is causing the issue, but I guess I can live without auto-loading my ssh keys if that’s what it takes to prevent the login hanging issues. It is odd that they no longer work on F44, as I’d been using this snippet for a long time on F42 without any issues. Tentatively marking this as a solution unless the issue comes back up again.
At least under kde plasma you can load the ssh keys in a script that you start on login to the desktop. The script will have access to the keyring of the desktop to get the unlock password.
