systemctl status sssd
○ sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Condition: start condition failed at Sun 2022-04-24 21:04:16 -03; 1h 10min ago
├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
└─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met
systemd[1]: sssd.service - System Security Services Daemon was skipped because all trigger condition checks failed.
Let me explain my situation: five days ago I was running a F36 kde upgraded from F35, and the service was running fine.
Since then I have reinstalled F36 KDE with a development iso and using my old /home (btrfs subvolume), and then re-enable the testing repos, thus upgrading again to this version of the package.
And today I was aware that this service was not starting correctly.
It wasn't pushed at first because we had a viable RC. By policy things that aren't in an RC we might ship cannot be pushed stable, because the frozen release repos must match the contents of the released images.
We declared no-go yesterday and we won't be shipping that RC, so things can be pushed stable again. But it wasn't pushed yesterday because nobody actually marked the update as fixing the bug. That link has to be in place for the tool we use to generate the push requests to include the update in the list.
This update has been submitted for testing by pbrezina.
This update's test gating status has been changed to 'waiting'.
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.
No issues found.
This update can be pushed to stable now if the maintainer wishes
The update works, but having f36 in testing and f35 in production creates a problem when doing a dnf system-upgrade from f35 to f36 now.
This update has been submitted for stable by bodhi.
Requested a freeze exception here: https://bugzilla.redhat.com/show_bug.cgi?id=2077856
Works.
Now it seems this is having a problem...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2078243
systemctl status sssd ○ sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Sun 2022-04-24 21:04:16 -03; 1h 10min ago ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met
systemd[1]: sssd.service - System Security Services Daemon was skipped because all trigger condition checks failed.
Let me explain my situation: five days ago I was running a F36 kde upgraded from F35, and the service was running fine. Since then I have reinstalled F36 KDE with a development iso and using my old /home (btrfs subvolume), and then re-enable the testing repos, thus upgrading again to this version of the package. And today I was aware that this service was not starting correctly.
It looks like SSSD is not configured anymore after you reinstalled the system.
Oops, it looks like this now is expected behavior of this package as dev explained at the bug ticket, sorry for spamming here.
So this was accepted as FE 4 days ago... when it will be pushed to stable?
no regressions noted
FE accepted 6 days ago. Users still can't upgrade because of this issue.
adamwill edited this update.
It wasn't pushed at first because we had a viable RC. By policy things that aren't in an RC we might ship cannot be pushed stable, because the frozen release repos must match the contents of the released images.
We declared no-go yesterday and we won't be shipping that RC, so things can be pushed stable again. But it wasn't pushed yesterday because nobody actually marked the update as fixing the bug. That link has to be in place for the tool we use to generate the push requests to include the update in the list.
This update has been pushed to stable.