On 10/03/2013 04:23 AM, Wakko Warner wrote: > Please keep me in CC. > > I compiled v3.3 to see if the problem was still there. It is. The problem. > I setup an imsm array with 2 volumes. a 200mb raid10 volume, and a raid5 on > the remaining space. This was done from the bios. > > mdadm detected the array and volumes ok, but the names are wrong. the 200mb > was named EFI and the other was named ani. > > /dev/md127 is the imsm container. > 126 is the volume ani. (This is about 7tb. disks are 3tb each and > still initializing) > 125 is the volume EFI. > > According to --examine /dev/md127, > [EFI] UUID is ad256dcf:38ff8fed:8c27647e:24f61d81 > [ani] UUID is 9fe3c18a:0e9e2d4f:613456ca:b9989dcc > > However --detail --export /dev/md125 shows the name as ani with UUID > ad256dcf:38ff8fed:8c27647e:24f61d81 and --detail --export /dev/md126 shows > the name EFI with UUID 9fe3c18a:0e9e2d4f:613456ca:b9989dcc. > > I did manually bring these up using mdadm 3.2.5-5 (Debian). I don't remember > the exact commands off the top of my head, but they should be in my history if > needed. Do I understand correctly, this is the situation after bringing up the array with mdadm 3.2.5, you are just looking at the state of affairs with mdadm 3.3? If yes, I wouldn't expect any difference between the output of mdadm 3.3 and 3.2.5. Both just reflect the current state of md in the kernel (MD_DEVNAME is just the device name the array has under /dev/md). In order to see if your problem is fixed with mdadm 3.3, you must assemble the array with 3.3 (and mdmon from 3.3 should be used as well). 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
