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?

8 Answers 8


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

# 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)

  • 8
    I would maybe add: you should also update your initramfs with update-initramfs -u
    – Pablo M
    Oct 19, 2012 at 3:08
  • 2
    mdadm --detail --scan does not print anything on my system, although I know for sure that I have two partitions that are part of a raid0 (mirror). Any general advice on this is welcome. Mar 14, 2014 at 13:59
  • 1
    @LennartRolland - try mdadm -Es instead.
    – slm
    Jan 9, 2015 at 1:00
  • this did not work for me, I had to do grub-install /dev/sda to make it work (replace sda for anything appropriate for you)
    – gorn
    Apr 25, 2016 at 23:17
  • Alternatively you can just use the kernel option: md.auto=1 ... I haven't actually tested this thoroughly but supposedly it detects them and assembles them (or at least tries to do so). But then kernel.org/doc/html/v4.15/admin-guide/md.html is a bit ambiguous on that: When md is compiled into the kernel (not as module), partitions of type 0xfd are scanned and automatically assembled into RAID arrays. [...] As of kernel 2.6.9, only drives with a type 0 superblock can be autodetected and run at boot time. And it doesn't refer to md.auto (or whatever it was) so I'm not sure now.
    – Pryftan
    Oct 14, 2019 at 18:39

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.

  • Same "problem" here. Not sure if it is a problem, though.. Nov 29, 2015 at 0:06
  • On reboot my device had changed from /dev/md0 to /dev/md127
    – Soth
    May 25, 2021 at 6:14
  • @Soth: You probably forgot to run sudo update-initramfs -u before rebooting.
    – DanB
    Oct 27 at 0:20

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


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!


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

#   should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
#   during boot?

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

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.

  • I wrote thi because Linker3000's answer did not work for me.
    – gorn
    May 4, 2015 at 2:51

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.

  • Note that uname -r in the above is supposed to be in back-ticks but I can't figure out how to escape them so they're printed here...
    – Rodney
    May 26, 2015 at 14:12
  • Which version of raspbian was this? I had it working fine on Wheezy, but ugrading to Jessie broke the assemble on boot.
    – nwaltham
    Mar 15, 2016 at 20:48

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

The credit goes here.


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 ?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .