Mdadm array fails to assemble on boot.

I spotted this error while installing lucid lynx and mdadm on another machine:

Setting up mdadm (2.6.7.1-1ubuntu15) ...
Generating array device nodes... /var/lib/dpkg/info/mdadm.postinst: 170: /dev/MAKEDEV: not found
failed.
Generating mdadm.conf... done.
 Removing any system startup links for /etc/init.d/mdadm-raid ...

Could this have something to do with the array not starting?

Here is the complete transcript of the install:

The following NEW packages will be installed:
  mdadm postfix
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,642kB of archives.
After this operation, 4,248kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://archive.ubuntu.com/ubuntu/ lucid/main mdadm 2.6.7.1-1ubuntu15 [239kB]
Get:2 http://archive.ubuntu.com/ubuntu/ lucid/main postfix 2.7.0-1 [1,403kB]
Fetched 1,642kB in 8s (200kB/s)
Preconfiguring packages ...
Selecting previously deselected package mdadm.
(Reading database ... 149165 files and directories currently installed.)
Unpacking mdadm (from .../mdadm_2.6.7.1-1ubuntu15_amd64.deb) ...
Selecting previously deselected package postfix.
Unpacking postfix (from .../postfix_2.7.0-1_amd64.deb) ...
Processing triggers for ureadahead ...
Processing triggers for doc-base ...
Processing 26 changed 1 added doc-base file(s)...
Registering documents with scrollkeeper...
Processing triggers for man-db ...
Processing triggers for ufw ...
Setting up mdadm (2.6.7.1-1ubuntu15) ...
Generating array device nodes... /var/lib/dpkg/info/mdadm.postinst: 170: /dev/MAKEDEV: not found
failed.
Generating mdadm.conf... done.
 Removing any system startup links for /etc/init.d/mdadm-raid ...
update-initramfs is disabled since running on read-only media
update-rc.d: warning: mdadm start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (S)
update-rc.d: warning: mdadm stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (0 6)
 * Starting MD monitoring service mdadm --monitor [ OK ]

Setting up postfix (2.7.0-1) ...
Adding group `postfix' (GID 123) ...
Done.
Adding system user `postfix' (UID 115) ...
Adding new user `postfix' (UID 115) with group `postfix' ...
Not creating home directory `/var/spool/postfix'.
Creating /etc/postfix/dynamicmaps.cf
Adding tcp map entry to /etc/postfix/dynamicmaps.cf
Adding group `postdrop' (GID 124) ...
Done.
setting myhostname: ubuntu
setting alias maps
setting alias database
mailname is not a fully qualified domain name. Not changing /etc/mailname.
setting destinations: ubuntu, localhost.localdomain, , localhost
setting relayhost:
setting mynetworks: 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
setting mailbox_size_limit: 0
setting recipient_delimiter: +
setting inet_interfaces: all
/etc/aliases does not exist, creating it.
WARNING: /etc/aliases exists, but does not have a root alias.

Postfix is now set up with a default configuration. If you need to make
changes, edit
/etc/postfix/main.cf (and others) as needed. To view Postfix configuration
values, see postconf(1).

After modifying main.cf, be sure to run '/etc/init.d/postfix reload'.
...

I'm experiencing something somewhat similar on a home server of ours. The four partitions (/, /boot. /home, /var) are all MD RAID1 arrays.

On a reboot yesterday morning, the MD array /boot was on failed to start. This morning, it was the /home array.

When I logged in this morning, /home was not mounted. The reason was that the MD array was down:

gavin@robin:/$ sudo mdadm --detail /dev/md3
/dev/md3:
        Version : 00.90
  Creation Time : Mon Sep 18 23:27:46 2006
     Raid Level : raid1
  Used Dev Size : 292439104 (278.89 GiB 299.46 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 3
    Persistence : Superblock is persistent

    Update Time : Thu May 6 23:43:34 2010
          State : active, Not Started
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 0019b5ec:1ad12c80:0df67ddf:f4706d12
         Events : 0.4177842

    Number Major Minor RaidDevice State
       0 8 7 0 active sync /dev/sda7
       1 8 23 1 active sync /dev/sdb7

I then ran:

gavin@robin:/$ sudo mdadm --stop /dev/md3
mdadm: stopped /dev/md3
gavin@robin:/$ sudo mdadm --assemble /dev/md3
mdadm: /dev/md3 has been started with 2 drives.

mounted the drive and all was well. However, there definitely seems to be some problem with the MD raid arrays.

Any suggestions for what to look at. I found this bug via this thread which seems to have some more people seeing similar issues:

http://ubuntuforums.org/showthread.php?p=9240332

Gavin

This might be relevant too

http://ubuntuforums.org/showthread.php?p=9171517

Following thread is related to the problem, but available in german language only: http://forum.ubuntuusers.de/topic/raid5-mounten-aber-wie/

I am also seeing this upon update to mdadm_2.6.7.1-1ubuntu15 on a mythbuntu box. Luckily I can just assemble and mount the array manually afterwards, it just does not automatically do it upon boot.

This would probably be a showstopper for anyone brave enough to have setup their root partition on a RAID array!

Found the line it was talking about in /var/lib/dpkg/info/mdadm.postinst

---------------------------------------SNIP---------------------------------------
    if [ ! -f /proc/mdstat ] && [ -x $(command -v modprobe 2>/dev/null) ]; then
      modprobe -k md >/dev/null 2>&1 || :
    fi
    if [ ! -f /proc/mdstat ]; then
      echo 'W: mdadm: failed to load MD subsystem.' >&2
    fi

    if [ ! -e /dev/md15 ] \
      && [ ! -e /dev/.static/dev/md15 ] \
      && [ ! -e /dev/.devfsd ]; then

        echo -n 'Generating array device nodes... ' >&2
        cd /dev
        if /dev/MAKEDEV md >&2 >/dev/null; then
          echo 'done.' >&2
        else
          echo 'failed.' >&2
        fi
    fi
---------------------------------------SNIP---------------------------------------

I haven't looked further into what that script really should be doing there however.

Looked into this more today and found that for some reason my array is not being detected and assembled correctly after a reboot.

I've got a RAID 5 with 4 disks:
/dev/sdb1
/dev/sdc1
/dev/sdd1
/dev/sde1

Here's what I've accomplished so far:

1) I removed /dev/sde1 using "sudo mdadm /dev/md0 --fail /dev/sde1 --remove /dev/sde1"
2) I zeroed it's superblock using "sudo mdadm --zero-superblock /dev/sde1"
3) I zeroed the entire disk with "sudo dd if=/dev/zero of=/dev/sde bs=1M"
4) I created a new msdos partition table and added 1 partition using the full size of the disk with gparted.
5) I reformatted the partition with "sudo mkfs.xfs -f -b size=4096 -d sunit=128,swidth=384 -L mythtv /dev/sde"
6) Finally, I added the disk back into the raid array using "sudo mdadm /dev/md0 --add /dev/sde1"

After rebuilding the array on all 4 disks, everything was working. I could unmount the partition, stop /dev/md0, and then restart it by doing:
sudo umount /media/terabyte
sudo mdadm --stop /dev/md0
sudo mdadm --assemble --scan

This worked fine before a reboot. After rebooting just now, it failed to bring the array up, giving the familiar error:
"the disk for/mnt/md0 is not ready yet or not present. Continue to wait; or Press S to skip mount or M for manual recovery."

I logged in and tried to assemble the array, but got this:
-------------------------------------------------------------------------
trinitronx@saturn:~$ sudo mdadm --assemble --scan -v
mdadm: looking for devices for further assembly
mdadm: cannot open device /dev/sdd1: Device or resource busy
mdadm: cannot open device /dev/sdd: Device or resource busy
mdadm: no recogniseable superblock on /dev/sde
mdadm: cannot open device /dev/sdc1: Device or resource busy
mdadm: cannot open device /dev/sdc: Device or resource busy
mdadm: cannot open device /dev/sdb1: Device or resource busy
mdadm: cannot open device /dev/sdb: Device or resource busy
mdadm: cannot open device /dev/sda6: Device or resource busy
mdadm: cannot open device /dev/sda5: Device or resource busy
mdadm: no recogniseable superblock on /dev/sda2
mdadm: cannot open device /dev/sda1: Device or resource busy
mdadm: cannot open device /dev/sda: Device or resource busy
mdadm: No arrays found in config file or automatically

trinitronx@saturn:~$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : inactive sdb1[0](S) sdc1[1](S) sdd1[2](S)
      2197715712 blocks

unused devices: <none>

trinitronx@saturn:~$ sudo mdadm --detail /dev/md0
mdadm: md device /dev/md0 does not appear to be active.
-------------------------------------------------------------------------

Now, examining the superblocks on the rest of the disks shows that /dev/sde1 is missing!!!
Trying to examine /dev/sde1 says that the device does not exist!!

I've repeated this multiple times and cannot figure out what it's problem is.
Here is the superblock information from /dev/sde1 and the first 3 disks:

-------------------------------------------------------------------------
trinitronx@saturn:~$ sudo mdadm --examine /dev/sde1
mdadm: cannot open /dev/sde1: No such file or directory

trinitronx@saturn:~$ sudo mdadm...

Attached: output of examining all disk partitions with fdisk -l

Attached: kernel message log

GParted just gave me troubles reformatting the drive again. Here are the details of that.

Now that I tried to create a new partition table and repartition /dev/sde, mdadm is trying to use it strangely as a second array!! wtf?
GParted failed to repartition it a second time, and now this:

trinitronx@saturn:/media$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md_d0 : inactive sde1[3](S)
      732571904 blocks

md0 : inactive sdb1[0](S) sdc1[1](S) sdd1[2](S)
      2197715712 blocks

unused devices: <none>

Rebuilding my RAID for the 5th time now. Here's the complete shell session, so in case I'm doing something wrong, PLEASE point it out! Let's hope it works this time!

.... And here we go.....

trinitronx@saturn:/media$ sudo fdisk -l /dev/sde
Disk /dev/sde: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sde doesn't contain a valid partition table

trinitronx@saturn:/media$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md_d0 : inactive sde1[3](S)
      732571904 blocks

md0 : inactive sdb1[0](S) sdc1[1](S) sdd1[2](S)
      2197715712 blocks

unused devices: <none>
trinitronx@saturn:/media$ sudo mdadm --stop /dev/md_d0
[sudo] password for trinitronx:
mdadm: stopped /dev/md_d0
trinitronx@saturn:/media$ sudo mdadm --examine /dev/md_d0
mdadm: cannot open /dev/md_d0: No such file or directory
trinitronx@saturn:/media$ sudo mdadm --examine /dev/sde
mdadm: No md superblock detected on /dev/sde.
trinitronx@saturn:/media$ sudo mdadm --examine /dev/sde1
/dev/sde1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 7a0e5ba8:669595fc:852484a6:e390a598 (local to host saturn)
  Creation Time : Fri Jan 9 03:40:39 2009
     Raid Level : raid5
  Used Dev Size : 732571904 (698.64 GiB 750.15 GB)
     Array Size : 2197715712 (2095.91 GiB 2250.46 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Sun May 16 22:13:13 2010
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : b38b3b34 - correct
         Events : 122066

         Layout : left-symmetric
     Chunk Size : 64K

      Number Major Minor RaidDevice State
this 3 8 65 3 active sync /dev/sde1

   0 0 8 17 0 active sync /dev/sdb1
   1 1 8 33 1 active sync /dev/sdc1
   2 2 8 49 2 active sync /dev/sdd1
   3 3 8 65 3 active sync /dev/sde1
trinitronx@saturn:/media$ sudo mdadm --zero-superblock /dev/sde1
trinitronx@saturn:/media$ sudo mdadm --examine /dev/sde1
mdadm: No md superblock detected on /dev/sde1.
trinitronx@saturn:/media$ sudo mdadm --zero-superblock /dev/sde
mdadm: Unrecognised md component device - /dev/sde

-------------------------------------------------------------------------------------------------
####### HERE'S WHERE I DELETED OLD PARTITION, ADDED NEW TABLE, AND REFORMATTED IN GPARTED #######
-------------------------------------------------------------------------------------------------

trinitronx@saturn:/media$ sudo fdisk -l /dev/sde

Disk /dev/sde: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0008b84d

   Device Boot Start ...

Here is the successful output of GParted formatting /dev/sde1 before my rebuild #5.

Beware of old superblocks, getting available again when (re-)creating partitions. Superblocks stay on the disks if you don't "mdadm --zero-superblock" the partition, prior to deleting the partition from the partition table.

Since we have to consider mdadm/raid as not maintained in ubuntu, maybe check other bug reports to see if their workarounds may help for this case.

ok, finished rebuilding it and ran "sudo mdadm --examine" on every device and partition. The info looks correct for:
/dev/sdb1
/dev/sdc1
/dev/sdd1
/dev/sde1

It reports "mdadm: No md superblock detected" for:

/dev/md0
/dev/sdb
/dev/sdc
/dev/sdd
/dev/sde

So hopefully this means that no superblock is on the devices themselves, and only the partitions. (I think I must have made the mistake of adding /dev/sde rather than /dev/sde1 the very first time, which is probably what caused all this mess).

Rebuilt again, and noticed an update for the mountall package too (not sure if this was related).

Seems everything is being brought up fine now after a reboot. I just hope it stays that way

Today it failed to mount on boot once again. I pressed "S" to skip mounting, and upon trying to mount it manually, I get:

trinitronx@saturn:~$ sudo mount /media/terabyte
mount: /dev/md0: can't read superblock
trinitronx@saturn:~$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md_d0 : inactive sda1[0](S)
      732571904 blocks

md0 : inactive sdb1[1](S) sdc1[2](S) sdd1[3](S)
      2197715712 blocks

unused devices: <none>

.....Ok... so now it's putting one of my drives on md_d0 again??? Why?

Apparently ubuntu is bringing up the drives in the WRONG ORDER! All drives [a-d] are now 1 letter incremented in the alphabet. (ie: ubuntu thinks sdb1 should be called sda1, sdc1 should be called sdb1, etc...) I'm not sure which drive it thinks is sde now, because it says there's no superblock on it.

How can I fix it's mistake?

Debug info below:
-----------------------------------------------------------

trinitronx@saturn:~$ sudo mdadm --detail /dev/md0
mdadm: md device /dev/md0 does not appear to be active.
trinitronx@saturn:~$ sudo mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.
trinitronx@saturn:~$ sudo mdadm --examine /dev/sda1
/dev/sda1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 7a0e5ba8:669595fc:852484a6:e390a598 (local to host saturn)
  Creation Time : Fri Jan 9 03:40:39 2009
     Raid Level : raid5
  Used Dev Size : 732571904 (698.64 GiB 750.15 GB)
     Array Size : 2197715712 (2095.91 GiB 2250.46 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Thu Jul 1 00:34:29 2010
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : b3c7801c - correct
         Events : 148755

         Layout : left-symmetric
     Chunk Size : 64K

      Number Major Minor RaidDevice State
this 0 8 17 0 active sync /dev/sdb1

   0 0 8 17 0 active sync /dev/sdb1
   1 1 8 33 1 active sync /dev/sdc1
   2 2 8 49 2 active sync /dev/sdd1
   3 3 8 65 3 active sync /dev/sde1
trinitronx@saturn:~$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 7a0e5ba8:669595fc:852484a6:e390a598 (local to host saturn)
  Creation Time : Fri Jan 9 03:40:39 2009
     Raid Level : raid5
  Used Dev Size : 732571904 (698.64 GiB 750.15 GB)
     Array Size : 2197715712 (2095.91 GiB 2250.46 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Thu Jul 1 00:34:29 2010
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : b3c7802e - correct
         Events : 148755

         Layout : left-symmetric
     Chunk Size : 64K

      Number Major Minor RaidDevice State
this 1 8 33 1 active sync /dev/sdc1

   0 0 8 17 0 active sync /dev/sdb1
   1 1 8 33 1 active sy...

Actually, to solve the problem for me I copied all the data to another hard disk. Then cleared all the md array information from the 3 drives. After that created a new array and since then it assembles correct at boot times.
It seems that the newer md-version are somehow incompatible with arrays created wit some former versions of itself. My array was existing for several years when this issue occours.

... and i changed all the information in mdadm.conf to uuids instead of using device names ...

md_dx stuff: Bug #551719 Bug #469574, Bug #532960, ...
They have workarounds and even some fixes in stable upstream for years but who cares.

I got the same problem.

I've setup a two-disks raid1 with palimpsest.
at boot i get the same message "the disk for /raid1 is not ready yet or not present. Continue to wait; or Press S to skip mount or M for manual recovery". press S and go to gnome.
opening palimpsest disk manager, my raid seems to be not partitioned and unmountable.
But if I deactivate and reactivate the raid, it works perfectly and now is mountable.

My RAID array still does not come up reliably upon every reboot. It
seems that if I reboot once after the "not ready or present" message,
it usually will come up fine the second time. I've been leaving my
system on for a while to avoid having to deal with this however.

Right now, I still need to find some space to store almost 2TB of data
to rebuild the array fully as was suggested earlier in this thread.

I started getting an error on the ubuntusplash screen when my PATA md array wouldnt mount.
(S)kip mounting or M for manual recovery
funnily enough goingin into manual mode and looking at dmesg didnt throw up any errors

/proc/mdstat showed the array as inactive partial and also named it /dev/md_p1 whe it had always been known as /dev/md3 (it was always an unpartitioned whole disk md component

Skipping mounting I was always able to get the array up via "disk utilty" by stopping the array, restarting it and then issuing a sudo mount -a (by specified uuid in fsatb .for affected array)

issuing a dpkg-reconfigure mdadm seemed to work through 2 reboots

but then the system after the next reboot mounted one of the component disks on the mountpoint where the array is
(dev/sdc1 instead of /dev/md3p1)

unmounted did dpkg-reconfigure again rebooted and got "skip"

mdstat showed the array as up, but umounted

substituted the dev path for the uuid in fstab and its currently rebooted ok..

Is there a timing issue somewhere?

It does seem like there is a timing issue here. Some sort of race
condition causes the array to be assembled incorrectly, or not at all
perhaps. My gut tells me it's something to do with the new upstart
system that ubuntu moved to, because it never happened before they
switched.

I still haven't gotten around to rebuilding my entire array as
suggested... I've currently got quite a bit of data on the array that
I don't really want to have to spend the time to save elsewhere and
copy back.

I've been rebooting whenever it happens as a workaround, but I'm still
hoping someone can help out with finding a full solution.

On Mon, Sep 27, 2010 at 9:40 PM, Bob Blanchett
<email address hidden> wrote:
> I  started getting  an error on the ubuntusplash screen  when my PATA md array wouldnt mount.
> (S)kip mounting or M for manual recovery
> funnily enough goingin into manual mode and  looking at dmesg didnt throw up any errors
>
> /proc/mdstat showed the array as inactive partial and also named it
> /dev/md_p1  whe it had always been known as /dev/md3 (it was always an
> unpartitioned  whole disk md component
>
> Skipping mounting I was always able to get the array up via "disk
> utilty"  by stopping the array, restarting it  and then issuing a sudo
> mount -a (by specified uuid in fsatb .for affected array)
>
> issuing a dpkg-reconfigure mdadm seemed to work through 2 reboots
>
> but then the system after the next reboot  mounted one of the component disks on the mountpoint where the array is
> (dev/sdc1 instead of /dev/md3p1)
>
> unmounted did dpkg-reconfigure again rebooted and got "skip"
>
> mdstat showed the array as up, but umounted
>
> substituted the dev path for the uuid in fstab and its currently
> rebooted ok..
>
> Is there a timing issue somewhere?
>
> --
> Mdadm array fails to assemble on boot.
> https://bugs.launchpad.net/bugs/573477
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Does anyone know if this bug still exists in 10.10?
I should consider a dist-upgrade, even if 10.10 is not LTS...

I know that this bug doesnt exist with 10.04.1 with an array constructed in 10.04.1 using mdadm.

I gave up on this bug as it wasnt a show stopper (server was rarely rebooted), but have made some observations during the new build that might shed some light on this. I used the palimpest disk utility to construct my array and Im 99% sure I did previously too, though this time I noticed some quirks, like the utility being unable to expand an array built by mdadm or the disk utility (saying the device wasnt big enough to add, but it is identical to the other drives.), mdadm unable to assesmble a array made by the disk utility while the disk utility was able to and on boot the disk utility has the array as started but degraded (stopping/starting the array fixes this). The array would work store data and mount without issue if constructed and stopped/started using the disk utility.

This got me thinking that maybe this was somehow related to the issues I was having previously. Anyone else assemble their arrays with the disk utility? Just putting it out there....

@ md0 is not ready yet or not present. Continue to wait; or Press S to skip mount or M for manual recovery'

I have this bug in 10.10 and it's really anoying me. I wonder if there is ever going to be a fix for this problem.

I followed this thread and solved my problem: http://ubuntuforums.org/showthread.php?t=1077167

Hey, my RAID1 has been mounting on boot. I can now have fstab mount my partitions when my computer goes on!

I'm running 11.04.

Can anyone else confirm that this has been fixed?

I could not get a raid10 to automount at boot with 11.04. After days of frustration I gave up.

I'm sorry to hear that. I'll set it to confirmed, though, as it shouldn't be on New.

Same problem here. Solved by adding to /etc/mdadm/mdadm.conf this line:
ARRAY /dev/md1 metadata=1.2 UUID=someuuid name=somename:0

/dev/md1 may be different for you. It' may be md/1, md1 or something.
I get someuuid by using blkid utility.
somename from mdadm --detail /dev/md1

To get information from dlkid and mdadm --detail you need to stop array first
mdadm --stop /dev/md1
and then assemble it again:
sudo mdadm --assemble /dev/md1 /dev/sdX1 /dev/sdY1
After that you will able to get UUID and array name.

There's apparently a race condition, and it appears to have been in (and still is, as of 12.04 LTS) deep in Ubuntu for many versions. It just bit me tonight...and for the last time. Had similar insurmountable problems with 10.04 LTS, 6.06 LTS, too. I guess it's more important for the Ubu coders to race around doing cloud coding and changing tectonic parts (like Upstart) that really shouldn't be screwed with, eh? My only solution was to revert to Debian 6.0.5. Ubuntu, in my now long suffering experience, is to Debian as Fedora is to RedHat. Beware.

https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/872220?comments=all

Thank you for your bug report. To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.

Kindly refrain from clogging up various bug reports with threats about leaving Ubuntu, michael. Your input is valuable if you can help solve the solution and is useless with empty rants.

The problem exists in the initramfs boot scripts. They do not fire --assemble. To fix this, I removed the package hook and scripts and replaced them with those provided in the debian package. The debian scripts are much better and not sure why ubuntu does not use those by default anyway.

here is a quick fix - assumes mdadm is config and working

#Remove ubuntu package scripts:
rm /usr/share/initramfs-tools/hooks/mdadm
rm /usr/share/initramfs-tools/scripts/mdadm-functions
rm /usr/share/initramfs-tools/scripts/init-premount/mdadm
rm /usr/share/initramfs-tools/scripts/local-premount/mdadm

#Extract / cp files from deb:
cp mdadm_3.2.5-3_amd64/usr/share/initramfs-tools/hooks/mdam /usr/share/initramfs-tools/hooks/mdadm
cp mdadm_3.2.5-3_amd64/usr/share/initramfs-tools/scripts/local-top/mdadm /usr/share/initramfs-tools/scripts/local-top/mdadm

#Then update initramfs
update-initramfs -vck all