The install script supplied with the Promise FastTrak100 Tx2 is a piece of junk. There is very little chance of the system booting from the RAID controller, if you use this install script. Not only that but the liklihood that the pre-built device driver that Promise supplies you with will work with your kernel is slim. You may need to build the driver from scratch.
Here are the steps to take to build the Promise FastTrak device driver from scratch. Do all of the steps (1-15) with the target system attached to the regular IDE controller and the system booted from it.
If you select the latest "Partial Linux Source Code" (anything from version 1.03.0.2 up), the problems with the missing symbols should be resolved.
Uncomment the line for the kind of FastTrak driver module you wish to build. Note that, although the comment says the default is "INDEP386", the default is really "DEP386".
Here is a brief description of what they are:
Note that the parameter says "386" but it is for the 586 architecture. If you're getting the idea that the Promise guys in Taiwan are confused, join the club.
Note that the "fasttrak.o" module is deleted by the Makefile, probably so that you won't confuse it with the "FastTrak.o" module. If you rerun the Makefile, this module will always be built.
In this example, the kernel version is "2.4.18-26.8.0". If you've built any specialty kernels, you might want to copy this driver to them too. However, you may need to recompile it for the specialty kernel version before doing so.
You can see all of the kernels on your system by looking in "/lib/modules".
The result of this command should be placed in "/lib/modules/kernel-ver/modules.dep".
You can see if the FastTrak driver is there by doing a grep:
You should see something like:
If you see an error that the kernel version doesn't match the version that the device driver was built with, you can change the version number in "/usr/src/linux/include/version.h" (if you're sure you know what you're doing). Otherwise perform steps 11-14 as shown in "Kernel Builds Under RedHat Linux" and then try again.
To rerun the Makefile, you'll need to delete "wrapper.o", "ftlog.o" and "FastTrak.o" by hand, since "make clean" doesn't work.
Note that this step may not be strictly necessary, since the drivers will probably get loaded automagically but it couldn't hurt.
If your kernel version were "2.4.18-26.8.0", you would use:
Hack "/etc/lilo.conf" (if you're using GRUB, you're on your own) and add a new section for the FastTrak controller (we'll assume in this example that the kernel version is "2.4.18-26.8.0"):
Use the name of the initial RAM disk that you created in step 12 for the "initrd" parameter. Use the same partition for the "root" parameter that was used before but change the device from "hd" to "sd". For example, if the other sections say "root=/dev/hda3", make this one read "/dev/sda3". Note that "/dev/sda3" presumes that the RAID array that you are trying to boot from will be the first one.
Do not make this new section the default, just yet. If the system fails to boot from the FastTrak RAID controller, you can switch back to the IDE controller in order to fix it.
Write the new boot configuration to the boot partition using LILO:
Make two copies of both these tables, one for the IDE drive and one for the FastTrak RAID drive. The RAID drive shows up as a SCSI device so call it "sda" and call the other one "hda":
Using your favorite text editor, edit "/etc/fstab.sda" and "/etc/mtab.sda". Change all occurrences of "hda" to "sda" (this is assuming that the drive was originally mounted on "hda" and that the new RAID array will be array 1, which will appear on "sda").
This is the absolute last step because once you do this, you will no longer be able to boot the drive on the IDE controller. If things get screwed up, you can mount the drive on a second Linux machine (you do have a second Linux machine, don't you?) and reset the mount and file system tables back to what they were. For example:
There is an alternative to this approach that doesn't involve living dangerously. It is possible to create a couple of mini root partitions that contain only "/etc" and, by extension, "/etc/fstab" and "/etc/mtab". These can then be pointed to by the "root" parameter in "lilo.conf". The partitions would have to have been created before hand, of course, and they would link all of the other directories in root to a common partition. It hardly seems worth it but it would allow one to switch back and forth between "hda" and "sda".
If it does boot OK, you can proceed to the next step. Otherwise, put the disk from IDE1 into another machine and reset fstab/mtab. Once you've done that, you can boot it as a regular IDE drive and, hopefully, repair the problem. If you need to go back and forth, you can do so by attaching the single disk to the RAID controller and leaving the other disk off IDE2. The controller will whine but will let you boot from the array with only one disk. Problems with the driver can be fixed by going back and forth between the regular IDE controller and the FastTrak RAID controller without updating fstab/mtab. The driver must load OK and the system boot from the RAID controller to the point where it tries fstab/mtab before the system will boot using the modified fstab/mtab. If it passes this test and drops you into single user mode because it can't mount "/dev/hda3", the changes to fstab/mtab will likely spell success.
If you do have to resort to this step, the RAID array will have to be rebuilt, once the second drive is added back to it. However, there is no point in doing so utill you are sure that the system boots all the way, since the RAID rebuild is a lengthy process, not to be repeated often (it took over four hours for a rebuild on a pair of 120G disks).
Note that, if you do this, the FastTrak RAID controller will be misidentified as an IDE device (well, actually, it is an IDE device. It is the same, identical device as the Promise IDE controller with one jumper installed and a different revision of the PROM) and the RAID disks will show up as "/dev/hde", "/dev/hdg", etc. This is not a problem but you should not try to access these disks by those names.
Write the updated boot configuration to the boot partition using LILO: