Upgraded 2 very different Fedora 40 systems using dnf to pam-1.6.1-1.fc40. In both cases, after reboot the graphical target wouldn't load and failing processes created 1000's of core files. Switching to a virtual console, I was unable to log in. I rebooted to single mode, enabled the multi-user target, and rebooted again. I was still unable to log in. I also verified that SSH would fail & core when attempting to log in. After inspecting the logs, it was obvious that pam was the problem. I ran dnf downgrade pam, rebooted, and everything worked as expected on both systems. One is +8y old and the other is -1y old. Reproducible: Always Steps to Reproduce: 1.Upgrade to pam-1.6.1-1.fc40 2.Reboot Actual Results: System completely unusable and core files being generated. Graphical target fails. No logins via any method succeed. Expected Results: System operated normally as previously: graphical target loaded without errors, and logins via DM, virtual console, or SSH worked.
Possibly related to bug 2280896, but that only mentions the graphical target.
Created attachment 2034867 [details] Core files from +8y old system I initially thought the DM was the source of the problem, so I tried different DMs, and they all failed the same way. I'll attach 3 cores files from this system.
Created attachment 2034868 [details] Core files from +8y old system
Created attachment 2034869 [details] Core files from +8y old system
Created attachment 2034870 [details] Core files from -1y old system
Created attachment 2034871 [details] Core files from -1y old system
I think you are hitting https://bugzilla.redhat.com/show_bug.cgi?id=2280896. Can you check whether /etc/environment contains any NULL value? If it's the same issue I think I have a fix for it. Would you be willing to test it?
In /etc/environment there is one line that is: DESKTOP_AUTOSTART_ID= I assume that be a NULL value? I don't remember why that's there, it could be to solve a problem in the past 20y that is no longer relevant. I see the COPR link in the other bug, I'll test it.
Yes, that's a NULL value
I also looked at the conversation in https://bugzilla.redhat.com/show_bug.cgi?id=2280896 I verified: - the issue is still not present in 1.6.0-2 - the issue still exists in 1.6.1-1 - the issue goes away when I remove the NULL assignment in /etc/environment - the issue goes away when I change the NULL assignment to "" - the issue returns when I restore the NULL assignment - the issue is NOT present in 1.6.1-2test But as noted in the other bug: - in 1.6.1-2test a NULL assignment results in the variable NOT getting set, which is a change in behavior
*** This bug has been marked as a duplicate of bug 2280896 ***