Comment 11 for bug 1209423

@Stefan: --scan command might be useless but thanks anyway since it helped me noticing the issue that make me solve it :)

Here is the output of the scan command and the relevant content of the config file:
$ sudo mdadm --misc --scan --detail
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=01.02 name=alan-desktop:0 UUID=d5119bd2:7491e0f3:df5db333:6e036bee
ARRAY /dev/md3 level=raid1 num-devices=2 metadata=01.00 name=pca3:3 UUID=154f648b:6076c08b:76f5610a:9fbce7c7

$ cat /etc/mdadm/mdadm.conf | grep ARRAY
ARRAY /dev/md/0 level=raid1 metadata=1.2 num-devices=2 UUID=d5119bd2:7491e0f3:df5db333:6e036bee name=pca3:1
ARRAY /dev/md/3 level=raid1 metadata=1.0 num-devices=2 UUID=154f648b:6076c08b:76f5610a:9fbce7c7 name=pca3:3

As you can see there is a mismatch in the configured and scanned names, the latter coming from the array creation since long ago. Now, I have no idea why they differ however changing the one in the config file to match the scanned one made the array build up at boot again. Just confirmed with 2.6.32-50-generic

So, to reproduce the issue its probably enough to change the array name into mdadm.conf.
A last notice/recommendation: I do not understand why there is a need for array information to be placed into a configuration file and even more why to rely so much on it, such a config file will belong to a single system while arrays would be used also in multi-boot environments or have to be read also from recovery system used to boot a machine. I think relying on metadata on the drives only to be a far better approach.

Thank you for helping in solving the issue and let me know if you need more info for further development.