GOAL: Dedicated File Server with Hardware RAID 1 Mirror array
I am running Debian Sarge 3.1 with a Kernel-2.6.8-2-686.
I have a Pentium 4, 1.5 GHZ processor with an Intel Desktop Mother Board D850MV.
I have an I/0 PCI ATA 133 RAID Controller with a Silicon Image chipset.
I have two identical Maxtor Drives of 160GB.
Both drives are connected to the RAID Controller.
In my BIOS RAID utility I have created a mirrored set:
Code:
Drive Number: 0 Maxtor 6Y160p0 156334 MB
Drive Number: 2 Maxtor 6Y160p0 156334 MB
Set: 1 <0> <2> SiI Mirrored Set <PM> 153333 MB
I tried to do a new install here, but the mirrored set was not 'true' as the second drive remained unwritten (what i could tell from multiple installations of Debian)
I then found instructions that led me to believe that I had to boot a linux kernel that I previously compiled with my RAID. And then mount the RAID, and then install Debian. This was after instensive searching, and became my only resource for finding an answer!
www.http://www.pocock.com.au/linux-doc/debian-raid-hw.html
Quote:
On the workstation PC, you need to build a kernel for the RAID PC.
The kernel source package supplied with Debian puts a zipped kernel source in /usr/src. You must decompress this with bzip2
cd /usr/src
bzip2 -cd kernel-source-2.4.21.tar.bz2 | tar xf -
cd kernel-source-2.4.21
make menuconfig
Select the kernel options required for your new RAID server. Typically, you must include the following into the kernel (but not as modules!):
* Choice of CPU
* Driver for RAID controller
* If the RAID controller uses a SCSI driver (some, like Compaq SMART2, use SCSI disks but do not require the Linux SCSI drivers!), you must inc
lude the sd SCSI disk driver
* Driver for network card
* Networking and TCP/IP support
Now you must save the kernel configuration, exit the menuconfig utility and compile your kernel with the following command:
make-kpkg binary-arch
After a few minutes, a kernel will be ready. Put the package file somewhere safe as you will need it again later. Now, you must make a standalone zImage file:
make zImage
You will use the zImage file shortly
|
This information is deprecated, or I am interpreting it wrong. Since I have a newer kernel, I used the newer kernel in place of the older one. I immediately found that the article left out dependencies needed to use the commands. i discovered them by trial and error and research.
Upon reaching the point where I must include the RAID drivers, I found that I had to research building drivers into the debian kernel. The best resource I could find was the following. However, it is deprecated information yet again; Sep 26, 2002.
http://www.phptr.com/articles/article.asp?p=29445&seqNum=6&rl=1
Quote:
An installation script that applies appropriate patches
The most common of all these is the patch against a specific kernel version. These patches can in most cases be applied with the following procedure:2
# cd /usr/src/linux ; patch -p1 < patch_file
Diffs made against a different minor version of the kernel may fail, but the driver should still work. Here, we cover how to manually add a network "snarf" driver to the kernel. It's a very complicated and tedious process, especially when compared to other operating systems we've seen.
By convention, Linux kernel source resides in /usr/src/linux. Within the drivers subdirectory, you'll need to find the subdirectory that corresponds to the type of device you have. A directory listing of drivers looks like this:
% ls -F /usr/src/linux/drivers
Makefile cdrom/ i2o/ nubus/ sbus/ telephony/
acorn/ char/ isdn/ parport/ scsi/ usb/
ap1000/ dio/ macintosh/ pci/ sgi/ video/
atm/ fc4/ misc/ pcmcia/ sound/ zorro/
block/ i2c/ net/ pnp/ tc/
The most common directories to which drivers are added are block, char, net, usb, sound, and scsi. These directories contain drivers for block devices (such as IDE disk drives), character devices (such as serial ports), network devices, USB devices, sound cards, and SCSI cards, respectively. Some of the other directories contain drivers for the buses themselves (e.g., pci, nubus, and zorro); it's unlikely that you will need to add drivers to these directories. Some directories contain platform-specific drivers, such as macintosh, acorn, and ap1000. Some directories contain specialty devices such as atm, isdn, and telephony.
Since our example device is a network-related device, we will add the driver to the directory drivers/net. We'll need to modify the following files:
*
drivers/net/Makefile, so that our driver will be compiled
*
drivers/net/Config.in, so that our device will appear in the config options
*
drivers/net/Space.c, so that the device will be probed on startup
After putting the .c and .h files for the driver in drivers/net, we'll add the driver to drivers/net/Makefile. The lines we'd add (near the end of the file) follow.
ifeq ($(CONFIG_SNARF),y)
L_OBJS += snarf.o
else
ifeq ($(CONFIG_SNARF),m)
M_OBJS += snarf.o
endif
endif
This configuration adds the snarf driver so that it can be either configured as a module or built into the kernel.
After adding the device to the Makefile, we have to make sure we can configure the device when we configure the kernel. All network devices need to be listed in the file drivers/net/Config.in. To add the device so that it can be built either as a module or as part of the kernel (consistent with what we claimed in the Makefile), we add the following line:
tristate 'Snarf device support' CONFIG_SNARF
he tristate keyword means you can build the device as a module. If the device cannot be built as a module, use the keyword bool instead of tristate. The next token is the string to display on the configuration screen. It can be any arbitrary text, but it should identify the device that is being configured. The final token is the configuration macro. This token needs to be the same as that tested for with the ifeq clause in the Makefile.
The last file we need to edit to add our device to the system is drivers/net/Space.c. Space.c contains references to the probe routines for the device driver, and it also controls the device probe order. Here, we'll have to edit the file in two different places. First we'll add a reference to the probe function, then we'll add the device to the list of devices to probe for.
At the top of the Space.c file are a bunch of references to other probe functions. We'll add the following line to that list:
extern int snarf_probe(struct device *);
|
I followed these instructions and copied the two files supplied by I/O for my silicon image chipset: "siimage.c" and "siimage.h". I moved them under the PCI Folder. (Since its a PCI card, and no RAID section was available) I edited my makefile in that directory with the script that they reccomended. Each time remembering to make snarf=siimage and the appropriate changes. When I get to the step where I am to edit the config.in file, I realize that it doesn't exist. There is, however, a kconfig file in the place where one would assume the config.in file should exist. Therefore, I simply input the text into that file as an experiment. The next step requires that I edit the Space.c file. The description this article gives to describe it is to vague for me to figure out what the new Space.c file is. Just like the config.in file, it no longer exists, and must have been replaced by a new file. Running make menuconfig again only offered me an error, therefore the kconfig file did not correlate! I ran make clean and gave up!
======================================================================
After this headache I decided to use the options on my menuconfig to load support for RAID. My RAID chip wasn't listed, but a general option was listed:
[*] Multiple devices driver support (RAID and LVM)
I checked this baby for support! And not just with an M for module!
<*> RAID-1 (mirroring) mode
I checked this baby for support! And not just with an M for module!
Okay. Maybe, the newer kernels will somehow support my device.. Maybe.
So then I go back to my very first resource to continue with the instructions and run:
make-kpkg binary-arch
This takes two hours (don't ask me why). Somthing must be wrong. I then try and make an image with the next command:
make zImage
It gives me an error stating that my kernel is too big!
I then pull my hair out and post this. HELP!!! What am I doing wrong? Anyone have a resource? ACK!
