No need to disable SELinux. Just run setenforce 0 before calling mdadm. When your reshape is done enable SELinux again with setenforce 1 no reboot needed. Also if you want a permanent workaround you can whitelist mdadm process type: semanage permissive -a mdadm_t # but be aware I didn't tested this! On 11 December 2015 at 02:26, George Rapp <george.rapp@xxxxxxxxx> wrote: > Indeed, SELinux appears to be very not-helpful in the RAID resize > process. I decided to put SELINUX=disabled in /etc/selinux/config, > touch /.relabel, and reboot before doing any more RAID 6 work. > > The only other workaround I could see is the ability to do a "dry run" > of mdadm operations a la wodim / growisofs - a chance to test out all > the parameters before actually pulling the trigger. (Sorry, no patch, > though ... 8^) > > On Thu, Dec 10, 2015 at 1:24 PM, Wols Lists <antlists@xxxxxxxxxxxxxxx> wrote: >> On 10/12/15 17:06, Edward Kuns wrote: >>> I ran into this as well. I unwisely worked around it by placing the >>> backup file on /tmp. I don't recommend that choice! >> >> Most people don't realise there are various tmp directories, with >> different behaviours. /tmp is defined by LSB or somesuch to be real >> temporary storage - no guarantees - stuff may disappear at any time. >> Which is why my /tmp is a tmpfs - stored in ram. So yes, a backup file >> on /tmp is not a good idea ... >> >> /var/tmp is defined as holding data that must survive a reboot - where >> emacs and vi and that lot are recommended to store their crash dumps, >> recovery files, etc for example. >> >> I didn't see >>> your AVC on your EMail, but I recommend you reach out to the SELinux >>> folks for labeling help. I've reach out to them in the past and have >>> found them very helpful (as are the folks here). Getting the labeling >>> corrected will not only help you but everyone else in the long term. >>> >>> I agree that it would be good for mdadm to handle this kind of failure >>> in a more productive fashion as well. But I'm only a lurker here. I >>> don't have enough knowledge to suggest what would be better. One >>> thing that really helped me debug this was commenting out the lines >>> >>> #StandardOutput=null >>> #StandardError=null >>> >>> in the systemd file /lib/systemd/system/mdadm-grow-continue@.service >>> -- note you have to run systemctl daemon-reload after changing the >>> file for the change to be noticed. >>> >>> Once I did that, the system logs had much more useful information. >>> I'm not sure where that file is sourced, whether it's from the >>> linux-raid people or from the distributions or somewhere in between. >>> Does anyone here know if there's a reason why standard out and >>> standard error are sent to /dev/null for this service? >>> >> I wouldn't know for certain, but given the amount of junk so many >> programs spew to stdout or stderr (which nobody ever sees because >> they're running in a gui), I expect it's because that's what happens by >> default anyway :-) They don't want to clutter the logs with all that >> junk and chatter. >> >> I often somehow get stdout and stderr for various programs redirected to >> konsole, because I'll use dbus-launch to start a program. And then when >> the program has exited I'll get loads of rubbish from other programs ... >> the chatter is horrendous. >> >> Cheers, >> Wol >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > George Rapp (Pataskala, OH) Home: george.rapp -- at -- gmail.com > LinkedIn profile: https://www.linkedin.com/in/georgerapp > Phone: +1 740 936 RAPP (740 936 7277) -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
