2

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:
http://www.howtoforge.com/how-to-set-up-software-raid1-on-a-running-system-incl-grub2-configuration-debian-squeeze

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:

/usr/share/initramfs-tools/init

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

Improve this question

2 Answers 2

Reset to default
3

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:

# INITRDSTART:
#   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.
INITRDSTART='none'

I had to chage it to :

INITRDSTART='all'

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

Improve this answer
0

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.

Improve this answer
6
  • 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, 2012 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.
    – Jeff Ferland
    Mar 25, 2012 at 21:59
  • Isn't there problem that if /dev/sda fails your RAID 1 won't boot? Thanks.
    – Infragile
    Mar 26, 2012 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.
    – Jeff Ferland
    Mar 26, 2012 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, 2012 at 15:04

You must log in to answer this question.

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