Bug 543746

This is because whenever you have an ARRAY line in mdadm.conf, and the UUID of that line matches the UUID of an array, then *all* items on the line must match or else it is a failed match and the device is not assembled.  For certain items, items which might change by the use of the --grow option to mdadm or adding disks to arrays, you do not want to specify those items on the ARRAY line or else changes do render the array unassemblable.  This has already been changed in mdadm so that mdadm -Eb or mdadm -Db will not put changable items into the ARRAY line it outputs and instead sticks to just the minimal data needed to positively identify the array.  Unfortunately, on upgrade, the array lines are not rewritten.  So, I'm not sure there is much that can be done about this other than to caution people to edit their mdadm.conf files and reduce the ARRAY lines to just the needed data.  However, I'm positive that whatever else might be done would need to be in anaconda, not mdadm.

At the very least, the boot process must _say_ why it is refusing to assemble the array.  Just silently refusing to assemble the array isn't very nice.

The way I found out was to mount the system under a live CD, extract the initramfs image and attempt to assemble the array myself.  I only did that because I noticed an anomaly when I pulled out the hot-swap drive.

The latest mdadm (in rawhide now, will build here too) resolves this issue, but not by issuing the warning you suggest.  Instead, the standard way of creating an array line using mdadm is to do one of:

mdadm -Db /dev/md? or mdadm -Eb /dev/sd?? >> /etc/mdadm.conf which will create a new ARRAY line for your device.  This method used to print out information that could legitimately change (such as number of devices).  The output of this operation has been reduced to just the information that should never change so that if a person later grows an array to a slightly different configuration it will no longer be rendered broken by an overly strict ARRAY line in the config file.

mdadm-3.1.1-0.gcd9a8b5.3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mdadm-3.1.1-0.gcd9a8b5.3.fc12

mdadm-3.1.1-0.gcd9a8b5.3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/mdadm-3.1.1-0.gcd9a8b5.3.fc13

mdadm-3.1.1-0.gcd9a8b5.3.fc13 has been pushed to the Fedora 13 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/F13/FEDORA-2010-1714

mdadm-3.1.1-0.gcd9a8b5.3.fc12 has been pushed to the Fedora 12 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/F12/FEDORA-2010-1891

mdadm-3.1.2-9.fc13,initscripts-9.09-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/mdadm-3.1.2-9.fc13,initscripts-9.09-1.fc13

mdadm-3.1.2-9.fc13, initscripts-9.09-1.fc13 has been pushed to the Fedora 13 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 initscripts'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/mdadm-3.1.2-9.fc13,initscripts-9.09-1.fc13

initscripts-9.09-1.fc13, mdadm-3.1.2-10.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.