Hi All,

I'm looking for tips on how to do a CentOS server installation onto a hard drive, and then clone that drive to a RAID 1+0 array. I am fairly new at linux, but I think this would be the process:

install onto 2g usb drive (sde, boot and root)
boot into the OS and create the array using mdadm (sda, b, c, d)
Partition the array as desired, including / and swap
Use rsync to clone the / partition onto the array (/boot will stay on sde)
- I need to research the appropriate commands

Modify fstab and menu.lst
- are there any other places I need to modify?

Is this possible?

Thanks!

J

P.S. I could not find a way to set up the RAID first, or during installation, which would make this easier. Maybe I'm searching for the wrong keywords.

The CentOS installer can configure software RAID for you, but you have to use the manual install options.

http://www.flmnh.ufl.edu/linux/linux_software_raid.htm
... the search term was "centos raid install", this was the fifth hit.

True HW RAID will simply show up as one drive, no worries there. Fake-RAID is not usually worth the trouble.

Back to OP's original perceived problem:
-- How to clone an installation?

Assuming an appropriate copying method has worked & that we are not dealing w/ the trivial case of the target having the same /dev identity as the source, what is the answer to: Just a day or 2 ago this Q came up in conversation & neither of us could quickly think of any additional files that need to be modified to reflect the new location. (We were discussing copying /dev/hda1 to /dev/hda2 & then making it work in both places. I doubt it matters, but, FWIW, we were talking about using MEPIS 6 or 7.)

You want hda1 to hda2 ... you only need to modify fstab, unless hda1 contains /boot, in which case you'll want to modify menu.lst too. Remember to mark the partition bootable.

Its more common to move a directory to a new partition - for eg. Running out of space in root (small root, big /home) one may plug in a new drive and take /usr out to the new space, freeing around 3+gig depending.

In this case, only an fstab entry is needed - mounting the new partition (in this example /dev/hdb1) at /usr automatically at boot.

A more interesting scenario is where you clone an entire drive to another on the same computer. So hda is copied completely to hdb. You want to be able to boot either.

You may want to do this in a testing environment where you are tweaking one installation and keeping the other as a control. I'm sure a creative person can come up with other uses.

menu.lst needs to be modified on hda, and /etc/fstab needs to be modified on hdb. There is the option to have the a install chainload the b install... IIRC that will involve reinstalling grub to hdb so it is not in mbr (hdb0). You lose some symmetry, but the two installs get to update themselves without messing each other up.

And for the advanced student - lets clone a partition to a virtual machine...

Linux needs a bootable partition? What am I forgetting?

That's almost the same scenario of the local discussion that triggered my post. In fact, experimentation is our reason.

Doesn't the menu.lst on hdb also need to be modified?

-- on the list, in fact.


My main concern is if there is possibly anything else that needs to be changed. Are menu.lst & /etc/fstab the only ones we need worry about?

Well... I don't actually know if it is needed for linux. You have information to the contrary - an install where /boot partition does not have the bootable flag set?
If you chainload them, but don't remap the drives ... sure.

menu.lst formats the grub menu and tells grub where to find the kernel.
GRUBs job from there, is to load the kernel.

The kernel initialises the devices, and loads the root filesystem... then init (sysV).

So the menu.lst job is done before the hdb menu.lst is even available to the kernel.

Provided you have a standard setup - sure.
If you are running a server, then server configuration files may need to be edited... particularly if both server instances are to run concurrently.