On 11/20/2013 03:30 AM, NeilBrown wrote:

quoted

quoted

quoted

mdadm --examine --scan

ARRAY metadata=ddf UUID=7ab254d0:fae71048:
404edde9:750a8a05
ARRAY container=7ab254d0:fae71048:404edde9:750a8a05 member=0
UUID=5337ab03:86ca2abc:d42bfbc8:23626c78

This shows that mdadm found a container with the correct UUID, but the member
array inside the container has the wrong uuid.

Martin: I think one of your recent changes would have changed the member UUID
for some specific arrays because the one that was being created before wasn't
reliably stable.  Could  that apply to David's situation?

I am confused. AFAIL, my patch bedbf68a first introduced subarray UUIDs
for DDF. I don't understand how this mdadm.conf could have worked with
mdadm 3.2.x.

But you are right, I had to make 7087f02b later that changed the way
subarray UUIDs were calculated. This would hurt people who created their
mdadm.conf file) with stock 3.3 and updated to latest git later.

David: if you remove the "UUID=" part for the array leaving the
"container=.... member=0" as the identification, does it work?

I second that. David, please try it. I'd also appreciate "mdadm -E
/dev/sdX" output for all the RAID disks.

Martin