On Thu, Oct 19 2017, sfunk1x wrote: > On 10/19/2017 02:17 PM, NeilBrown wrote: > >> 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* ?? > >> 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. > >> >> 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.
Attachment:
signature.asc
Description: PGP signature
