Comment 11 for bug 576147

Same problem here with a strange /dev/md_d127 (AMD64, Ubuntu 10.10). I also used a name ("raid1"). It's of type raid1 with two devices. The md device is partitioned. Metadata version is 1.2.

Unsetting the name as described by Marcus Overhagen solved the problem. Actually the name was not removed but automatically replaced with "64". Not all steps described by Marcus Overhagen where necessary. Only the lines with "... --update=name ...", the ".../mkconf..." and the "update-initramfs..." were needed (the first --update=name command I executed in the emergency shell when booting the system, see below).

But there is something else wrong which might be the reason. The following steps where done before resetting the name:

After deactivating (commenting out the lines) in /lib/udev/rules.d/85-mdadm.rules (this prevents the array from being automatically incrementally assembled at boot time), the boot stopped and threw me into a shell (the root resides on the raid).

In the shell I tried to reproduce the commands normally automatically executed by udev (via the script 85-mdadm.rules):
mdadm --incremental /dev/sda1
mdadm --incremental /dev/sdb1

The first command succeeded. The second command didn't. It failed with a message similar (I cannot remember the exact name of the file) to: "cannot create /dev/md/d1, file exists"

It looks like the mdadm --incremental command twice tries to create the device file which, of course, the second time doesn't succeed. This leaves a half build array lying arround.

After resetting the name, the --incremental command works as expected.

The bug is quite severe, I think, because it can lead to an unbootable system (at least without manual intervention). Probably the easiest way to reduce the problem would be a big warning in the mdadm man page that non-numeric names can lead to problems (probably there are even more restrictions like the number range).