On 11/20/2013 03:30 AM, NeilBrown wrote: >>>> 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 -- 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
