I want to flag a gap that’s likely costing Fedora new users, not just an inconvenience for people who already know their way around the project.
This bug (and the login-after-install failures reported around it) means a fresh install from the official Fedora-Workstation-Live-44-1.7 ISO on getfedora.org can leave a brand new user completely locked out of their own system — not able to log in from the GUI, from a TTY, or anywhere. For someone trying Fedora for the first time, there’s no way to know this is a known, tracked issue. They just assume the install failed, try again a few times, and give up on the distro entirely.
The fix (a Respins SIG image with the corrected anaconda) exists and works, but it’s only available on Making sure you're not a bot! — a page most new users have never heard of, let alone would think to check. The main download page gives no indication that the release ISO has a known, severe login-blocking bug, or that an updated image is available.
Given the severity here (urgent, unable to log in at all, affecting multiple independent users/machines), could the getfedora.org download page at least carry a temporary banner pointing to the respin while this is being resolved? Even a single line — “Known issue: users created during install may not be able to log in — download the updated respin here” — would save a lot of people from bouncing off Fedora for a bug that’s already fixed elsewhere.
Happy to provide more reports/details if useful — this affected installs on multiple different machines for me.
Red Hat Bugzilla #2477902 – ‘Cannot log in after fresh installation of Fedora Jam KDE 44.’ The root cause is that Anaconda leaves the password hash unset (!) in /etc/shadow during install, so the account is locked even though setup appears to complete normally.
Since it looks like you are trying to notify the Workstation team about a problem, I’ve moved this from the user support side of the forum to the team discussion category.
Yes — my own experience was specifically with Fedora Workstation (GNOME), not Jam. I installed from the official Fedora-Workstation-Live-44-1.7 ISO on multiple machines and hit the same lockout. I referenced Bug 2477902 because the root cause described there (password hash left unset in /etc/shadow) matched what I found independently on Workstation — but you’re right that the bug report itself is filed against Jam. If it’d help, I can open a separate report specifically for Workstation, or is there an existing one I should link instead?
I’m not entirely following this. You can’t create users during install on the Workstation live, by design. You create users during first boot, in a thing called gnome-initial-setup (the GNOME-looking wizard that asks for your location and a few other things before letting you create a user).
The KDE edition, and KDE-based spins, use a similar but entirely separate wizard called plasma-setup. Again, there is no ability to create users during install (on the KDE live at least, and I’m pretty sure the Jam spin would be the same). So a “corrected anaconda” can’t have anything to do with it.
We have extensive automated testing of the Workstation and KDE editions that includes doing a standard install and creating a user and logging in as that user. Those work. If they failed we would not have released F44.
It’s possible there is/are one or more specific issues perhaps to do with particular usernames or passwords. They could even be the same issue I guess if they’re in shadow-utils (which both g-i-s and p-s ultimately use). But there’s not enough information in either this post or the linked bug report to be sure they’re the same issue, or what the issue actually is, or whether respun ISOs are any less likely to hit it.
You’re right, and I appreciate you pointing that out — I hadn’t actually realized until your reply that Anaconda doesn’t handle user creation on Workstation live, and that I’d linked a bug report for a different spin (Jam) without checking that carefully enough. That was a mistake on my part, not something I already knew.
To be precise about my own case now: this was Fedora Workstation (GNOME), installed from the official Fedora-Workstation-Live-44-1.7 ISO, on more than one machine. I did not use disk encryption (no LUKS). The password was lowercase letters and numbers only, no special or non-ASCII characters, and typeable on a standard US keyboard. The install itself completed normally, and I set the username/password at gnome-initial-setup on first boot — that screen accepted it and let setup finish. But at the login screen right after, the same password was rejected.
I don’t have logs from those specific installs anymore, and I’m not very experienced with pulling diagnostic logs myself — if it would help, I’m willing to try reproducing it on a spare machine, but I’d need some guidance on exactly what to run/collect.
Let me know what would help narrow it down, and whether there’s a simple set of steps I could follow to capture useful logs if I reproduce it.
So it looks like accounts-daemon generates a password hash that chpasswd then rejects as invalid, and gnome-initial-setup’s SetPassword call fails silently from the user’s point of view — setup completes, but the password was never actually set. This lines up with what pg-tips suspected about a shared component, though the failure point here seems to be accounts-daemon/chpasswd rather than shadow-utils directly."
That was in the context of KDE Plasma, and I think there are two separate issues there:
accounts-daemon / chpassword rejects the password (for unclear reason)
The KDE Plasma account setup screen ignores that failure, rather than notifying the user and requiring them to try again.
It could be that gnome-initial-setup has/had a separate but equivalent bug to (2) and also was ignoring the failure.
If issue (1) has been fixed since Fedora 44 release then that would explain why there’s no longer a user-facing problem when installing from the respin ISOs.
Following up — found what might be the root cause. There’s a Debian bug (#1124835) about shadow-utils’ chpasswd rejecting valid password hashes, caused by an overly strict check added upstream in July 2025. Debian fixed it same-day on 7 Jan 2026 in shadow 1:4.19.0-4.
Checking Fedora’s package, F44 currently ships shadow-utils-4.18.0-7.fc44 — so it’s on the 4.18.x branch, not 4.19.x, which makes me unsure whether the fix (or the original bad commit) was ever backported either way. Might be worth someone checking whether F44’s 4.18.0-7 build includes the c44f1e0 commit that caused this, since my logs show the same ‘invalid password hash’ / ‘error detected, changes ignored’ messages verbatim
One more detail from the full boot log — gnome-initial-setup did generate a PAM error message internally (‘Üzgünüm, parola kimlik doğrulaması işe yaramadı…’ / password auth failed) right after the chpasswd failure, but I can say with certainty I never saw any error on screen during setup — it went straight through to a normal-looking completion. So it looks like the failure is logged internally by gnome-initial-setup but never actually surfaced to the user in the UI, same pattern pg-tips described for KDE.
Update: tested the F44-WORK respin (20260731) in a VM tonight, same install flow — set password at gnome-initial-setup, got locked out at login just like before. Didn’t pull logs this time since the failure itself was enough to confirm, but happy to if it’d help.
So whatever’s causing this isn’t fixed in the latest respin as of 31 July.
Ah, to clarify — that earlier comment was speculation on my part, before I’d actually tested anything. I assumed the respin included a fix based on timing, but I hadn’t verified it. Tonight’s test was the first time I actually installed from the respin and checked. So it’s not a regression — I just hadn’t confirmed my earlier assumption, and now that I have, it turns out to still be broken.
OK. I’d suggest moving this out of “Project Discussion” into “Ask Fedora”, since what remains relevant is the discussion of the bug, rather than the request to publicise the respins - which wouldn’t help in this situation.
Makes sense, agreed the respin-publicizing angle is moot now. Happy for this thread to move to Ask Fedora and focus on the bug itself.
One thing I’d still flag separately though: regardless of where the fix ends up, this is a silent, complete lockout with zero on-screen warning — I confirmed gnome-initial-setup does generate an internal PAM error but never surfaces it. That seems worth a UX/bug-severity discussion on its own, independent of root cause. Should I open a separate topic for that, or is it better tracked as part of the existing Bugzilla report?
Cool, I’ll move it back. (And indeed I see Ask Fedora is where you originally opened it.)
Actually I would suggest a new Bugzilla ticket for this. The one cited above is in the context of Fedora Jam, and not all the code paths are the same (it uses plasma-initial-setup, whereas it looks like you found a similar but not identical bug in gnome-initial-setup.)