Bug 721905

This implies that when mdadm assembled the array it couldn't reliably determine which number it should use so it arbitrarily assigned one starting at 127 and working downwards.

As the arrays appear to be listed in /etc/mdadm.conf the possibly explanations that come to mind are:

1/ the uuids in /etc/mdadm.conf don't match the uuids of the arrays.  So please
  report
  mdadm -Ds
  so we can compare uuids.

2/ The arrays are getting assembled from the initrd and the mdadm.conf on the
  initrd does not have correct information.  So please:
  mkdir /tmp/i
  cd /tmp/i
  zcat /boot/initrd-KERNEL_VERSION |cpio -idv
  cat etc/mdadm.conf

Thanks.

(In reply to comment #1)
>   mdadm -Ds
>   so we can compare uuids.

ARRAY /dev/md/linux:0 metadata=1.0 name=linux:0 
  UUID=41b8971f:df6c3d81:40a999bc:490996f9
ARRAY /dev/md/linux:3 metadata=1.0 name=linux:3 
  UUID=3b988094:5c379c09:cb3773cc:a44c243c
ARRAY /dev/md/linux:4 metadata=1.0 name=linux:4 
  UUID=dfc46d0f:cf98c90a:163cbca9:c954a7c6
ARRAY /dev/md2 metadata=1.0 name=linux:2 
  UUID=caa75fa1:5e0a6fcf:c456a754:896617d0
ARRAY /dev/md/linux:1 metadata=1.0 name=linux:1 
  UUID=fa768d7e:b3eed134:3bf3c2ce:70ca362f

The UUIDs are the same as in /etc/mdadm.conf (unless I overlooked a minor difference).

>   zcat /boot/initrd-KERNEL_VERSION |cpio -idv
>   cat etc/mdadm.conf

ARRAY /dev/md2 metadata=1.0 name=linux:2 
  UUID=caa75fa1:5e0a6fcf:c456a754:896617d0

Looks like the initrd contains only the information for the / partition, not for my other /dev/md* arrays.

I just checked my backups - the initrd from openSUSE 11.4 also has only /dev/md2 in its mdadm.conf. The boot/51-md.sh script in the 11.4 and 12.1 initrd are exactly the same. However there are some differences in 
lib/udev/rules.d/64-md-raid.rules

Thanks.
I can see what is happening now.  I'll have to give a bit of thought to figure
how best to fix it.
In the mean time you could edit 64-md-raid.rules and remove (or comment out)
the line that mentions "--incremental" and then remake your initrd (mkinitrd).
Then the arrays should look right on the next boot.

Created attachment 454530 [details]
Replacement /lib/mkinitrd/scripts/setup-md.sh

Ok, I've had a think about this and tried some things out.

Please don't make the change to the udev/rules.d file - or reverse it if you have made it, and instead replace /lib/mkinitrd/scripts/setup-md.sh with the attached file.
The change is just this:
@@ -82,7 +82,7 @@
 
 if [ -n "$root_md" ] ; then
     need_mdadm=1
-    echo -n "" > $tmp_mnt/etc/mdadm.conf
+    echo "AUTO -all" > $tmp_mnt/etc/mdadm.conf
     for md in $md_devs; do
         eval echo -e \"\$md_conf_$md\" >> $tmp_mnt/etc/mdadm.conf
     done

It should cause the initrd environment to only try to assemble arrays listed in mdadm.conf.  Once boot completes the rest of the arrays will then be assembled based on the /etc/mdadm.conf in the root filesystem.

Please confirm that this works for you and I'll submit an update.

Thanks for the report.

(In reply to comment #4)
> Replacement /lib/mkinitrd/scripts/setup-md.sh
> Please confirm that this works for you and I'll submit an update.

etc/mdadm.conf in the initrd now has:

AUTO -all
ARRAY /dev/md2 metadata=1.0 name=linux:2 
  UUID=caa75fa1:5e0a6fcf:c456a754:896617d0

Unfortunately I still get /dev/md12* devices, so you'll need another fix...

Thanks for testing.
It seems that "AUTO -all" is broken in the latest mdadm :-(

I've fixed it and submitted an update - it should filter through the system in a couple of days.  I'm highly confident that this will really fix it.

I'll attach and RPM that I have build so you can test with that if you like.

Setting Needinfo for confirmation, either from this RPM or when an 'offical' one gets out.

Thanks,
NeilBrown

Created attachment 454797 [details]
new mdadm RPM for x86_64 with fix.

This is an autogenerated message for OBS integration:
This bug (721905) was mentioned in
https://build.opensuse.org/request/show/86854 Factory / mdadm

Tested with mdadm-3.2.2-3.1.x86_64 from Factory. Good news: I get the correct device names again :-)

Thanks for fixing this issue!

Thanks for the confirmation - and the original report.