On Thu, Oct 19 2017, sfunk1x wrote:

On 10/19/2017 02:17 PM, NeilBrown wrote:

quoted

Anything is better than nothing..  Can we get a photo of "mdadm
--examine" output on one of the devices (e.g. /dev/sda1) ??

Also, what mdadm version (mdadm -V) and kernel version (uname -r)?

https://imgur.com/x2rZEl5

I included an --examine of sda1 and sdf.

Thanks.  sdf looks like it might have a gpt partition
table on it.  The "od -x" supports that.  What does "fdisk -l /dev/sdf"
show? What about 
  mdadm --examine /dev/sdf*
??

quoted

mdadm never tries to edit mdadm.conf.
It does modify files in /run/mdadm (or maybe /var/run/mdadm).
Can we get a photo of that audit log?

I was mistaken, I think. It looks like mdadm tried to read (??) the file
and the context for the file was not set properly:

https://imgur.com/5UvFExp

As you say, it was reading.  That makes sense but shouldn't be fatal.

In order to "fix" the issue, I ran sealert against the audit.log and
followed it's instructions, producing a rules file.

quoted

I'm very suspicious of these new drives appearing to have not metadata.
Can you
   od -x /dev/sdf | head
   od -x /dev/sdf | grep a92b
and provide a photo of the output?

grep'ing a92b scrolled off the screen, so I grabbed a portion of it,
ctrl-c' and included head:

I should have suggested " | head" at the end of the 'grep'
command.  Maybe make it
  od -x /dev/sdf | grep '4efc a92b' | head
That will look for md metadata.

Thanks
NeilBrown

https://imgur.com/WDcAYBc

Thanks for the help so far.