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
  • 1
    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

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

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 ?


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

The credit goes here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.