Bug 2517109

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.