Description of problem: When I boot my my machine, it hangs. When I changed SELinux to permissive, it started to work. The system is working fine when SELinux is in permissive-mode. The change happened after I upgraded my installation on Friday. SELinux is preventing systemd-user-se from 'create' accesses on the file .#nologinBgczG4. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-user-se should be allowed create access on the .#nologinBgczG4 file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c systemd-user-se --raw | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:systemd_logind_var_run_t:s0 Target Objects .#nologinBgczG4 [ file ] Source systemd-user-se Source Path systemd-user-se Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-182.fc24.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.5.2-300.fc24.x86_64 #1 SMP Wed Apr 20 16:46:11 UTC 2016 x86_64 x86_64 Alert Count 2 First Seen 2016-04-15 16:35:44 CEST Last Seen 2016-04-22 16:18:23 CEST Local ID fc3074e6-fe04-47b5-8ae5-d9640000bb87 Raw Audit Messages type=AVC msg=audit(1461334703.182:784): avc: denied { create } for pid=16933 comm="systemd-user-se" name=".#nologinBgczG4" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_logind_var_run_t:s0 tclass=file permissive=0 Hash: systemd-user-se,init_t,systemd_logind_var_run_t,file,create Version-Release number of selected component: selinux-policy-3.13.1-182.fc24.noarch Additional info: reporter: libreport-2.7.0 hashmarkername: setroubleshoot kernel: 4.5.2-302.fc24.x86_64 reproducible: Not sure how to reproduce the problem type: libreport
Created attachment 1152640 [details] File: dnf.rpm.log
This is now fixed. Probably the last selinux update fixed the problem.
*** Bug 1336215 has been marked as a duplicate of this bug. ***