Bug 466803

Can you clarify something for me.  You say that you are building an array in step 1, and you are using the --build option.  But the --build option does *not* create a persistent superblock, so once you reboot the machine in step 2, the array would no longer exist.  If that's the case, then the problem in step 3 is not a bug.  However, if you said --build but what you actually did was a --create, then the superblock would still exist and this would be a legitimate bug.  Can you please clarify your situation?

Sorry, that's effectively a "--create", an existing & working md config.

This appears to be resolved with mdadm-2.6.7.1:

[root@firewall ~]# mdadm -C /dev/md10 -l1 -n2 /dev/loop10 missing
mdadm: array /dev/md10 started.
[root@firewall ~]# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [raid1] 
md10 : active raid1 loop10[0]
      102336 blocks [2/1] [U_]
      
md1 : active raid1 sdb1[2] sdd1[4] sda1[0] sdc1[1]
      104376 blocks super 1.0 [4/4] [UUUU]
      bitmap: 0/7 pages [0KB], 8KB chunk

md0 : active raid5 sda2[0] sdd2[4] sdb2[2] sdc2[1]
      937390080 blocks super 1.1 level 5, 1024k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 13/298 pages [52KB], 512KB chunk

unused devices: <none>
[root@firewall ~]# mdadm -S /dev/md10
mdadm: stopped /dev/md10
[root@firewall ~]# mdadm -A /dev/md10 /dev/loop10
mdadm: /dev/md10 has been started with 1 drive (out of 2).
[root@firewall ~]# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [raid1] 
md10 : active raid1 loop10[0]
      102336 blocks [2/1] [U_]
      
md1 : active raid1 sdb1[2] sdd1[4] sda1[0] sdc1[1]
      104376 blocks super 1.0 [4/4] [UUUU]
      bitmap: 0/7 pages [0KB], 8KB chunk

md0 : active raid5 sda2[0] sdd2[4] sdb2[2] sdc2[1]
      937390080 blocks super 1.1 level 5, 1024k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 5/298 pages [20KB], 512KB chunk

unused devices: <none>
[root@firewall ~]#

(In reply to comment #3)
> This appears to be resolved with mdadm-2.6.7.1:

Can you confirm we're talking about the rescue image ?

I don't have the ability to create rescue images, so no.  I was just confirming that the mdadm build I'm working on will actually create an array without needing a UUID identifier (which was the root cause of the problem you had, that it was on a rescue image was moot, the problem is that the older mdadm would refuse to assemble an array if all you gave it was a name and a constituent device, and not any other identifier information and no information was present in mdadm.conf).  Actual run testing of a rescue image will have to wait until after this mdadm build hits the dist-f10 tag and gets included in the next generated rescue cd image.

mdadm-2.6.7.1-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/mdadm-2.6.7.1-1.fc9

mdadm-2.6.7.1-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mdadm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9325

mdadm-2.6.7.1-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.