Ubuntu

Best way to add RAID1 to existing Feisty Installed system

Asked by John Williams

I just migrated my edgy to Feisty on a new machine with a 160gb SATA drive. Things are running well...

I have 1 disk, with /dev/sda1 containing the system and /dev/sda6 with /home.

These SATA disks are real cheap so I have decided to get another to run as a mirror.

What is the best way to add the disk and configure RAID1 using mdadm? Do I have to backup the system, create the array then restore the data or is there a better way?

is md working well on Feisty?

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
John Williams
Solved:
Last query:
Last reply:

This question was reopened

Revision history for this message
Ralph Janke (txwikinger) said : 		#1

Hier is a howto that might help:

http://www.ubuntu-in.org/wiki/SATA_RAID_Howto

Revision history for this message
Ralph Janke (txwikinger) said : 		#2

Here are some more:

https://help.ubuntu.com/community/FakeRaidHowto

http://www.howtoforge.com/ubuntu_dapper_raid_system

Hope they help with your question

Revision history for this message
John Williams (jswillms) said : 		#3

All of these methods use dmraid in combination with MB RAID support. My MB has no support for Raid so I need info on using md based software raid. Thx for the pointers, anyway.

Anyone else?

Revision history for this message
Benjamin Hodgetts (enverex) said : 		#4

Just thought I'd throw this in, but DO NOT USE ONBOARD FAKERAID. It's generally not very reliable, hard to recover from and slower than pure Linux software raid. Just something to keep in mind. You want to look up mdraid rather than dmraid.

Revision history for this message
John Williams (jswillms) said : 		#5

Thanks Ben...

Still loooking for md raid info...

Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) said : 		#6

I agree with the "dont use fakeraid" point. Here's the problems a good friend of mine had it:-

http://www.smop.co.uk/blog/index.php/2007/04/01/fakeraid-avoid/

Revision history for this message
John Williams (jswillms) said : 		#7

Not a problem for me, no fakeraid on my mb.

Still looking for input on md and mdadm raid...

Revision history for this message
Ralph Janke (txwikinger) said : 		#8

How about this?

http://www.linuxdevcenter.com/lpt/a/2776

I hope this helps

Revision history for this message
John Williams (jswillms) said : 		#9

This is what I was looking for...will post when I get thru the migration...

http://xtronics.com/reference/SATA-RAID-debian-for-2.6.html

Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) said : 		#10

http://www.debian-administration.org/articles/238 is a great article about converting to software RAID.

Revision history for this message
John Williams (jswillms) said : 		#11

None of these ideas have worked. I did the procedure but cannot get thru the reboot of the degraded raid array. It fails in the ram disk boot phase. I tried remaking the initfs but no joy...

Fortunately the procedure did not destroy non-raid booting, so I am still running. I am giving up on this and will reinstall from the alternate disk when feisty goes gold. Got another bug to work on till then...

Revision history for this message
John Williams (jswillms) said : 		#12

To try a different approach, I installed the beta from scratch, using the alternate disk. Deleted and rebuilt the raid arrays. I have 2 identical drives, that I partitioned into 3 (/, swap and /home) partitions. Then made 3 raid1 arrays (md0 for /, md1 for swap and md2 for /home). Installed the beta, and guess what?

Ran into the identical initramfs problem! So, the above migration procedures probably failed not due to the procedure but due to a bug in mkinitramfs or related feisty issues. It appears that the ramfs is complaining about missing files, such as /etc/fstab. On the migrated version, I tried to mount /dev/md0 and that failed to continue the boot. On the fresh install, mounting /dev/md0 allows the boot to complete and the system comes up.

Another thing to note is that fresh mdadm updates were applied (along with the rest of the 300+ updates). During post-processing, update-initramfs was run. I was hopeful that this would correct the boot bug, but it did not.

So, my action plan is to get hold of the daily build, or the RC, whichever occurs first, and retry the install. If it still fails, I will open a bug in launchpad.

Revision history for this message
Best John Williams (jswillms) said : 		#13

Final note - this is all working fairly well on released level of Feisty. The recent initramfs updates make the reboot work most of the time. Not 100% but close. If it fails, I just manually mount /dev/md0 and continue (mount -t ext3 /dev/md0 /root).

There is still a problem with init of the IDE ports on SATA (when IDE has both CDrom and disk) that is causing my cdrom to go missing. That is a known bug that will be picked up in a upcoming update...

Revision history for this message
hohum (hummon) said : 		#14

I have configured RAID1 from the Feisty DVD (text install) with two SATA drives,
sda1 = /boot
sda5 = /
sda6 = /altroot
sda7 = swap
sea8 = /home

After syncing is complete, the system boots with both disks.
After installing grub stage 1 and 1.5, either disk will boot alone, BUT
first it drops into the busybox prompt, "(initramfs)".

if I type

mdrun

and reboot, it will come up to ubuntu.

It appears this behavior is consistent.

I am new to RAID, trying to learn enough about it to send off a system to a remote
location, off line, with unknown sysadmin support at the other end.

I am worried that there might be some other bug (magic command needed,
linux RAID-savvy person required to figure it out) and I am perhaps better off
doing without RAID for the moment.

Any feedback is appreciated.