it goes away next reboot. No idea what’s going on.

It’s called Udev.

The magic incantation: sudo dpkg-reconfigure mdadm

The really frustrating part is that there are a lot of people on the various forums who are offering solutions but none of them really address the underlying problem. Several suggest hacks to create the /dev/md0 device entries either manually with MAKEDEV or to get udev to do it using some undocumented (!) links.conf file. Others suggest hacks to the mdadm.conf file to tell it what raid arrays are configured (which should not be necessary because this information is stored in the filesystem superblocks anyway). So many answers, but all of them band-aids over the real underlying cause.

The way I understand it, it should work is as follows:

1. System starts up, early in the startup sequence it initialises udev and the filesystem
2. Certain filesystems are marked as raid-autodetect, which triggers the kernel to load the relevant module (md_mod I believe).
3. Later in the system boot sequence, mdadm-raid is invoked. This scans the partitions for raid-arrays previously created and “assembles” them. It also creates the /dev/md0 entries by communicating with udev.
4. The newly-created raid device is mounted in accordance with /etc/fstab.
5. The raid monitoring daemon is started.

I think what was happening in my case was that the kernel wasn’t set up somehow to trigger the md module to be loaded. This needs to be done in a special way because you normally need md to be compiled into the kernel. dpkg-reconfigure mdadm obviously takes care of it, and I’d like to know exactly how it does this. But maybe that’s something for another time.

Despite spending far too much time on this, I’m glad I’ve got a better understanding about it all, and that it seems to be working properly without hacking. Disappointed that the correct solution was so difficult to come across.

alastair@pierre:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb[0] sda1[1]
      244195904 blocks [2/1] [_U]
      [>....................]  recovery =  0.9% (2265920/244195904) finish=68.9min speed=58440K/sec

unused devices: <none>

Lovely. 68 mins a lot quicker than 11 hours.