Topic: Trying to install SME 6.0.1 on SATA RAID ... BUG in SME ...

[jeremy]

I downloaded all of the "Dev Tools" RPMs from:

http://mirror.contribs.org/smeserver/contribs/saco/contrib/devtools_SME6.0/

I just installed all of them that I could.  All but two (only openssl-devel-0.9.6b-32.7.i386.rpm and anaconda-7.3-7.i386.rpm were missing dependencies) were successfully installed on a no-frills machine running a basic install of SME 6.0.1.

One of those RPMs (I don't know which) eventually installed "cc" which one needs to use the "gcc" compiler.

[jeremy]

I downloaded the following zip file from VIA, which includes driver source code for the VT8237 SATA chipset.

http://downloads.viaarena.com/LinuxApplicationNotes/Apr04/via_raid_linux_v100_20040412.zip

It also includes a script dd.sh which compiles the driver for your kernel version of linux and generates a viamraid.img file which is a driver disk image.

I used this image to create a driver disk:

> dd if=./viamraid.img of=/dev/fd0

With the driver disk ready, I booted the SME installation CD on the target machine -- while holding down the left [SHIFT] key, so that the boot menu would appear.

At the boot: prompt, I typed "accept dd" so that the installer would prompt for the driver disk prior to installation.

The installer prompts for the disk, which was then inserted.  The installer then loaded the driver from the driver disk.

Installation then continued as normally, and -- for the first time ever -- the installer was able to see the two SATA drives connected and provided the usual options for a single disk install or a two disk install using software RAID-1.

I selected the RAID-1 option, and the installation started by formatting the drives, and then went through the install.  Finally, a dialog asked about creating a recovery disk, which I skipped.

The CD then ejected and the machine rebooted, as it should.

Upon rebooting, the machine booted from the software RAID-1 array and the SME splash screen was displayed giving the option of normal SME or using SMP.

I selected the normal SME mode and then, after a few text messages, a kernel panic occured.  One of the messages complained that the viamraid.o file was compiled for kernel 2.4.20-18.7BOOT, but that kernel 2.4.20-18.7 was currently in use.

I checked the driver disk image compile script, and it definitely compiles two drivers ( viamraid.o-2.4.20-18.7BOOT and viamraid.o-2.4.20-18.7 ).

It is clear that kernel 2.4.20-18.7BOOT loads its driver properly, otherwise SME would never have installed and the reboot (from the raid array) would never have brought up the splash screen.

So why isn't kernel 2.4.20-18.7 loading its own driver properly?

[cublink]

Jeremy on my last post I suggested looking at a couple of howtos, which obviously sparked you of on the current post.

In the "how to modify an E-smith 6.0 boot disk to add support for use with Adapetec Ultra 320 SCSI controllers" on bottom of first page it mentions changing the line in the file from -18.7 to -18.7BOOT,
I wondered wether this is relevant?

I had same problem installing the rpms and anaconda and openssl still have missing dependencies. I installed in the following order:
cpp-2.96
glibc-kernel header
glibc-devel
gcc-2.96
zlib-devel
rpm-python
readline
pam-devel
automake
m4
autoconf
apache-devel
libtool
mkisofs
neurses
libstdet
libattr
libacl
libacl-devel
anaconda runtime
gcc-c++
kernel-source

I have to tell you that it didnt work for my controller Promise 20378, but that appears to be because Promise only supply a partial source for the driver and its compiles with gcc v3.0 which I think is in a later kernel.

On that note have you looked at the biggest thread on the forum "How to kernel upgrade" Mister Sleepy seems to have compiled a 2.4.27 kernel with hardware support for Raid controllers inbuilt.

[jeremy]

cublink,

With regard to installing the "Dev Tools" RPMs, I got what I needed (the cc and gcc compilers).

The boot disk modification page is somewhat stale.  It says to change the EXTRAVERSION variable in the Makefile from "-18.7" to "-18.7BOOT".  However, in the latest version of SME 6.0.1-1, the Makefile has "-18.7custom".

I did change it to "-18.7BOOT" before compiling the driver disk.  I also tried the install, after compiling a new driver disk after changing EXTRAVERSION to just "-18.7".  In both cases, the result was exactly the same:  Installation and reboot, but then kernel panic.

Booting is not really the problem.  We can boot on install and boot after install.  Its getting the post-boot kernel to use the correct driver that is at issue.

From reading the kernel update thread, it looks like some programs will not operate correctly with the updated kernel.

The simplest path is to just add a driver for SATA, by compiling a version of the SATA driver for the appropriate kernel version, from the source.  We have the source.

Someone out there must have some experience with this driver module kernel version issue.  So, I'll ask the question again:

Why isn't kernel 2.4.20-18.7 loading its own SATA driver properly?

[cublink]

Ok understood, the other thread claims to have a kernel with support albeit bracketed (experimental) for via sata raid

http://forums.contribs.org/index.php?topic=20988.0
 Will this work for you?

[cublink]

Also I ask the question has anyone got SATA drives plus or minus raid working with the vanilla distro. I dont think SATA works full stop on the current distro, because I have now tried the SATA´s i bought for my origanal RAID on a promise 20378 chip ASUS mb, on four different mbs, 2 with RAID (different to promise, HPT) and just plain SATA in an attempt to use software raid.
In every case either the controller was´nt found in the standard kernel or in the case of vanilla SATA drives detected but the install hangs mid setup, before it starts to copy files.

And if you read the docs on the thread above, he says somewhere (I cant find it at the moment), something about "Fixed SATA to work in this kernel" !!!!

Friday when I have some time I going to install on IDE disk on RAID m/b then use Mister Sleepy new kernel and se if it sees the SATA RAID.

[jeremy]

cublink,

I read that other thread, and saw the "experimental" tag for the VIA SATA support.  If you read back through that thread, you will see the problems that an updated kernel causes with existing software.  It looks like new versions of packages need to be used, and it hasn't all been ironed out yet.

I'd be happy to use the existing SME packages, but with SATA support.  Not really asking for much.

Another issue with that thread is that there is no description of which VIA SATA chipsets are supported, even "experimentally".

According to VIA, the driver that I downloaded and have compiled supports the following VIA SATA chipsets:  VT6410, VT6420, VT6421 and VT8237

Also, VIA has drivers which are supposed to resolve the DMA / SATA issue which has been discussed in other threads.  Once this driver works for SME, I'd like to get that working as well, not to mention the Silicon Image SiI 3114 SATA driver, since the board we're using has that as well.

[jeremy]

I found this in a file called "driverdisk.txt" which came with the SATA driver source code and compile script, and item "c" suddenly jumped out at me.

This is the document describes how I install linux onto our RAID controller.  If you have any suggestion/questions, contact me with dolpherdu@viatech.com.cn

Here is what you should know before we can begin.

a). Kernel for installation(boot from CDROM) is not the same as the normal kernel, so we need to compile drivers for both kernel version. For example, for redhat9.0, the kernel from CDROM boot is 2.4.20-8BOOT, but after installation, boot from hard disk, the kernel version is 2.4.20-8. We will use XXXX to refer to the kernel version number.

b). Before installation, we must load the driver for BOOT kernel, to recognize our hard disk. The method is not standard for different linux vendors.

c). After installation, we need to boot from hard disk. Because kernel is installed on our RAID hard disk, we must load driver module before kernel init. This is done by a image file "initrd", the initrd is a filesystem image which should contain the driver information.

   We can see this initrd file under /boot/ directory, and boot loader(both grub and lilo) have an option "initrd = ourinitrdfile".

   After installation, we should add our driver module to this initrd file, unfortunately, the method is not standard too.
 
That's all. We'll discuss the details for each specific linux.

...

The kernel panic observed mentions using "INIT."

So, how can we access the boot loader during SME startup to give this instruction?  (Holding Left [SHIFT] did not work.)

[jeremy]

Discovered (in another thread) that pressing [CTRL] + [X] when the SME splash screen comes up takes you to the boot prompt.

Unfortunately, I can't seem to find an "init=" or "initrd=" parameter that it will accept.  I have tried variations of "init=/boot/initrd-2.4.20-18.7" but nothing seems to work.

Its not really clear how this file would (or should) have been created during the install process.  Its not of the driver disk.

The prompt suggests "Press [TAB] for options."  Doing so, shows "SMEServer_up" and "SMEServer_smp".  Typing either causes the boot process to continue, as if you had selected them at the splash screen.

Any ideas?

[jeremy]

I noticed a "make install" option in the documents that came with the driver source.  It looks like this is to update the installation of linux from the command prompt.

I see the same result from running "make install" as when the machine reboots from the array post install:

# make install
find /lib/modules/uname -r -name viamraid.o -exec rm '{}' ';'
install -m 555 -D viamraid.o /lib/modules/uname -r/misc/viamraid.o
depmod -a
depmod: *** Unresolved symbols in /lib/modules/2.4.20-18.7/misc/viamraid.o
modprobe viamraid
/lib/modules/2.4.20-18.7/misc/viamraid.o: kernel-module version mismatch
        /lib/modules/2.4.20-18.7/misc/viamraid.o was compiled for kernel version 2.4.20-18.7BOOT
        while this kernel is version 2.4.20-18.7.
/lib/modules/2.4.20-18.7/misc/viamraid.o: insmod /lib/modules/2.4.20-18.7/misc/viamraid.o failed
/lib/modules/2.4.20-18.7/misc/viamraid.o: insmod viamraid failed
make: *** [install] Error 255

[jeremy]

I'm replacing this thread with a new thread containing a HowTo that details the entire procedure that I have discovered as a result of the conversations in this thread.

The HowTo is available at:

http://forums.contribs.org/index.php?topic=23758.0

[ldkeen]

Jeremy,
I'm by no means an expert in this field, but I did spend three weeks sorting out the same problem as you're having now with my unsupported scsi controller. Here is my understanding of the boot process (correct me if I'm wrong):
From http://www.cpqlinux.com/sysinit.html

1) the boot loader loads the kernel and the initial RAM disk
2) the kernel converts initrd into a "normal" RAM disk and
frees the memory used by initrd
3) initrd is mounted read-write as root
4) /linuxrc is executed (this can be any valid executable, including
shell scripts; it is run with uid 0 and can do basically everything
init can do)
5) linuxrc mounts the "real" root file system
6) linuxrc places the root file system at the root directory using the
pivot_root system call
7) the usual boot sequence (e.g. invocation of /sbin/init) is performed
on the root file system
the initrd file system is removed

So In our case the kernel loaded by the inital ram disk (or initrd) is 2.4.20-18.7BOOT. Once we build the driver for this kernel and place it in the initrd.img file we dont need to do anything else or build any other modules for any kernel versions. In other words the driver is loaded as part of the initrd process. If you do it properly and insert the pcitable and modinfo stuff as well then you simply boot off the floppy with the cd-rom in the tray and the boot disk auto detects the controller and continues with the installation as if you were installing on an ide controller. Even when booting from the hard disk it still uses initrd (which contains the driver). If you send me the driver disk that you built I'll have a go at modifying the boot.img for you to test. Once you have created the boot disk containing support for the controller you can then use that disk on any system with that particular controller regardless of what kernel is installed or whether it uses an smp or up kernel.

[ldkeen]

Jeremy,
In case the above was a bit confusing the basic procedure that you should be following is as follows:

Build the driver object file against 2.4.20-18.7BOOT kernel
Grab hold of the boot.img file from the images directory of the SME6.0.1-01 cdrom
Unpack it (it contains the initrd.img)
Unpack the initrd.img
Copy the above driver object file into the initrd.img
Add the pcitable and modinfo entries if possible (to allow autodetect)
Repack initrd.img
Repack boot.img
copy modded boot.img to floppy (dd if=boot.img of=/dev/fd0)
Boot of THIS floppy and thats it.

Nothing else needs to be done. During the installation the initrd.img from the floppy is copied to the hard drive so upon reboot the driver is now loaded through the initrd from the hard drive. If you followed my procedure closely here http://comnetel.com/bootdisk.htm you would probably have it going now. I'd be happy to help if you need a hand.
Regards Lloyd

[jeremy]

Lloyd,

     Thank you for taking an interest in this.
I used your SCSI How-To as a basis for my procedure, but ran into the symbol and the kernel mismatch issue discussed above.

      Since this forum won't allow me to PM you, here is a link to the driver source that I've been using:

http://downloads.viaarena.com/LinuxApplicationNotes/Apr04/via_raid_linux_v100_20040412.zip

If you are able to create a proper floppy for the driver, I would really appreciate it.

Question:  Its not clear to me from your post whether we will be using the floppy to boot from, or if the floppy will be used as a driver disk during the install process.  

Obviously, I would prefer to load the driver once at install time, rather than having to boot from a floppy each time the machien start.

Also, have you had a chance to read through my How-To (linked a few posts above)?

Looking forward to hearing back from you.

[ldkeen]

Question: Its not clear to me from your post whether we will be using the floppy to boot from, or if the floppy will be used as a driver disk during the install process

Jeremy
Once we modify the boot.img from the SME6.0.1-01 cdrom we then use THAT modified boot.img file to boot from. That boot.img file can reside on a floppy or you can replace the boot.img from the cd with your modded one and boot straight from the cdrom. There is no requirement for a driver disk once we modify the boot.img file. The boot.img file includes a very tiny kernel (2.4.20-18.7BOOT) and filesystem containing our drivers.
Regards Lloyd

Unfortunately I dont have access to a build machine at the moment. Are you able to send me the driver object file that you compiled against 2.4.20-18.7BOOT?? I'll have a look through the above link to see if I can find the pcitable and modinfo stuff and we might be able to test it today.