users created in F43 can’t log in via GDM in F44.
The log files of GDM is in the following link
Apr 29 04:52:31 fedora gdm[1694]: Gdm: GdmSession: Emitting 'session-started' signal with pid '4532'
Apr 29 04:52:31 fedora gdm[1694]: Gdm: GdmManager: session started 4532
Apr 29 04:52:31 fedora gdm-wayland-session[4532]: Gdm: Enabling debugging
Apr 29 04:52:31 fedora gdm-wayland-session[4532]: Gdm: Running session message bus
Apr 29 04:52:31 fedora gdm-wayland-session[4532]: Gdm: session message bus already running, not starting another one
Apr 29 04:52:31 fedora gdm-wayland-session[4532]: Gdm: Running wayland session
Apr 29 04:52:31 fedora gdm-wayland-session[4532]: Gdm: gdm-wayland-session: Session will register itself
Apr 29 04:52:31 fedora gdm-wayland-session[4532]: Gdm: session was killed with status 6
Apr 29 04:52:31 fedora audit[4030]: AUDIT1106 pid=4030 uid=0 auid=1000 ses=4 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_keyinit,pam_namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_gnome_keyring,pam_umask acct="josephsaber" exe="/usr/libexec/gdm-session-worker" hostname=fedora addr=? terminal=/dev/tty2 res=success'
Apr 29 04:52:31 fedora audit[4030]: AUDIT1113 pid=4030 uid=0 auid=1000 ses=4 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success'
Apr 29 04:52:31 fedora audit[4030]: AUDIT1104 pid=4030 uid=0 auid=1000 ses=4 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix,pam_gnome_keyring acct="josephsaber" exe="/usr/libexec/gdm-session-worker" hostname=fedora addr=? terminal=/dev/tty2 res=success'
Apr 29 04:52:31 fedora gdm-password][4030]: Gdm: GdmSessionWorker: child (pid:4532) done (status:0)
Apr 29 04:52:31 fedora gdm-password][4030]: Gdm: GdmSessionWorker: uninitializing PAM
Apr 29 04:52:31 fedora gdm-password][4030]: pam_unix(gdm-password:session): session closed for user josephsaber
Apr 29 04:52:31 fedora gdm-password][4030]: Gdm: GdmSessionWorker: state NONE
Apr 29 04:52:31 fedora gdm[1694]: Gdm: GdmSession: Emitting 'session-exited' signal with exit code '0'
It looks like things are going normally until it suddenly reports session was killed with status 6 and logs you back out.
Should I post the full logs of the boot session generated by journalctl ?
Hi! I’ve got the same problem. Could you troubleshoot it? Is it tracked anywhere else?
It looks like you authenticated successfully. I ‘m not sure what’s going on there with gdm, but I wonder if maybe your upgrade isn’t quite done yet. If you grab a TTY (ctrl+alt+f[3-6]) and tell dnf to upgrade, does it actually try to fetch updates or does it cry about an incomplete transaction? If it does try to upgrade, do things get better after a reboot?
This link includes the full logs generated by journalctl
I hope it will help.
I’ve upgraded through gnome store GUI package manager,
I can update through GUI Package manager and dnf
$ sudo dnf upgrade
[sudo] password for Mohammed:
Updating and loading repositories:
Repositories loaded.
Nothing to do.
I can log in to the affected F43 user via TTY3 session, but not through graphical desktop manager GNOME session.
Ok, so back over in your reddit thread, someone was doing some post necromancy about issues folks had back in F41. One of the two posts actually looked a lot like your problem, and they ultimately resolved their issue.
The user backed up ~/.config and then deleted the contents of the original, effectively resetting a lot of their user settings. Neither user specified what content in .config was actually causing the issue, but cleaning it out got them logged in. (Be careful when doing this, and please please don’t skip the backup!)
That’s not surprising. GNOME tries to start a lot of programs when the user signs in . When you sign in on the console, almost nothing beyond the Bash shell is started unless you’ve explicitly added things in Bash’s startup scripts.
I’m not sure if I could find it again, but one of the reports I saw when I was skimming similar reports indicated that if some process or flatpak spawned in your session when you sign in on GNOME kills its process group (because that app failed somehow and couldn’t shutdown cleanly), then it can end up killing the whole gnome-shell as well.
Can you work around the issue by using a sudo useradd ... command in a VT to create another account? You’ll also need to use sudo passwd <username> to set a password for the account after you create it.
The user backed up ~/.config and then deleted the contents of the original
It worked thank you very much.
however dark mode now is broken somehow, but I may dedicate another thread regarding that, but it’s only broken for that user.
I’m not sure if I could find it again, but one of the reports I saw when I was skimming similar reports indicated that if some process or flatpak spawned in your session when you sign in on GNOME kills its process group (because that app failed somehow and couldn’t shutdown cleanly), then it can end up killing the whole gnome-shell as well.
@glb
that explains how deleting everything in .config folder fixed the login issues for me.
I’m not sure that a crashing startup application is taking out gnome-shell as well, but for what it is worth, I found the comments that I was referring to and I’ll repost them here:
Excerpted from The GNOME Shell session is killed when a Flatpak running in the background is closed.:
…
@josephsaber40 do you use Cloudflare’s warp-cli client? Someone has reported that that startup app can cause gnome-shell to crash when signing in:
It worked out for me as well. It ended up being the .config/systemd folder in my system iirc. However, many settings were changed after the update. So far, a very not smooth update experience…
~/.config contains a lot of configuration for many things, so if you move it, you lose a lot of configuration. Generally moving the entire directory to see if it fixes the problem is a first step. If it does fix the problem, you know something in there is causing the problem, and you can try moving the whole directory back but then moving/renaming individual things inside it until you find the one that’s causing the problem. Then you can just remove/fix that thing, and not lose all the other configuration.
There have been a few reports of the login crashes happening due to startup applications under ~/.config/systemd/user, so that is probably a good place to start.
do you use Cloudflare’s warp-cli client? Someone has reported that that startup app can cause gnome-shell to crash when signing in:
I was and yes this file warp-desktop-svc.service by restoring this file to its original place I was able to reproduce the issue.
You might try restoring the whole .config folder minus that service file and see if everything is “normal” for you.
You might try restoring the whole .config folder minus that service file and see if everything is “normal” for you.
I did that but some UI elements aren’t rendering dark mode theme correctly for that particular user.
[Unit]
Description=Cloudflare Zero Trust Client Service
Requires=dbus.socket
After=dbus.socket
# BindsTo=graphical-session.target
# Change BindsTo to PartOf
PartOf=graphical-session.target
[Service]
Type=simple
ExecStart=/usr/bin/warp-desktop-svc
Restart=always
[Install]
#WantedBy=default.target
WantedBy=graphical-session.target
Fixed with AI version of warp service. Works fine
This worked for me to log in to Gnome but many things are still missing like shortcut config. If you have a dotfiles repo it might be good to just restore back up the configs dir and then restore the config using the dotfiles.