On Mon, 2002-12-09 at 08:00, Bill Dossett wrote:
> Hi,
> 
> Does anyone from redhat ever hang out on these lists?
> 
Yeah there are many RedHat people who read the list.
This is visible by looking at all the online archives
and seeing the from addresses that end with "@redhat.com"

I have a feeling that many people that would answer your questions
are going to be put off by your demanding and accusing 
tone. (Even if you don't intend it.)

> I REALLY, need to figure out how the hell they do bootable
> software RAID as modules....
>
> I am trying to convert a system to bootable software raid
> from a single disk system.
>
> I really really really do not want to have to spend three
> days configuring this server after a reload.
> 
> However.. all documents that I read about bootable software
> raid assume you are building your own kernel...  and I know
> that redhat loads the raid modules .. most likely via initrd
> I guess, but try as I might, I can't get this into a bootable
> system.

You are correct, they do it through mkinitrd
The command
man mkinitrd 
will show you what you probably need.
> 
> If I build my own kernel, then I will continue to have
> problems every time I run up2date and I'll have to constantly
> build new kernels and while I don't mind building a kernel,
> I used to do it all the time, I am trying to make things easier
> to maintain around here.. not harder.
> 

By default "up2date" skips kernel package update errata unless you 
specifically tell it not to.

In your /etc/sysconfig/rhn/up2date file you can control this:

removeSkipList[comment]=A list of package names, optionally including
wildcards that up2date will not remove
removeSkipList=kernel*;

noBootLoader[comment]=To disable modification of the boot loader (lilo,
silo, etc)
noBootLoader=1

pkgSkipList[comment]=A list of package names, optionally including
wildcards, to skip
pkgSkipList=;
# OR
#  pkgSkipList=kernel*;
#  which by the way is on by default, so you don't need to worry about
#  that.

This information is indicated in  "man up2date"


Each new kernel comes with /boot/config-*
which is the RedHat kernel config file.
If you installed the RedHat Kernel source RPM then you can copy this
file into your /usr/src/linux-* directory and then you can load it and
just change the few variables that you need, they are usually simple 
things like:

CONFIG_MD=y

Most of the time your kernel doesn't HAVE to be updated unless the
errata indicate a problem that would affect your particular situation.

System Administration is not free, it does require some work.
For example I have many systems that have custom compiled drivers for
RAID devices, and I don't upgrade the kernels on those boxes very often.
Most of the time the notes for a kernel errata might say something like:

FIXES problem with SMP 
or
Fixes ip_conntrack issue with FTP in iptables.

Well, in a single CPU box that is not running any firewalling I don't
need to apply this update at all, so I don't worry about it.

> Can anyone point me in the right direction to any documents about
> how to do this?

Have you tried going to www.google.com and doing a search for
        RedHat Software Raid howto

Most of the information is for RedHat 6.2 or 7.1-2 so you will
have to read the docs to get an understanding and then apply
that to what version you are running.

RedHat 8.0 kernels have built in support for Software Raid.
The installation process has Software RAID configuration GUI's
The RedHat 8.0 manuals also contain a section about how to configure
it after you have completed an install without it.

> And secondly....   is there any further info on bootable sofware
> raid and what I do if one of the disk fails?  I pulled one of the
> disks the other day while the system was powered down, and it wouldn't
> boot at all while it was out... that certainly is _not_ the way
> my hardware RAID systems work.  I am using the GRUB boot loader
> and I assumed that each disk was bootable, but no go here, I had
> to put the disk back in before it would boot up again..  if they
> are going to offer us software raid, then I think they should follow
> thru and tell us how to use it.
> 
> Thanks
> 
> Bill

Well, it isn't hardware RAID, so of course it isn't going to work
just like the hardware RAID systems.  This is one reason why there are
hardware RAID solutions.

Think about the process that PC hardware goes through during the boot
process. It looks at the MBR on the configured boot devices for the
system.  Just because you have file system partitions that are mirrored
in software after the kernel loads and configuration begins doesn't mean
that the PC BIOS knows anything about it.  

You have to install grub on the MBR of each of the devices that you 
intend to be bootable, and you have to make sure that the boot sequence
finds those devices first.

Even if you accomplish this you can still have a primary IDE hard disk
fail in such a way that it will prevent your system from booting.

What you are trying to accomplish may be best addressed by a hardware
raid solution.

-Ben.



-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to