On Monday April 9, frank.baumgart@xxxxxxx wrote: > Hello, > > hopefully someone can help me. I'll see what I can do :-) > > The 4 x 300 RAID can not be assembled anymore. > > mdadm --assemble --verbose --no-degraded /dev/md5 /dev/hdc1 /dev/sdb1 > /dev/sdc1 /dev/sdd1 > > mdadm: looking for devices for /dev/md5 > mdadm: /dev/hdc1 is identified as a member of /dev/md5, slot 2. > mdadm: /dev/sdb1 is identified as a member of /dev/md5, slot 3. > mdadm: /dev/sdc1 is identified as a member of /dev/md5, slot 0. > mdadm: /dev/sdd1 is identified as a member of /dev/md5, slot 1. > mdadm: added /dev/sdd1 to /dev/md5 as 1 > mdadm: failed to add /dev/hdc1 to /dev/md5: Invalid argument > mdadm: failed to add /dev/sdb1 to /dev/md5: Invalid argument > mdadm: failed to add /dev/sdc1 to /dev/md5: Invalid argument > mdadm: /dev/md5 assembled from 0 drives (out of 4), but not started. That is a little odd. Looking at the 'Event' number on the devices as given below, sdd1 is way behind all the others, and so mdadm should not be including it... and even if it is, the kernel should simply let the one with the higher event count over-ride. Are there any kernel logs that this time which might make it clear what is happening? > > Detaching sdb (the faulty disk) does not make any difference. sdd1 seems to be the problem. Can you run the above 'mdadm' command but without listing /dev/sdd1 ? > /dev/sdb1: .... > > Number Major Minor RaidDevice State > this 3 8 49 3 active sync > /dev/sdd1 <- what's this? why "SDD"? This is "SDB"! also, this > is the faulty device! /dev/sdd1 is the device with major/minor numbers 8,49. The last time the array was assembled, the device at slot '3' had major/minor numbers 8,49. It is telling you what the situation used to be, not what it is now. Just ignore it... NeilBrown - 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
