> I am using RedHat 5.2 (raid supported) and am having a hell of a time
> getting a root partition to boot as raid 1.
.....
> I am simply trying to set up mirroring on my root partition for High
> Availability (as well as fault tolerance). I don't want my system to
> lock if any one of the drives go out.
If you want High Availability, you probably want to use server mirroring, or failing
that, hardware raid. See the recent messages on this list about swap on RAID for one
reason why a disk failure may well take down a software-RAID based server. But
assuming you've got to use software RAID (because you are using existing hardware),
the good news is that the latest RAID code supports root-RAID very well. The bad news
is that firstly, you don't have the latest RAID code, and secondly, getting your
system into a state where you can use root-RAID takes a bit of contortion.
With regard to the first problem, refer to earlier messages on this mailing list
which have pointed out that the RAID support included in RH5.2 is, in the fashion of
more recent RedHat releases, a balls-up. In particular, see Luca Berra's message of
16/11/98 on the "Obsolete MD ioctl error - help..." thread. RedHat included old
versions of the RAID code/tools, which were superseded even before RH5.2 was
released. So you will want to remove RH5.2's RAID setup with "rpm -e raidtools" and
remove any line referring to any of the old raidtools in /etc/rc.d/rc.sysinit and
/etc/rc.d/init.d/halt.
As for the second problem, the difficulty is that you can't install onto a RAID
array, so you have to go through a few hoops to get the root partition onto one.
Basically, you are going to have to create a sacrificial installation partition(s),
create the RAID device(s) and then copy the installation across. My preferred way is
to install initially to areas of the disks which I intend to use later as swap, but
this does mean that you will end up with large areas of swap (remember you are going
to need enough disk space to accommodate a basic installation plus the kernel
source), when you may not want to use swap at all if you are that concerned about
High Availability. If that's the case, you will have to base your scheme around the
way you will divide up your filesystem (you will be unable to have your whole
filesystem on a single array without wasting the space to which you originally
installed). Pick a part of your filesystem (say /usr or /usr/src) for which you will
want to allow at least 200MB, say, of disk space. Let's say, for the sake of
demonstration, that you will use /usr/src. The following scheme will work as well for
using another partition, or swap:
Install RH5.2 onto a partition which will initially be root, and later /usr/src. Make
this partition at least 200MB, or more if you think you will want more for /usr/src.
Do not bother installing RedHat's raidtools or kernel-source packages. Reboot after
installation.
Install (a) a clean (i.e. unpatched) version of the kernel source package (the RedHat
rpms probably won't work), and (b) the latest RAID kernel patch and raidtools package
(at writing, these are raidtools-19981201-0.90.tar.gz and
raid0145-19981110-2.0.35.gz) from
http://www.kernel.org/pub/linux/daemons/raid/alpha/. Patch the kernel source with the
RAID patch and recompile. It is best to build the RAID support you require into the
kernel rather than as a module, because modular support is still flaky. And, make
sure you include auto-recognition support - this is always a good idea, and a
life-saver for root-RAID.
When you have successfully compiled and rebooted into the kernel with RAID support,
mark any partitions you want to be RAIDed (other than the current root partition) as
type (0x)fd using fdisk. For reasons explained later, you will also want to have a
non-RAIDed mini-partition of a couple of MB in size on the first two disks on the
SCSI controller(s) for the kernel image. And if you will be converting the
installation partition into a RAID array for /usr/src, make sure you have matching
partitions on the other disk(s) (but don't mark them type fd yet).
Extract the raidtools source and change into the directory created. Do "make; make
install; make install_dev" to compile and install the tools and devices.
Using raidtab.sample (in the raidtools directory) as a model, create your own
/etc/raidtab for the setup you require.
Do "mkraid /dev/md?" where ? is the number of each RAID array you want to create (as
listed in /etc/raidtab). If all is well, these arrays should be active (cat
/proc/mdstat to check).
Create a filesytem on each RAID array with "mke2fs /dev/md?" (or the equivalent for
whatever type of filesystem you want).
Copy each part of the filesystem to their respective arrays using "tar clf - * | tar
xpfC /RAID/mountpoint" where /RAID/mountpoint is the point on the filesystem where
the RAID array to which you are copying is currently mounted, and where you are
currently in the directory which you want to copy. The l switch to tar should prevent
the recursion which is possible when you are copying the root filesystem, but you may
get errors - check that tar hasn't done a recursive copy. For now, /usr/src can live
on /usr or /, depending on the filesystem structure you have chosen.
Edit /rootRAID/mountpoint/etc/fstab (i.e. etc/fstab on the root RAID array) to
reflect the filesystem as it will be when you are running root-RAID (excluding
/usr/src for now).
Edit /etc/lilo.conf to point at the kernel image and root md device you will be using
once you are running root RAID. This requires a decision. You can have a
mini-partition to place the kernel image on. Or you can take a chance on pointing at
the kernel image on one of the partitions which make up the root RAID array. This has
worked for me, but others have had problems with it. If you want to do this (which
option, by the way, is only available if your root-RAID array is RAID-1), unmount and
stop the root-RAID array with "raidstop /dev/md?" where ? is the number of the
root-RAID array. Now mount one of the partitions which make up the root RAID array.
Edit /etc/lilo.conf to point to the location on the current filesystem of the kernel
image on this partition. Run lilo and your next boot-up should be using this kernel
image. However, having just thought about this, it strikes me that a fairly major
disadvantage of this scheme is that you will never be able to run lilo again! Once
root is on a RAID partition, you will not be able to stop the root RAID array to
point to a kernel image on one of its partitions. Much better, then, to have a
partition of a couple of MB in size to put the kernel image in (better still,
partitions on the first two disks in the root array, each with a copy of the kernel
image, for reasons I will come to later).
Run lilo and reboot. The kernel should autorecognize the RAID partitions and
start/mount them automatically. In this case, you are now running root-RAID. There
are just a couple of things to put right, if you want:
Firstly, you may want to use the installation partition for /usr/src. Some people
prefer to keep it as a rescue partition, but the RAID code is solid enough nowadays
not to need this. If you do want to mount /usr/src here:
Use fdisk to mark this partition and its equivalent(s) on the other disk(s) as type
fd.
Add an entry to /etc/fstab for this array.
"mkraid /dev/md?" for this md device.
"mke2fs /dev/md?" to create a filesystem on this device.
"tar clf - * | tar xpfC /RAID/mountpoint" (as above) while in /usr/src and this array
is mounted on /RAID/mountpoint.
Delete the contents of the current /usr/src, so it is an empty directory.
Edit /etc/fstab to reflect the new location of /usr/src.
Reboot. Your system should now be exactly as you designed it in the first place.
Secondly, for High Availability, you probably want to deal with the situation where
your first disk fails and takes down your kernel. As we are currently configured, you
will not be able to reboot in this situation, as lilo has been installed into the MBR
of the first disk, which is no longer available. You therefore need to install lilo
on the second disk as well, with the added complication that it needs to think it is
the first disk, as it will be if it is ever used. To do this, create an alternative
lilo.conf (say /etc/lilo.conf.sdb). Assuming your second disk is /dev/sdb (replace it
at the appropriate points with /dev/hdb if that's what you are using), include the
general lines "boot=/dev/sdb" and "disk=/dev/sdb bios=0x80" at the start, to fool
lilo into thinking that sdb is the first disk. Run "lilo -C /etc/lilo.conf.sdb" to
install lilo onto the second disk. Now, hopefully, if you reboot with the first disk
not present, your system should still work, albeit in degraded mode.
I hope I have remembered everything correctly. It is some time since I set my system
up, so I may have forgotten something vital. I am sure someone will pick up on it and
let you know if I have.
Cheers,
Bruno Prior [EMAIL PROTECTED]
