Description of problem: This problem happens after running 'dnf upgrade'. Virtual machines are no longer able to access their disks because the user, group, and SELinux context of disk files are reset to the default. This usually causes virtual machines to stop working or crash. This problem is not always reproducible because most updates don't trigger it. Only a few updates can cause this problem. SELinux is preventing worker from 'read' accesses on the blk_file /dev/dm-11. ***** Plugin catchall (100. confidence) suggests ************************** If 您認為 worker 就預設值應擁有 dm-11 blk_file 的 read 存取權。 Then 您應將此回報為錯誤。 您可產生本機模組,以允許這項存取。 Do allow this access for now by executing: # ausearch -c 'worker' --raw | audit2allow -M my-worker # semodule -X 300 -i my-worker.pp Additional Information: Source Context system_u:system_r:svirt_t:s0:c645,c843 Target Context system_u:object_r:fixed_disk_device_t:s0 Target Objects /dev/dm-11 [ blk_file ] Source worker Source Path worker Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-191.16.fc24.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.7.4-200.fc24.x86_64 #1 SMP Thu Sep 15 18:42:09 UTC 2016 x86_64 x86_64 Alert Count 3 First Seen 2016-10-04 20:51:14 CST Last Seen 2016-10-04 20:51:14 CST Local ID 650fd888-20dc-4f2d-8d49-afa7aaf6cd10 Raw Audit Messages type=AVC msg=audit(1475585474.117:3088): avc: denied { read } for pid=13158 comm="worker" path="/dev/dm-11" dev="devtmpfs" ino=13533 scontext=system_u:system_r:svirt_t:s0:c645,c843 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file permissive=0 Hash: worker,svirt_t,fixed_disk_device_t,blk_file,read Version-Release number of selected component: selinux-policy-3.13.1-191.16.fc24.noarch Additional info: reporter: libreport-2.7.2 hashmarkername: setroubleshoot kernel: 4.7.4-200.fc24.x86_64 type: libreport
I found the problem can be reproduced by running 'systemctl try-restart systemd-udev-trigger.service'. This command is included in systemd-udev scriptlets, so it can also happen when updating systemd.
Move it to systemd because it is a change in systemd.spec that causes the issue to become annoying and easily reproducible: http://pkgs.fedoraproject.org/cgit/rpms/systemd.git/commit/?id=c16b573
Looks like udev or something changed the label on this device. Looks like another good reason not to do dnf upgrade on a running machine.
Thia problem has been fixed by removing 'systemctl try-restart systemd-udev-trigger.service' in systemd.spec.