So even after configuring my /etc/mdadm/mdadm.conf (im using ubuntu, its /etc/mdadm.conf if on deb), for some reason, at system boot, I was still getting a device name of /dev/md127. As per the ubuntu forums, this is a common problem with a change made in newer kernels.

Here is my mdadm.conf:

# mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default (built-in), scan all partitions (/proc/partitions) and all # containers for MD superblocks. alternatively, specify devices to scan, using # wildcards if desired. #DEVICE partitions # auto-create devices with Debian standard permissions #CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system #HOMEHOST # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays # Was for the original 1.5TB array ARRAY /dev/md0 UUID=91f3fbda:3e3d14b6:3bb9aea0:9769bb89 # This file was auto-generated on Thu, 14 Nov 2013 22:25:46 -0500 # by mkconf $Id$

I verified that stopping the array and starting it using “mdadm –assemble –scan” works. Then, I ran the following as recommend:

sudo update-initramfs -u

which regenerates your initrd. reboot and you should get the device mappings you desire!

One xtra tip…which I recommend because I like my array to be available as much as possible at boot:

In your /etc/rc.local, something like:

# We try to mount the array (which has already been assembled by mdadm) and if we can’t, probably need to replay the journal from a bad shutdown # Note the the main array in this system should always be called md0 [ -b /dev/md0 ] && mount /dev/md0 /raid || fsck.ext4 /dev/md0 && mount /dev/md0 /raid

This is really nice when you are doing a lot of unclean shutdowns etc….I mean I don’t recommend them and you should probably comment this out if you are but sometimes things happen….This ensures your array stays clean and mounts just fine!:)

Mario Loria is a builder of diverse infrastructure with modern workloads on both bare-metal and cloud platforms. He's traversed roles in system administration, network engineering, and DevOps. You can learn more about him here.