No login screen after upgrade to f43 (Solved: authselect was never set up on a system upgraded through many versions)

I solved this myself but wanted to document the solution in case other users might have the same issues. All hints and feedback on how to best achieve this goal are appreciated.

Issue

The upgrade itself ran smooth but after boot there is just a blinking cursor, no login screen.

Debugging steps (feel free to skip)

  1. Switch to a text console (Ctrl+Alt+F3), login as prompted.
  2. Check for failed services systemctl --failed
    1. Some user@[somenumber].service entries were listed
    2. systemctl status user@[somenumber].service can give first hints, but I decided to check the full journal at this point.
  3. journalctl -b gives you the logs from the current boot. (I’m currently reconstructing this using journalctl -b -1, very convenient, thanks journalctl! :slight_smile:)
  4. Quickly scroll through using the pagedown key, red stack traces appear near the end, starting with a systemd-coredump[1612]: [šŸ”•] Process 1596 (gnome-session-i) of user 60578 dumped core. That doesn’t look good!
  5. Scrolling up a bit there are some useful hints:
    systemd\[1\]: Starting user@60578.service - User Manager for UID 60578…
    dbus-broker-launch\[1109\]: Activation request for ā€˜org.freedesktop.home1’ failed: The systemd unit ā€˜dbus-org.freedesktop.home1.service’ could not be found.
    unix_chkpwd\[1572\]: could not obtain user info (gdm-greeter)
    unix_chkpwd\[1574\]: could not obtain user info (gdm-greeter)
    (systemd)\[1557\]: user@60578.service: PAM failed: Authentication service cannot retrieve authentication info
    (systemd)\[1557\]: user@60578.service: Failed to set up PAM session: Operation not permitted
    (systemd)\[1557\]: user@60578.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
    systemd\[1\]: user@60578.service: Main process exited, code=exited, status=224/PAM
    systemd\[1\]: user@60578.service: Failed with result ā€˜exit-code’.
    systemd\[1\]: Failed to start user@60578.service - User Manager for UID 60578.
    
  6. Out of sheer luck I had a totally different issue last year where someone hinted, that authselect may never have been set up correctly on my system. Had a hunch that this might have become a bigger issue now.

Solution

  1. Switch to a text console (Ctrl+Alt+F3), login as prompted.
  2. Check your current status of authselect:
    authselect current
    If it says No existing configuration detected. then this issue is for you!
    If it starts with Profile ID: then the following is unlikely to help you, sorry :pensive_face:
  3. Setup with the default authselect configuration or read more about authselect in the documentation or the two great magazine articles I’ll link below.
    sudo authselect select local with-silent-lastlog with-mdns4 --force
  4. Reboot systemctl reboot The login screen should be back now :slight_smile:

More Info on Authselect

July 2024: Authselect in Fedora Linux 40: Migrating to the new ā€œlocalā€ profile - Fedora Magazine

May 2025: How to use Authselect to configure PAM in Fedora Linux - Fedora Magazine

6 Likes

Thank you so much for this! After about 6 hours of googling I got Fedora 43 graphical login working. This is emblematic of new user frustration with Linux. I’ve been using Linux for about 28 years and without this posting I’d still have a broken Linux update. Perhaps I could have solved this sooner after poring over logs but I doubt it. This really just shouldn’t happen in this day and age, but unfortunately I don’t have any suggestions for preventing it.

2 Likes

I upgraded from F42 to F43 on a number of computers, and one of them failed to start GDM login as described here.

I have been searching Google and AI for several days, without luck.

Applying this fix, it started working. :slight_smile:
Thank you!!!

2 Likes

Thank you so much for this! This was the problem with my laptop, so I have marked my own thread as solved and posted a link here. Thank you; I had tried so many things and nothing had worked.

2 Likes

Yeah, I got caught by this, too.

It would have been so bad if authselect wasn’t so confusing. There are warnings everywhere not to edit files, but there isn’t any documentation about how to configure modules that are not pre-defined ā€œfeaturesā€. My system is up, again, with a custom profile; that was easy. But, now I’m stuck.

For special needs, you can create your own profile using authselect create-profile. Run man authselect to see the man page and search for ā€œcreate-profileā€.

For example

sudo authselect create-profile myprofile -b local

Then edit the files in /etc/authselect/custom/myprofile and the use authselect select custom/myprofile to enable it.

1 Like

I’m surprised you wouldn’t have just reinstalled.

I have less experience (Ubuntu 6.06), but seen update issues back then, had some with Windows before that, and by the time Vista SP1 came out I knew not to bother with major OS version upgrading: I can back up and set-up a new install sooner than I can track-down random issues :stuck_out_tongue:

Thanks. That’s where I was headed, but it doesn’t say those files are editable anywhere in the documentation, while everywhere else it just says DO NOT EDIT.

Can you define your own ā€œfeaturesā€ somehow?

Hello everyone,

I’m glad that this already helped a hand full of users who commented here (and probably a few more who didn’t), seems like my time writing it was well spent :slight_smile:

While there are surely interesting use cases for custom authselect features, I’d ask you, @prdamon, to create a separate discussion for that. It might be beneficial for interested parties of both sides to not have this special topic mixed with the ā€œargh, can’t login after I upgraded!?ā€ folks for whom I specifically created this thread. Links back and forth are always appreciated of course :heart:

One thing that could be discussed here, however is this thought in the back of my mind: Could we as the Fedora community have done something to prevent people running into this issue? Is there something we still can do? Would it be worth the effort and what would be the first steps?

1 Like

If you create your own profile, you can modify it to exactly the way you want. Or you could opt-out of using authprofile, and edit the files in /etc/pam.d. However, if you do so, you also need to make manual updates when and if needed.

I was thinking while I was having the problem, ā€œI am definitely going to download those ā€œlarge filesā€ and let my laptop report bugs to Fedora in future, because they definitely don’t have anyone else with this sort of laptop to report problems.ā€ I had the issue a couple of months ago where kernel 6.16 kept disconnecting my WiFi as well, so there have now been two disasters in rapid succession. In the eight years I’ve used Fedora before that, the worst thing that ever happened was when an update deleted my desktop wallpaper. I’m not going to be any use at actually contributing, so we’ll still need experts like you, but I think getting more people’s systems to test the updates on will help provide more feedback before these updates go public. If everyone who uses Fedora gets more involved in the community, it might not even matter that users like me don’t know anything about maintaining an operating system :rofl: