I’ve rebased to Fedora Silverblue 43 for testing and starting gdm seems to crash due to gdm-launch-environment trying to load pam_lastlog.so, which must have been gone because of https://fedoraproject.org/wiki/Changes/Migrate_to_lastlog2 Authselect must be reapplied to regenerate the config with the new library. The cause of this is that "Authselect currently applies new profile only inside the rpm scriptlet, which does not work on Silverblue or other ostree systems." Reproducible: Always
Created attachment 2106842 [details] Journalctl boot logs exerpt
Proposed as a Blocker for 43-final by Fedora user tcit using the blocker tracking app because: Makes gdm crash at startup due to authselect not regenerating profile after pam_lastlog2 change.
hi, is there other workaround? I'm already on F43 workstation (non-silverblue) and editing /etc/pam.d/postlogin-ac does not help - gdm doesn't show a gui.
Install the pam-lastlog2 package if it isn't already installed. Then do this: sudo systemctl enable lastlog2-import sudo systemctl start lastlog2-import That might get things working, but if not try this: sudo authselect enable-feature with-silent-lastlog Apart from that I'm not sure if further things are needed. I did get Fedora Workstation booting to a gdm graphical screen, but there may have been other things I did that I forget the details of.
Filed https://bugzilla.redhat.com/show_bug.cgi?id=2397255 for enabling the new service by default. There is also upstream pull request: https://github.com/authselect/authselect/pull/421
(In reply to Kazimieras Vaina from comment #3) > hi, is there other workaround? > I'm already on F43 workstation (non-silverblue) and editing > /etc/pam.d/postlogin-ac does not help - gdm doesn't show a gui. If you're still on an old non-authselect configuration, I recommend to run "authselect select local --force", this will create backup of your current configuration and switch to authselect. After that, you can tweak the configuration with authselect to your needs.
The "authselect select local --force" did the trick - Thank you! I probably I was editing wrong files. Can I get rid of files in /etc/pam.d that are not linked to /etc/authselect ?
AGREED RejectedFinalBlocker Discussed at the 2025-09-22 (blocker / freeze exception) review meeting: So far we think it's pretty clear this doesn't meet the criteria ("For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed.") We're not sure the issue is restricted to Silverblue, but openQA testing at least indicates it's not affecting a clean F41 -> F43 upgrade https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-22/f43-blocker-review.2025-09-22-16.01.txt
The issue is restricted to ostree systems where rpm scriptlet that runs that updates the configuration does not run. I have fix ready, just waiting for systemd preset to be created. Indeed, even on Silverblue, default configuration will be updated via a 3way merge. But changing authentication mechanisms via authselect should be supported as well, so I think it should be a blocker.
I had this problem with Fedora Workstation, it took quite a lot of searching and reading to understand what the problem was. I had updated Fedora on the machine in question (built in 2007) over many releases but had not switched to authselect as I don't recall any prompting to do that. While I agree this isn't a blocker I think something added to wherever Common Bugs lives these days would be a good idea.
Fedora Workstation is affected only if you have non-authselect configuration. You should have been switched to authselect configuration automatically in F36, not sure why it did not worked for you.
Yes, I know it was supposed to have happened at some point but it seems not to have done so and I ended up having to manually fix it up. There have been a few instances of instability during Fedora history, I expect it was something of that nature.
FEDORA-2025-617342aa98 (authselect-1.6.2-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-617342aa98
Fix is in bodhi, but it requires https://bugzilla.redhat.com/show_bug.cgi?id=2397255 to work.
FEDORA-2025-617342aa98 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-617342aa98` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-617342aa98 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-617342aa98 (authselect-1.6.2-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Issue still persists with authselect-1.6.2-1.fc43. As described in [1]: > For me this did not work at first, since authselect complained that I have no configuration. > So I had to call authselect select local --force first. After that I could run sudo authselect apply-changes. And with that it finally worked. > > My assumption to why i had no profile is, that I only upgraded my system, but did not had a fresh install since at least 2018. [1] https://discussion.fedoraproject.org/t/pam-lastlog-change-crashing-gdm/164467/12 This is also the case for me: 1. when I tried to run `authselect apply-changes`, it failed, complaining that I have no configuration. 2. `authselect select local --force` fixed the issue for me. 3. My system is also very old (from 2015 I think) This is the old /etc/authselect/postlogin file: ``` #%PAM-1.0 session optional pam_umask.so silent session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailed ``` And this is the new one after following the steps before: ``` # Generated by authselect # Do not modify this file manually, use authselect instead. Any user changes will be overwritten. # You can stop authselect from managing your configuration by calling 'authselect opt-out'. # See authselect(8) for more details. session optional pam_umask.so silent session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog2.so session optional pam_lastlog2.so silent ```
> Issue still persists with authselect-1.6.2-1.fc43. I've just bumped into that with an upgrade from F41 to F43 - gdm crashing in the loop. No way to use text console (unless "3" used in Grub to target "multi-user"). It helped: > This is also the case for me: > 1. when I tried to run `authselect apply-changes`, it failed, complaining that I have no configuration. > 2. `authselect select local --force` fixed the issue for me. > 3. My system is also very old (from 2015 I think) My initial Fedora version on this computer might be even older.
*** Bug 2395013 has been marked as a duplicate of this bug. ***
Documented as common issue: https://discussion.fedoraproject.org/t/171961
Closing as won't fix as this is really not an authselect problem and it was resolved by documenting it as an common issue: https://discussion.fedoraproject.org/t/171961 Using authselect will prevent this kind of issues in the future.
*** Bug 2412249 has been marked as a duplicate of this bug. ***