How can I make mdadm auto-assemble RAID after each boot?

Question

I successfully created a RAID (mirroring) by utilizing mdadm. However, I must run the following commands after each boot:

mdadm --stop --scan // to stop /dev/md127 - I don't know where the number 127 even comes from
mdadm --assemble --scan // to start /dev/md0

What am I doing wrong/why do I need to run these commands at boot? What is the right way to auto-start RAID with each (re)boot?

Answer 1

NB: You either need to be logged in as root, or use sudo to do all this...

• Use your favourite editor to create or edit /etc/mdadm/mdadm.conf file as follows:

If the file does not even exist, paste the following into the new, empty file:

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

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 <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays

• Save the file

• Run the following command to add a reference to your array config at the end of the file:

  mdadm --detail --scan >> /etc/mdadm/mdadm.conf

This should add a line like the following to the end of mdadm.conf:

ARRAY /dev/md0 level=raid5 num-devices=3 metadata=00.90 UUID=a44a52e4:0211e47f:f15bce44:817d167c

If the mdadm command has added any other stuff above the ARRAY line, remove it. For example, on one of my machines, the command returns 'mdadm: metadata format 00.90 unknown, ignored.' before the ARRAY line.

Your array should now auto-build on boot and thus you can add an entry to /etc/fstab to mount it (if it's not already there)

Answer 2

I realize this is an older question, but I had a frustrating time with this on the 32-bit version of Ubuntu Server 12.04.

Running mdadm --detail --scan >> /etc/mdadm/mdadm.conf appended the line

ARRAY /dev/md0 metadata=1.2 name=ubuntu:0 UUID=a8a570c6:96f61865:05abe131:5c2e2f7e

After a reboot I could never see /dev/md0. Running the mdadm --detail --scan again (without putting the result in a file) I would see

ARRAY /dev/md/ubuntu:0 metadata=1.2 name=ubuntu:0 UUID=a8a570c6:96f61865:05abe131:5c2e2f7e

and manually mounting /dev/md/ubuntu:0 would work. In the end, that was what I put in the fstab file too.

I am not sure what I got wrong, if this is how it works in Ubuntu 12.04, or if this is a bad practice. Just wanted to share what worked for me.

Answer 3

I had this problem on my Raspberry Pi 2 running Raspbian GNU/Linux 8 (jessie). I had a RAID array on /dev/sda1 and /dev/sdb1 which failed to assemble at boot. I had in my /etc/mdadm/mdadm.conf file the entry

ARRAY /dev/md/0  metadata=1.2 UUID=53454954:4044eb66:9169d1ed:40905643 name=raspberrypi:0 

(your numbers will be different; see other answers on how to get this.)

I had in my /etc/fstab file the entry

/dev/md0        /data           ext4    defaults          0       0

(and of course /data indeed existed)

Like the OP, I could assemble and mount the RAID array by hand after boot, but I could not get it to happen automatically during boot despite apparently correctly setting it up.

I was able to solve the problem as follows. I investigated the script at /etc/init.d/mdadm-raid and inserted a line of debug code

ls /dev > /home/pi/devices.txt

Rebooting and checking this file I learned that devices /dev/sda and /dev/sdb existed at the time the mdadm-raid initialization happened, but the partitions /dev/sda1 and /dev/sdb1 were missing. I edited the /etc/init.d/mdadm-raid file and inserted the line

partprobe

after the header (i.e. after the ### END INIT INFO but before the script begins). This caused the partitions to be detected and so the mdadm-raid script was able to assemble the RAID array, resolving the problem. Hope this helps someone!

Answer 4

On Debian wheezy one more step is required: in /etc/default/mdadm set autostart from false to true

#AUTOSTART:
#   should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
#   during boot?
AUTOSTART=true

Also I had to use mdadm -Es >>/etc/mdadm/mdadm.conf instead of the --scan option, as that did not work for me.

Answer 5

sudo mdadm -Es >> /etc/mdadm/mdadm.conf

Now edit lines added to /etc/mdadm/mdadm.conf in the following way. Delete everything, but the basic parts. It should look like

ARRAY /dev/md5 UUID=031cea92:50a7a28c:6b077fe7:8817092a
ARRAY /dev/md6 UUID=53454954:4044eb66:9169d1ed:40905643

Note: you can choose X in mdX to your convenience.

Now reboot

sudo update-initramfs -u
sudo reboot

EDIT: command corrected.

Answer 6

I tried with

mdadm --create /dev/md/abcdef ...

I see the softlink /dev/md/abcdef persisting on reboots and if need be access the device through soft link.

Is it a acceptable solution ?

Answer 7

Having the Raspberry Pi 3, adding the rootdelay=5 to the /boot/cmdline.txt solved this problem for me.

The credit goes here.

Answer 8

I have been fighting with this on Raspbian using a couple of external USB HDD's on a Raspberry Pi. I had to mess with the start order of services to make sure that mdadm-raid started after the USB drives were recognised by udev but before checkfs.sh (which checks filesystems at boot time). If mdadm-raid started too early, the drives were not available and therefore the array was not assembled. That meant that fsck subsequently failed and the boot process dropped out to a maintenance prompt (because the raid array is required for other services).

Modifying boot dependencies to start mdadm-raid after checkroot.sh but before checkfs.sh and running update-rc.d mdadm-raid defaults, followed by update-initramfs -uv -k `uname -r` (note backticks around uname) fixed it (finally). For me, anyway, YMMV.