Created attachment 522019 [details] syslog from f16-beta.tc1 livecd showing failure --- Additional comment from dlehman on 2011-09-07 19:26:59 EDT --- The live version's problem is related to selinux. Here are the syslog entries from mdadm trying to start the array: Sep 7 19:12:34 localhost kernel: [ 36.687948] type=1400 audit(1315437142.158:4): avc: denied { create } for pid=555 comm="mdadm" name="0" scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mdadm_var_run_t:s0 tclass=lnk_file Sep 7 19:12:34 localhost kernel: [ 37.686153] md: bind<sda5> Sep 7 19:12:34 localhost kernel: [ 37.874116] md: bind<sda4> Sep 7 19:12:34 localhost kernel: [ 37.900842] type=1400 audit(1315437143.371:5): avc: denied { module_request } for pid=556 comm="mdadm" kmod="md-level-1" scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system Sep 7 19:12:34 localhost kernel: [ 37.910393] bio: create slab <bio-1> at 1 Sep 7 19:12:34 localhost kernel: [ 37.938256] md: personality for level 1 is not loaded! It is failing to create a symlink somewhere in /var/run and then it is failing to load the md raid1 kernel module, both times thwarted by selinux.
note that this is a Beta blocker bug through 731177's dependence on it, so please prioritize - thanks!
Dan, were the SELinux rules for mdadm updated to account for the change from /var/run to /run (and will they still work if the final file location is in /run instead of /var/run)? I can build a new mdadm that uses /run directly instead of going through /var/run, but I'm not certain that will solve this problem is what's happening is that the old mdadm rules expect /var/run, but due to the /var/run->/run symlink the final real file names are ended up in /run/mdadm and not matching the rules.
Yes we are labeling everything under /run as if it was under /var/run. We don't care how you create your files. Miroslav lets add kernel_request_load_module(mdadm_t)
Should probably backport to RHEL6 also.
Dan, Miroslav: this is a blocker issue for F16 Beta and we need all blockers resolved today or tomorrow in order to compose the first Beta release candidate on time. Can you please fix this and submit an updated selinux-policy as an update ASAP? Thanks!
This is fixed in the latest build. http://koji.fedoraproject.org/koji/buildinfo?buildID=263386 - Allow collectd to read hardware state information - Add loop_control_device_t - Allow mdadm to request kernel to load module Do I need to do a new update on F16 with this policy release? Or is the build enough?
Actually I am going to do a new build right now which should be included in the compose and submit it as an update.
yes, please submit an update - thanks!
selinux-policy-3.10.0-28.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-28.fc16
Package selinux-policy-3.10.0-28.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-28.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-28.fc16 then log in and leave karma (feedback).
I can confirm the fix looks good. I built a live image with anaconda 16.17 and selinux-policy 3.10.0-28. I do not see this traceback on the console when starting liveinst, and I can select my BIOS RAID array in advanced devices and 'continue': previously, anaconda would exit showing the traceback at that point, now it continues. I can't complete a test install as the RAID array is my production laptop F15 install, but at least I can say this specific issue looks to be fixed.
selinux-policy-3.10.0-28.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.