Fedora Account System
Red Hat Associate
Red Hat Customer
During first boot after a fresh Fedora Workstation install, gnome-initial-setup fails to set the user's password, but does not surface any error to the user. The install appears to complete successfully, but the user is then locked out at the login screen with the correct password. Steps to reproduce: 1. Install Fedora 44 Workstation from the official ISO (Fedora-Workstation-Live-44-1.7) or the 20260731 respin 2. Complete gnome-initial-setup, including setting a username and password 3. Reach the login screen and attempt to log in with the password just set Actual results: Login fails. Password was never actually written to /etc/shadow. Expected results: Either the password is set correctly, or gnome-initial-setup shows an error and asks the user to retry rather than completing "successfully." Relevant journalctl output from the affected boot: accounts-daemon[1055]: request by system-bus-name::1.74 [/usr/libexec/gnome-initial-setup pid:2352 uid:60578]: create user 'semih' useradd[3288]: new user: name=semih, UID=1000, GID=1000, home=/home/semih, shell=/bin/bash, from=none useradd[3288]: add 'semih' to group 'wheel' accounts-daemon[1055]: request by system-bus-name::1.74 [/usr/libexec/gnome-initial-setup pid:2352 uid:60578]: set password and hint of user 'semih' (1000) accounts-daemon[3313]: chpasswd: (line 1, user semih) invalid password hash accounts-daemon[3313]: chpasswd: error detected, changes ignored gnome-initial-setup[2352]: SetPassword call failed: GDBus.Error:org.freedesktop.Accounts.Error.Failed: running '/usr/sbin/chpasswd' failed: Sub-process exited with code 1 An automatic login attempt immediately follows and also fails: unix_chkpwd[3321]: password check failed for user (semih) gdm-password][3315]: pam_unix(gdm-password:auth): authentication failure; ... user=semih gnome-initial-setup[2352]: PAM module error: password authentication did not work, please try again I can confirm with certainty that no error was shown on screen during setup — the wizard completed normally from the user's point of view. Additional context: - Reproduced on 6 different physical machines (mixed AMD/Intel CPUs, integrated/discrete GPUs including Nvidia) and in a GNOME Boxes VM - 100% reproduction rate across 5-6 reinstalls on one machine - Also reproduced on the 20260731 Workstation respin, so this is not fixed in the latest available image as of that date - Password used contained only lowercase letters and numbers, no special/non-ASCII characters - No disk encryption (no LUKS) was used in any of the affected installs - A related but not identical issue was reported for Fedora Jam/KDE (plasma-initial-setup) in Bugzilla 2477902 — that report is for a different code path and may not share the same root cause Discussion thread with more background: https://discussion.fedoraproject.org/t/official-fedora-44-workstation-iso-can-lock-users-out-at-first-login-with-no-warning-on-the-download-page-that-a-fixed-respin-exists/198190 Reproducible: Always Steps to Reproduce: 1 Install Fedora 44 Workstation from the official ISO (Fedora-Workstation-Live-44-1.7) or the 20260731 Workstation respin 2. Complete gnome-initial-setup, including setting a username and password 3.Reach the login screen and attempt to log in with the password just set Actual Results: Login fails with the correct password. journalctl shows gnome-initial-setup's SetPassword call failing because chpasswd rejects the password hash generated by accounts-daemon: accounts-daemon[1055]: request by system-bus-name::1.74 [/usr/libexec/gnome-initial-setup pid:2352 uid:60578]: set password and hint of user 'semih' (1000) accounts-daemon[3313]: chpasswd: (line 1, user semih) invalid password hash accounts-daemon[3313]: chpasswd: error detected, changes ignored gnome-initial-setup[2352]: SetPassword call failed: GDBus.Error:org.freedesktop.Accounts.Error.Failed: running '/usr/sbin/chpasswd' failed: Sub-process exited with code 1 No error is shown on screen during setup — the wizard completes normally from the user's point of view, so the user has no indication anything went wrong. An automatic login attempt immediately after also fails: unix_chkpwd[3321]: password check failed for user (semih) gdm-password][3315]: pam_unix(gdm-password:auth): authentication failure; ... user=semih gnome-initial-setup[2352]: PAM module error: password authentication did not work, please try again The password itself was never written to /etc/shadow, so the account is effectively locked with no password set. Expected Results: Either the password should be set correctly, or gnome-initial-setup should detect the SetPassword failure and show the user an error, prompting them to retry, instead of completing "successfully." Additional Information: - Reproduced on 6 different physical machines (mixed AMD/Intel CPUs, integrated/discrete GPUs including Nvidia) and in a GNOME Boxes VM - 100% reproduction rate across 5-6 reinstalls on one machine - Also reproduced on the 20260731 Workstation respin, so this is not fixed in the latest available image as of that date - Password used contained only lowercase letters and numbers, no special/non-ASCII characters, standard US keyboard - No disk encryption (no LUKS) in any affected install - A related but not identical issue was reported for Fedora Jam/KDE (plasma-initial-setup) in Bugzilla 2477902 - different code path, possibly different root cause - Background discussion: https://discussion.fedoraproject.org/t/official-fedora-44-workstation-iso-can-lock-users-out-at-first-login-with-no-warning-on-the-download-page-that-a-fixed-respin-exists/198190 Recorded the full process (fresh VM install → gnome-initial-setup → password set → login failure) in case it helps: https://youtu.be/v3Bs08U_lKE — used a different, disposable password for this test. Timestamps for the video, in case it helps: user/password creation around 7:59, login attempt around 9:20. Update: I just tested a fresh install selecting English (US) as the system language instead of Turkish, keeping everything else identical (same ISO, VM configuration, and ASCII password credentials). This time, the installation completed successfully, I was able to log in at GDM without any issues, and no chpasswd errors were logged. It turns out this bug is locale-dependent: selecting Turkish during setup triggers the chpasswd failure in accounts-daemon (likely due to locale-specific case/string handling when calling chpasswd without LC_ALL=C), while English (US) works fine.
Can reproduce using username 'semih' and password '123456789qwertyuiop' (well, those keys pressed on a US keyboard, the string being typed may not be exactly that). I see the same errors in the journal, and g-i-s never hands off to a logged-in desktop as it should. We do have automated testing of a Turkish install, as it's a known tricky scenario, but it's done from the Server DVD, not the Workstation live, so it did not hit this exact path :/
Oh, actually, my test password would have included a non-ASCII character - pressing i on a US keyboard with the tr layout set gives you an i wit no dot, I think it's the character ı . I'm going to test KDE and also test a GNOME install without that letter in the password.
OK, no, that was wrong. My Workstation test used us keyboard layout, so the password really was '123456789qwertyuiop' and it still failed. I also tested with username 'test' and password '111111' and it failed, same with password 'aaaaaa'. So it definitely seems like it's just something about using Turkish locale, and it's GNOME-specific. I suspect the issue is in accountsservice as gnome-initial-setup really just uses accountsservice for this stuff.
Ah - I think this may have been fixed since F44. Current Rawhide Workstation live does not show the bug.
CCing Ray and Björn who made possibly-relevant changes to accountsservice between 23.13.9 (latest in F44) and 26.27.3 (current in Rawhide). Any idea what fixed(?) this? Can we backport it?
Probably related to (or even a duplicate of) bug #2548931.
Hah, yes, probably is. Apparently I forgot I'd already discovered it. I suspect in comment #4 it wasn't fixed, I just saw a test that got lucky. If the hash has no 'i' or 'I' characters in it, it passes. *Most* hashes wind up with at least one occurrence of one of those letters, but occasionally one doesn't.
*** This bug has been marked as a duplicate of bug 2548931 ***