I dealt with this issue recently and initially looked at it as a bug, but having explored it some more, I have come to the conclusion that it is not - it is by design, and for a purpose.
During early userspace when the initrd.img's /init shell script is running mdadm is triggered. It examines /etc/mdadm/mdadm.conf (in the initrd.img) for ARRAY entries and will assemble those, but it will also assemble other arrays it finds that are not defined in the conf file.
Since arrays defined using ARRAY usually have device numbers starting at 0, the dynamically discovered arrays are numbered starting at 127 to avoid them using the device number of MD devices defined and assembled later when Upstart has taken over.
With an entry in the root file-sytem's /etc/mdadm/mdadm.conf of, for example:
ARRAY /dev/md0 UUID=...
the update-intramfs hook scripts installed by mdadm will copy that into the initrd when it is built and the device will receive its correct designation.
I dealt with this issue recently and initially looked at it as a bug, but having explored it some more, I have come to the conclusion that it is not - it is by design, and for a purpose.
During early userspace when the initrd.img's /init shell script is running mdadm is triggered. It examines /etc/mdadm/ mdadm.conf (in the initrd.img) for ARRAY entries and will assemble those, but it will also assemble other arrays it finds that are not defined in the conf file.
Since arrays defined using ARRAY usually have device numbers starting at 0, the dynamically discovered arrays are numbered starting at 127 to avoid them using the device number of MD devices defined and assembled later when Upstart has taken over.
With an entry in the root file-sytem's /etc/mdadm/ mdadm.conf of, for example:
ARRAY /dev/md0 UUID=...
the update-intramfs hook scripts installed by mdadm will copy that into the initrd when it is built and the device will receive its correct designation.