It worked on Fedora 42, but after update to Fedora 43, it doesn’t work. I took a look at logs and it said that it couldn’t find Python package homeassistant. I previously dealt with this issue in another application, so I knew that the problem was Python update from 3.13 to 3.14, so I went to recreate the venv and reinstall the package. Then SELinux started throwing security alerts, and the troubleshooter suggested doing in a loop:
I have to admit that I started doing random things that I don’t remember hoping that some change in SELinux would eventually work, so it’s really difficult to tell what is my current state of SELinux configuration. In either case, currently HomeAssistant webserver does start, but no functionality works and there are lots of “access denied” errors in the logs, and I keep getting pop-ups “New SELinux security alert”.
Is there some easy way to make SELinux allow HomeAssistant to function, or is it better to completely disable SELinux? I tried to read a little about how SELinux works, but it seems very complicated.
If you click on “Details” what does it show? There can be important information in there. I know they don’t really like posting screenshots here but maybe you can find some of the important info towards the bottom. That has helped me solve at least one issue that I was having.
Also here are a couple of articles on the subject.
Use permissive SELinux mode for troubleshooting.
Some alerts do not appear until you resolve previous ones.
Permissive mode is specifically useful for collecting all alerts.
Sometimes this also requires to disable dontaudit rules.
Didn’t read in detail, but there are already some SELinux issues identified and fixes are on their way.
Three BZ# are in the update that was pushed to stable today, so a dnf update --refresh should tackle these three alread now (Making sure you're not a bot!)
Another issue I identified on my system is to be fixed in the subsequent update that should be there soon as well (the fix from our selinux-policy maintainer is already available and I tested+verified it). I don’t think the latter issue will affect people not using confined users, but the first three might contain solutions for you too.
So you might do the dnf update --refresh, install all updates, reboot, and if the issue is then still there, provide us with some information about SE denials.
E.g., the output of journalctl --boot=0 --unit setroubleshoot.service --no-hostname while running an affected boot, at the best along with journalctl --boot=0 -k --no-hostname or even along with journalctl --boot=0 --no-hostname. Also, it would be good to get cat /proc/sys/kernel/tainted and dnf repolist for an overview (and if you have done any customizations).
That might be a way to verify if an issue is SELinux-related, but it cannot be a permanent solution.
I agree that just setting SELinux mode to permissive is not a solution. I prefer to do some troubleshooting to see what is going on. I was able to fix a problem with SELinux AVC Denial messages popping up every time I did a screenshot. When I looked in the details it mentioned that it was related to the systemd-homed service. Disabled that service and the problem went away. Also in the article that I referenced in a previous post it seems that you can get information by using the command journalctl -t setroubleshoot. Adding on the --since=time option at the end can bring up only the most recent messages as well.
OK. I am learning some things… I just got an AVC Denial message to pop up by downloading a PDF file. No idea why this is happening. So then I used the journactl -t setroubleshoot --since=time command to bring up the message. At the top it says to use the sealert -l [message_ID] command to get the details of that message. That output will be the same as what you see when you click on the details of an SELinux Alert. You could copy and paste than information here and maybe someone can figure out what is going on.