Description of problem: On a F40->F41 upgraded system, systemd-homed.service fails to start on boot. The logs say: systemd[1]: Starting systemd-homed.service - Home Area Manager... (md-homed)[1974]: systemd-homed.service: Failed to set up special execution directory in /var/cache: Permission denied (md-homed)[1974]: systemd-homed.service: Failed at step CACHE_DIRECTORY spawning /usr/lib/systemd/systemd-homed: Permission denied systemd[1]: systemd-homed.service: Main process exited, code=exited, status=239/CACHE_DIRECTORY systemd[1]: systemd-homed.service: Failed with result 'exit-code'. systemd[1]: Failed to start systemd-homed.service - Home Area Manager. I believe the problem might be caused by SELinux, see bug 2036108. Version-Release number of selected component (if applicable): systemd-256.7-1.fc41.x86_64 selinux-policy-41.21-1.fc41.noarch How reproducible: happens on each boot Steps to Reproduce: 1. upgrade F40 to F41 2. see systemd-homed.service fail to start Proposing as an F41 blocker, because: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present. " https://fedoraproject.org/wiki/Fedora_41_Final_Release_Criteria#System_services "The upgraded system must meet all release criteria." https://fedoraproject.org/wiki/Fedora_41_Beta_Release_Criteria#Upgrade_requirements A solution would be to either fix the problem, or disable the service by default.
So, openQA Rawhide tests have a lot of failures like this (failures of the base_services_start test because the homed service failed). I didn't get time to look into it yesterday. openQA F41 tests are not seeing the same, though. I note the selinux-policy build you're running is only in updates-testing: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8707c24571 , and there is actually some discussion about this bug there. It looks like zpytela is working on a fix at https://github.com/fedora-selinux/selinux-policy/pull/2390/checks . If this is caused by something that's only in updates-testing, it's not technically a blocker.
I tested with selinux-policy-41.20-1.fc41 and indeed, the service doesn't fail. Removing the blocker nomination.
*** This bug has been marked as a duplicate of bug 2036108 ***