There appears to be a real bug here that openQA is catching. Somehow, live images built with this update included just do not boot successfully, neither KDE or GNOME ones. They get stuck partway through boot.
It really does seem to be specific to this update, because the same tests run on both earlier and later updates have passed; if the bug was introduced by some other change, the tests would be failing on other updates too.
Some users on IRC are saying they are getting a forced password change on login and they've set no such thing up and don't see a reason for it to be trying to do this. They said downgrading this package seemed to make it stop, so there may be something wrong here.
Some users on IRC are saying they are getting a forced password change on login and they've set no such thing up and don't see a reason for it to be trying to do this. They said downgrading this package seemed to make it stop, so there may be something wrong here.
That might happen to users, who didn't change their passwords since 2007 or so, as libxcrypt now reports the use of very unsafe hash methods to PAM.
That is interesting, since this happened with a ~2016 server install, which has been slowly upgraded as time went by. Specifically this was with the 4.4.21 version
Afterwards, at every login prompt it would just prompt me to change my password. The first time it popped back up it was weird, but I went along with it. It logged me out and I attempted to log in again. I hit the same thing, and at this point I decided it was in a loop. Thankfully I had some free time now to utilize a recovery image and chroot into my actual sysroot, and downgrade back to 4.4.20.
Excerpts from journal:
Initial login, password change:
May 27 20:07:02 das-hostname systemd[1]: Starting User Manager for UID USER_ID...
May 27 20:07:02 das-hostname systemd[695]: pam_unix(systemd-user:account): expired password for user das_user (root enforced)
May 27 20:07:02 das-hostname systemd[695]: PAM failed: Authentication token is no longer valid; new one required
May 27 20:07:02 das-hostname systemd[695]: user@USER_ID.service: Failed to set up PAM session: Operation not permitted
May 27 20:07:02 das-hostname systemd[695]: user@USER_ID.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
May 27 20:07:02 das-hostname systemd[1]: user@USER_ID.service: Main process exited, code=exited, status=224/PAM
May 27 20:07:02 das-hostname systemd[1]: user@USER_ID.service: Failed with result 'exit-code'.
May 27 20:07:02 das-hostname systemd[1]: Failed to start User Manager for UID USER_ID.
May 27 20:07:02 das-hostname systemd[1]: Started Session 1 of user das_user.
May 27 20:07:02 das-hostname sshd[692]: pam_unix(sshd:session): session opened for user das_user(uid=USER_ID) by (uid=0)
May 27 20:17:28 das-hostname passwd[697]: pam_unix(passwd:chauthtok): password changed for das_user
Second attempt
May 27 20:17:31 das-hostname systemd[1]: Starting User Manager for UID USER_ID...
May 27 20:17:31 das-hostname systemd[709]: pam_unix(systemd-user:account): expired password for user das_user (root enforced)
May 27 20:17:31 das-hostname systemd[709]: PAM failed: Authentication token is no longer valid; new one required
May 27 20:17:31 das-hostname systemd[709]: user@USER_ID.service: Failed to set up PAM session: Operation not permitted
May 27 20:17:31 das-hostname systemd[709]: user@USER_ID.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
May 27 20:17:31 das-hostname systemd[1]: user@USER_ID.service: Main process exited, code=exited, status=224/PAM
May 27 20:17:31 das-hostname systemd[1]: user@USER_ID.service: Failed with result 'exit-code'.
May 27 20:17:31 das-hostname systemd[1]: Failed to start User Manager for UID USER_ID.
May 27 20:17:31 das-hostname systemd[1]: Started Session 2 of user das_user.
May 27 20:17:31 das-hostname sshd[706]: pam_unix(sshd:session): session opened for user das_user(uid=USER_ID) by (uid=0)
I have not tested 4.4.22 yet, if that improves things. Additionally, are there any hints in f.ex. password -S das_user which would give a hint to the user that they would be hitting issues?
This update has been submitted for testing by besser82.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
There appears to be a real bug here that openQA is catching. Somehow, live images built with this update included just do not boot successfully, neither KDE or GNOME ones. They get stuck partway through boot.
It really does seem to be specific to this update, because the same tests run on both earlier and later updates have passed; if the bug was introduced by some other change, the tests would be failing on other updates too.
To test, grab https://openqa.stg.fedoraproject.org/tests/1199611/asset/iso/01199611-Fedora-Workstation-Live-x86_64-FEDORA-2021-e6916d6758.iso (an affected ISO generated by openQA with this update included). I tested that locally and it fails to boot to a graphical environment. Booting with
systemd.debug-shell=1gives you a console on tty9 where you can poke around. I see these errors fromgdm.servicein the journal:This update has been pushed to testing.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
https://bugzilla.redhat.com/show_bug.cgi?id=1965149
Works.
besser82 edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by besser82.
This update's test gating status has been changed to 'passed'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'passed'.
Some users on IRC are saying they are getting a forced password change on login and they've set no such thing up and don't see a reason for it to be trying to do this. They said downgrading this package seemed to make it stop, so there may be something wrong here.
@khaytsus was that with 4.4.21 or 4.4.22?
@adamwill One user on x86 was using 4.4.22 and different user was on 4.4.21 on aarrrch64.
This update has been pushed to testing.
My machines still work, but not leaving karma.
works for me
works for me
@khaytsus, @adamwill:
That might happen to users, who didn't change their passwords since 2007 or so, as libxcrypt now reports the use of very unsafe hash methods to PAM.
That is interesting, since this happened with a ~2016 server install, which has been slowly upgraded as time went by. Specifically this was with the 4.4.21 version
Afterwards, at every login prompt it would just prompt me to change my password. The first time it popped back up it was weird, but I went along with it. It logged me out and I attempted to log in again. I hit the same thing, and at this point I decided it was in a loop. Thankfully I had some free time now to utilize a recovery image and chroot into my actual sysroot, and downgrade back to 4.4.20.
Excerpts from journal:
I have not tested 4.4.22 yet, if that improves things. Additionally, are there any hints in f.ex.
password -S das_userwhich would give a hint to the user that they would be hitting issues?besser82 edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by besser82.
besser82 edited this update.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'passed'.
This update has been pushed to testing.
This update has been submitted for stable by bodhi.
This update has been pushed to stable.