Comment 7 for bug 576147

I can verify the bug described above, and that the workaround of Bug #469574 does NOT work.

My system 10.04 LTS on an AMD 86x64:
Linux logopolis 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux

Steps to reproduce:
* Initialized 8 1.5T new drive partitions - each drive getting primary partition 3 configured as type fd using the entire 1.5T of space.

* Verified all working drives via smartctl tests

* Created a new raid w/ the command:
sudo mdadm --create /dev/md0 --level=6 --verbose -c 128 --name=raid_disk_2 --raid-devices=8 --metadata 1.2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 /dev/sdg3 /dev/sdh3 /dev/sdi3 /dev/sdj3

* Created a ext4 fs on the raid, and added about 2.7T of data to raid (test data...)

* Added the ARRAY to the /etc/mdadm/mdadm.conf manually by adding the line returned from mdadm -Es:
ARRAY /dev/md/raid_disk_2 level=raid6 metadata=1.2 num-devices=8 UUID=b5402c2f:02bd34b0:fe8277f3:2925a050 name=logopolis:raid_disk_2

* Manually started and stopped the raid

* Rebooted, and got the phantom md_d127 raid.

* Verified that multiple reboots consistantly cause one or more of the 8 random drive partitions to be added to this md_d127 fake raid.

* Verified that after stopping md_d127 that mdadm -As starts the proper raid

* Verified that the Bug #469574 does NOT fix the problem, as this did not help:
# start your arrays manualy
# /usr/share/mdadm/mkconf force-generate /etc/mdadm/mdadm.conf
# update-initramfs -k all -u

* Finally, verified that by manually removing the name part of the ARRAY definition in mdadm.conf does not help, even after then re-running update-initramfs -k all -u

* The only fix I know works is to add a init script which stops the phantom raid and then assembles the correct one.

Interesting sidenote: In researching this problem, I found that the Fedora people might have seen the a similar sort of problem, see http://osdir.com/ml/linux-raid/2009-04/msg00358.html however I have not verified this; it may be a red herring.