Description of problem: Sometime in the last week, fresh installations of Fedora ELN have been failing. Users cannot log in because after entering their username at the login prompt, the system immediately rejects them. Investigating, I found that none of the expected symlinks exist in /etc/pam.d and that manually running `authselect select sssd` (or any other profile) gives: "[error] Unable to get profile information [2]: No such file or directory" Version-Release number of selected component (if applicable): authselect-1.4.0-1.eln118 How reproducible: Every time Steps to Reproduce: It's easiest to simulate the initial install using mock and the fedora-eln-x86_64.cfg from mock-core-configs: 1. Remove any existing root cache with `sudo rm -f /var/cache/mock/fedora-eln-x86_64/root_cache/cache.tar.gz` 2. Initialize the mock buildroot with `mock -r fedora-eln-x86_64 init` 3. Use `mock -r fedora-eln-x86_64 shell` to get a shell inside the mock chroot. Actual results: The /etc/authselect directory contains only an empty "custom" directory. None of the expected symlinks appear in /etc/pam.d. Expected results: A properly-configured authentication stack. Additional info: This appears unique to ELN. Rawhide is not experiencing the same bug. Since authselect has not changed for some time, I suspect that the real issue is in another component, but I haven't been able to get any information on what it could be. The RPM scriptlet does not print any errors during DNF installation of the chroot.
This looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2100287, can you confirm?
Yes, looks like it. Apparently when 1.19 was untagged from Rawhide, no one thought to check ELN for it. *** This bug has been marked as a duplicate of bug 2100287 ***