Hello I have very strange problem creating swraid on Debian Squeeze Linux. I started creating RAID1 from existing standard instalation of Debian on single drive. So I bought new drive and started following this tutorial:

Everything went fine, i created initial raid from new drive. Then I successfully booted this new drive and added my old drive to this array. Old drive sucessfully synchronized in to raid. And after all setup I was ready for last reboot to my new Raid1 array.
But suddenly the drive array want boot. Grub takes very long to start (printing some error messages about fd0 read error). When I choose from menu debian starts loading very slowly and stops with message that md0 wasn't found. In grub shell I found that there is only /dev/md, no /dev/md0 or /dev/md1.

After many hours of trials i finnaly managed to get Raid working. Using ugky hack.

I had to add:

mdadm -A --auto=md /dev/md0

On the right place in:


and rebuild initrd.img of my kernel

This command starts my Raid and creates /dev/md0 and /dev/md1.

But its quiet ugly hack, and I dont think its very stable. Also it can break in future with some update. So my question is why i need this change in init script? Is there something bad with my array? How to fix it?

Thanks for all hints. I'm quiet desperade now it took my all night (12 hours). to


Ok, so I found solution of my problem booting from mdadm Raid1. I'm quite ashamed that it took me so much time to figure this out, because it's a quite simple mistake.

In /etc/default/mdadm there was section:

#   list of arrays (or 'all') to start automatically when the initial ramdisk
#   loads. This list *must* include the array holding your root filesystem. Use
#   'none' to prevent any array from being started from the initial ramdisk.

I had to chage it to :


And then I could remove my custom command from /usr/share/initramfs-tools/init and linux boots without problems from my raid 1.


Nothing's wrong with your array, and it's common to alter an initrd image to have extra drivers or other adaptations to accomodate the boot process.

The other trick you can use is that when you start, most init processes mount the root partition read-only, so you can point it at /dev/sda1 or whatever designator ties to one of the appropriate partitions for booting, but when you pivot your root, point it at the mdadm device. That's how I handled back when I had a software raided set of drives.

  • Thanks Jeff for your answer, it brought me back some optimism. Can you provide some example of your alternative solution? I'm not sure ho it can be donoe.
    – Infragile
    Mar 25 '12 at 13:00
  • Point your root that is passed to the kernel in grub and the grub configuration to the raw /dev/sda* (or equivalent) partitions that apply. Point the root in your /etc/fstab to the mdadm copy. Make sure that your initial mounting by the kernel includes the "read-only" option. That said, if your initrd setup is working, I would consider that the preferred method. Mar 25 '12 at 21:59
  • Isn't there problem that if /dev/sda fails your RAID 1 won't boot? Thanks.
    – Infragile
    Mar 26 '12 at 8:10
  • Well, you do lose automatic recovery, but then you just repoint to sdb or bootdisk it. The BIOS has to point to one drive anyway... downside of the software RAID and why you /boot can't be MDADM raid 5. Mar 26 '12 at 16:12
  • I thought that as far as 1 disk is OK I can still boot my system, and that it doesn't matter which drive failed. This is not true? I think that I tried to disconnect one or the other drive and system booted ok, but I'm not sure.
    – Infragile
    Mar 27 '12 at 15:04

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.