When I reboot or shutdown the computer, the sequence stops and the computer doesn't reboot or completely shuts down. I have to press the power button for 5 seconds in order to force a power off. When run with setenforce permissive this issue doesn't occur. Running without the rhgb and quiet boot flags I can see the last messages of the console: audit: type=1400 audit(1511192212.675:377): avc: denied { write } for pid=4175 comm="mdadm" name="md127.sock" dev="tmpfs" ino=1463 scontext=system_u:system_r:mdadm_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=sock_file permissive=0 audit: type=1400 audit(1511192212.675:377): avc: denied { write } for pid=4184 comm="mount" name="utab" dev="tmpfs" ino=2250 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=0 audit: type=1400 audit(1511192212.680:378): avc: denied { write } for pid=4187 comm="mount" name="utab" dev="tmpfs" ino=2250 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=file permissive=0 There's also a relevant message during boot: systemd[1]: Unable to fix SELinux security context of /run/mdadm/md127.sock: Permission denied kernel: audit: type=1400 audit(1511192361.989:56): avc: denied { relabelto } for pid=1 comm="systemd" name="md127.sock" dev="tmpfs" ino=16767 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:mdadm_var_run_t:s0 tclass=sock_file permissive=0 Version-Release number of selected component (if applicable): selinux-policy-3.13.1-283.16.fc27.noarch selinux-policy-targeted-3.13.1-283.16.fc27.noarch May also be of relevance: # ls -lZ /run/mdadm total 20 -rw-r--r--. 1 root root system_u:object_r:mdadm_var_run_t:s0 5 Nov 20 15:39 autorebuild.pid -rw-------. 1 root root system_u:object_r:mdadm_var_run_t:s0 255 Nov 20 15:39 map -rw-------. 1 root root system_u:object_r:mdadm_var_run_t:s0 4 Nov 20 15:39 md125.pid srwx------. 1 root root system_u:object_r:mdadm_var_run_t:s0 0 Nov 20 15:39 md125.sock -rw-------. 1 root root system_u:object_r:mdadm_var_run_t:s0 4 Nov 20 15:39 md127.pid srwx------. 1 root root system_u:object_r:tmpfs_t:s0 0 Nov 20 15:39 md127.sock -rw-r--r--. 1 root root system_u:object_r:mdadm_var_run_t:s0 5 Nov 20 15:39 mdadm.pid # cat /proc/mdstat: Personalities : [raid1] md124 : active (auto-read-only) raid1 sdb[1] sda[0] 488383488 blocks super external:/md125/0 [2/2] [UU] md125 : inactive sda[1](S) sdb[0](S) 5928 blocks super external:imsm md126 : active raid1 sdc[1] sdd[0] 488383488 blocks super external:/md127/0 [2/2] [UU] md127 : inactive sdd[1](S) sdc[0](S) 5928 blocks super external:imsm unused devices: <none> # parted /dev/md126 print Model: Linux Software RAID Array (md) Disk /dev/md126: 500GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 1075MB 1074MB primary ext4 boot 2 1075MB 7435MB 6361MB primary linux-swap(v1) 3 7435MB 500GB 493GB primary btrfs # mount | grep md126 /dev/md126p3 on / type btrfs (rw,relatime,seclabel,space_cache,subvolid=257,subvol=/root) /dev/md126p3 on /home type btrfs (rw,relatime,seclabel,space_cache,subvolid=266,subvol=/home) /dev/md126p1 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
Thanks for reporting this. I fixed all AVC and fixes should be part of next selinux-policy build. Please let me know if is issue fixed. Lukas.
selinux-policy-3.13.1-283.17.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d05b1a2ab9
selinux-policy-3.13.1-283.17.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d05b1a2ab9
I updated selinux-policy and selinux-policy-targeted selinux-policy-3.13.1-283.17.fc27.noarch selinux-policy-targeted-3.13.1-283.17.fc27.noarch Problem persists, but with a different message: audit: type=1400 audit(1511447203.561:370): avc: denied { create } for pid=2128 comm="mount" name="utab.lock" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:mount_var_run:t:s0 tclass=file permissive=0 tried forcing relabeling with touch /.autorelabel and also tried refreshing the initrd with dracut -f but didn't solve the issue.
selinux-policy-3.13.1-283.17.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
Hi. I'm still having the issue reported in comment #4. I managed to connect another computer to the serial console and these are the last messages in the console. [ OK ] Reached target Shutdown. [ 762.838064] watchdog: watchdog0: watchdog did not stop! [ 764.099462] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 764.129057] systemd-journald[674]: Received SIGTERM from PID 1 (systemd-shutdow). [ 764.214757] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 764.219996] systemd-shutdown[1]: Hardware watchdog 'iTCO_wdt', version 0 [ 764.221030] systemd-shutdown[1]: Unmounting file systems. [ 764.221102] systemd-shutdown[1]: Failed to parse /proc/self/mountinfo:1. [ 764.221110] systemd-shutdown[1]: Failed to parse /proc/self/mountinfo:2. [ 764.221118] systemd-shutdown[1]: Failed to parse /proc/self/mountinfo:3. [ 764.221125] systemd-shutdown[1]: Failed to parse /proc/self/mountinfo:4. [ 764.221132] systemd-shutdown[1]: Failed to parse /proc/self/mountinfo:5. [ 764.221139] systemd-shutdown[1]: Failed to parse /proc/self/mountinfo:6. [ 764.261509] systemd-shutdow: 29 output lines suppressed due to ratelimiting <30>systemd-shutdown[1]: Successfully changed into root pivot. <30>systemd-shutdown[1]: Returning to initrd... [ 764.264838] watchdog: watchdog0: watchdog did not stop! [ 764.295468] audit: type=1400 audit(1513013998.645:498): avc: denied { create } for pid=5112 comm="mount" name="utab.lock" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:mount The computer then stays like that for 10 minutes and then reboots. I figured that the 10 minutes wait is from the ShutdownWatchdogSec=10min option in /etc/systemd/system.conf because I changed that option to 1min, systemctl daemon-reload and reboot. Now the computer is only stuck 1 minute
I have the same issue with selinux-policy-3.13.1-283.17.fc27.noarch selinux-policy-targeted-3.13.1-283.17.fc27.noarch Temporary disabling selinux allows me to reboot: setenforce 0; reboot
I posted the same bug for Fedora 24 more than a year ago https://bugzilla.redhat.com/show_bug.cgi?id=1379044 I proposed a solution with a small selinux module, but nobody has incorporated this module to selinux-policy before Fedora 24 EOL. This solution is still working in Fedora 27: after compiling and installing this module I can easy reboot or shutdown: ---------------------------------------------------------------------- module my-mdadm 1.0; require { type mdadm_var_run_t; type init_t; type mdadm_t; type tmpfs_t; type user_tmp_t; class unix_stream_socket connectto; class sock_file { relabelto write }; class file { create getattr rename write }; } #============= init_t ============== #!!!! This avc is allowed in the current policy allow init_t mdadm_t:unix_stream_socket connectto; #!!!! This avc is allowed in the current policy allow init_t mdadm_var_run_t:file { create rename write }; #!!!! This avc is allowed in the current policy allow init_t mdadm_var_run_t:sock_file { relabelto write }; #============= mdadm_t ============== #!!!! The file '/dev/shm/lldpad.state' is mislabeled on your system. #!!!! Fix with $ restorecon -R -v /dev/shm/lldpad.state allow mdadm_t tmpfs_t:file getattr; ----------------------------------------------------------------------
Some more information: my mdadm process is launched from dracut instead of systemd so it has init_t context instead of mdadm_t. Maybe it is wrong...
Oleg, Could you attach output of: # ls -Z Thanks, Lukas.
Hello, After upgrading to versions: selinux-policy-3.13.1-283.26.fc27.noarch selinux-policy-targeted-3.13.1-283.26.fc27.noarch I no longer have this issue.