# HELP - how to start raid1 from initramfs SOLVED

## Moriah

How do I start a raid-1 array from my init script in my initramfs so that the array will start if at least any one drive is working?

This raid-1 array will hold my root filesystem, but is first encrypted with luks, then managed with lvm.

If all raid drives are working, this works, but if any raid drive is not present/working, then mdadm refuses to start the array.  

It is kind of stupid to boot from a raid-1 array for reliability and redundancy if all the drives must be working for the system to boot.

The actual boot drive is on a usb stick, but the root filesystem in a logical volume on the raid array.

Surely there is a way to make the array start even if all the specified drives are not present or working, otherwise what is the point?

I should mention that the drives participating in the raid-1 array are not partitioned; the entire device is a member of the array.  This is so that the full disk encryption is truley full disk, and not just full partition.  Because of this, the --auto option will not work.

I have experimented a bit, and the following command seems to work, but it will require that awk be in my initramfs:

```

livecd ~ # mdadm -Q /dev/sd[abc]

/dev/sda: is not an md array

/dev/sda: device 0 in 2 device undetected raid1 /dev/md0.  Use mdadm --examine for more detail.

/dev/sdb: is not an md array

/dev/sdb: device 1 in 2 device undetected raid1 /dev/.tmp.md0.  Use mdadm --examine for more detail.

/dev/sdc: is not an md array

livecd ~ # mdadm -Q /dev/sd[abc] | grep raid1

/dev/sda: device 0 in 2 device undetected raid1 /dev/.tmp.md0.  Use mdadm --examine for more detail.

/dev/sdb: device 1 in 2 device undetected raid1 /dev/.tmp.md0.  Use mdadm --examine for more detail.

livecd ~ # mdadm -Q /dev/sd[abc] | awk '/raid1/ { print substr($1,1,index($1,":")-1) }' -

/dev/sda

/dev/sdb

livecd ~ # mdadm -A /dev/md0 `mdadm -Q /dev/sd[abc] | awk '/raid1/ { print substr($1,1,index($1,":")-1) }' -`

mdadm: /dev/md0 has been started with 2 drives.

livecd ~ # 

```

Is there a simpler way that uses only options built into in mdadm?

----------

## jpc22

You probably aldready know that :

You can create a raid array with a missing drive and add it latter and you can still start this array in degraded mode.

You can also run without a disk while waiting for a replacement, but not without manual intervention and that may be fine , since they dont fail everyday, but your data will be gone if the last disk fails. You can manually degrade a raid array by removing a disk from it to do that. 

If you intend to remove disks often, its possible ,but again you will have to degrade your array and sync the disk when you put them back in latter, and i dont think it can be done on a running system, in addition to being long.

Add encryption over that and you double the nightmare if somethings fails when replacing/removing a disk manually or have any raid/encryption problems.

Maybe there is a way to do what you ask without manual interventions, but i have not heard of it yet. 

If you require drives to be removed on demand while having duplicated data for redundancy, a networked(localhost) clustered filesystem with offline support like coda/moosefs could do the trick, but they are not easy to implement.

----------

## Moriah

Actually, with a 3-way raid-1 mirror, you can fail a drive and remove it and still have redundancy.  You can keep running as long as you have at least one drive working.  The issue here is none of that.  The issue here is how to START an array at system boot time when not all drives are present or working.  This is a server.  It is remotely administered.  I receive an email when it is rebooted by cycling power on an ethernet controlled power strip.  I could be hundreds of miles away when this happens.  I will need to log into my kvm-over-ip to enter a luks passphrase to satisfy the encryption, but I will not be physically present to physically insert or remove any drives from the hot-swappable SATA backplane.  I just need a foolproof way to get the raid-1 to start as long as there is at least one working drive present.

I think my little script with mdadm and awk will do the trick.  I was concerned about having to put awk into my initramfs, but a little research shows me that awk is supported under busybox, which is already in my initramfs, so I think I have solved my own problem.  I will post again when I have verified this.

----------

## Moriah

I have indeed solved my own problem.    :Very Happy: 

The only modification was the addition of "--run" to the mdadm command.

For the record, here is my init file in my initramfs:

```

#!/bin/busybox sh

mount -t proc none /proc

#mdadm -A -f /dev/md0 /dev/sda /dev/sdb

mdadm -A --run /dev/md0 `mdadm -Q /dev/sd[abc] | awk '/raid1/ { print substr($1,1,index($1,":")-1) }' -` 

mount -t sysfs none /sys

echo /sbin/mdev > /proc/sys/kernel/hotplug

mdev -s

cryptsetup luksOpen /dev/md0 cryptoraid

lvm vgscan --mknodes

lvm vgchange -a y

mount /dev/mapper/gentoo-rootfs /mnt/root

umount /proc

umount /sys

exec switch_root /mnt/root /sbin/init

echo OOPS!

sleep 30

```

So this works.  It starts a RAID1 mirror using whatever drives it can find that are legitimate members of of /dev/md0.    :Cool: 

----------

## NeddySeagoon

Moriah,

I thought that was the default behaviour, so I've learned something too.

----------

## Moriah

Neddy:

I think it is, if you use --auto and have your raid-1 running on partitions with the correct partition type for linux raid, but I am running this raid-1 on bare drives with no partitioning, so the --auto method does not work.

----------

## Goverp

 *NeddySeagoon wrote:*   

> Moriah,
> 
> I thought that was the default behaviour, so I've learned something too.

 

I was surprised to find my RAID5 wouldn't start with one disk out (due to a read error marking the disk as bad), and needed --run to get it to start.

Then I had another I/O error and this time the array would start, without --run.

There may have been a kernel upgrade between the two events, or maybe mdadm has different degrees of badness of disks out.  The two events needed different handling to get the array working.  One event (sorry, I've forgotten which, probably the second) just required --re-add'ing the dodgy drive.  The other required me to re-assemble the array with just 3 of the 4 drives, and then --add the offender back in.

I have a suspicion there's a kernel issue lurking at the bottom here; as noted in another thread, I've had several infrequent read errors on different disks in my array, but on running the manufacturer's drive inspection tool everything checks out OK.  I've not had the problem since kernel 3..6, but it's a bit early to be sure that anything's changed.  The fact that the I/O errors started about November last year, and occur across different disks, one of which is 3 years older than the others, makes me suspect something other than the disks.  I replugged the cables, which didn't fix it; which I reckon leaves one of the motherboard, power supply and kernel as suspect.

----------

## Moriah

Interesting.  On a similiar note, I purchased a 3TB Seagate Barracuda 7200 RPM for my back-up server a week ago.  I go thru one of these every couple of months, as I archive them offsite.  I have used 1, 1.5, 2 and now 3 TB drives like this in a RAID-1 for many years.  Friday evening I shoved the new drive into a hot swappable sata backplane to run badblocks on it beforre placing it into service on the backup server, and it couldn't be recognized on the sata bus!  I pulled it and shoved it into a different slot.  Same thing.  So I stuffed it into a different machine, same thing.  Obviously, the drive was bad out of the box.  It is going back to the vendor today.  I have never had that happen before -- bad out of the box.     :Confused: 

----------

