# hen-and-egg situation: kernel boot /w initrd

## philip99

Hi...

I've run into a rather serious problem, where I currently face the classical hen-and-egg situation...

What I have:

An existing Linux installation on /dev/hda.

An IDE cdrom. (at /dev/hdb)

No scsi devices attached.

What I want:

The goal being inserting a FastTrak raid cntrl. card, doing a "semi-hardware" raid1 configuration with two identical IDE disks.

What I got after insertion:

A emulated scsi harddrive (at /dev/sda)

No IDE harddrives attached

An IDE cdrom (now at /dev/hda)

The problem:

After insertion, I can't of cause boot my Linux... I chose to boot from the cd, and when I loaded the FastTrak driver, it emulates a single scsi harddrive, located under /dev/sda. No problem here...

After changing the various configuration files, copying the FastTrak drivers and creating a new initrd image, I ran into a problem.

The problem appears when booting from the "scsi" disk... The classic message "RAMDISK: Couldn't find valid RAM disk image starting at 0." appears.

My guess is that after the initial kernel boot, it tries to fetch the initrd.img file under /boot/... However, before this can succeed, the kernel must know of /dev/sda... The driver however for /dev/sda is located _in_ the initrd.img file.... Ergo resulting in the hen-and-egg situation...

As far as I can see, the only real solution is to include the driver into a new kernel compilation... Only problem is that the driver is precompiled, and I have no access to the sourcecode... 

What now? Can I, at compile time, link the module into the kernel?

Or is there some way that I can tell the kernel to locate the initrd.img file the same way as lilo tells the PC where to find the kernel?

- Philip

----------

## ravon

Ha, sweet! I have the EXACT same problem. There are some better drivers here: http://majestic.lugh.de/~fs/promise/index.html, though they're still not implemented into the kernel.

Please, tell me if you get that initrd/kernel up and running.

----------

## ravon

And oh, I got a simpler (but lower version) driver from Promise support. I managed to get that one into the kernel, but it seems like it's not called during the kernel boot.

I can forward that source to you if you want.

----------

## philip99

Please do... My e-mail is philip at soeberg dot com... I'll give it a try  :Smile: 

----------

## ravon

 *philip99 wrote:*   

> Please do... My e-mail is philip at soeberg dot com... I'll give it a try 

 

Hmmm.. It bounced back :/

http://ormgas.com/misc/OpenSourceSATAb15.zip

----------

## philip99

Merely a progress update:

I have gotten one step further; After investigating how lilo/kernel/initrd interacts, I discovered that it was in fact lilo, and not the kernel as first assumed, which loads the initrd image at boot... From here I could conclude that although lilo did load the image, the kernel still did not know the location in ram.

So an additional kernel parameter was added to the kernel list like this:

```

initrd=/boot/initrd.img

append="initrd=/boot/initrd.img ..."

```

This tells lilo to load the image, and parses its ram address to the kernel.

---

Next step was to build a new image with the FastTrak driver inserted. I'm working with the standard 2.4.19-16mdkenterprise kernel.

After doing a

```

mkinitrd -f --preload scsi_mod --preload sd_mod --with FastTrak /boot/initrd.img 2.4.19-16mdkenterprise

```

I prayed that everything would work... but sadly no..

Now I face a new booting problem; just after the kernel has completed, parsing process to the image, scsi_mod is loaded... Shortly hereafter a failure with 

```
kmod: failed to exec /sbin/modprobe -s -k block-major-8, errno = 2
```

 occurred...

I have so far traced this to the sd_mod module, but have not yet found a solution for it.

When FastTrak.o loads, it complains about unresolved symbols... This could have something to do with the above complaint... But I don't know yet...

Hope someone else (ravon?) keeps working on the same or similar problem...   :Rolling Eyes: 

- Philip[/code]

----------

## ravon

I use grub so I add "initrd /initrd" and "initrd=/initrd" to the boot parameters, but it doesn't seem like grub loads initrd (the path is correct since grub's autocomplete finds it). I get that modprobe error too, though I have sd compiled into the kernel.

I got this response from the Promise Linux team:

If you have statically linked the driver as part of the kernel, there is no need to create driver support in ramdisk since the kernel will initialize the driver.

The question is... HOW? I guess that would solve a lot of problems. I've mailed them and ask if they know a way of linking the module to the kernel. I'll get back here if I get some answers.

----------

## ravon

It works for me now. I got the initrd to work properly, but that driver didn't work with my chipset. I use the driver I got from their Linux support.

Philip: Check that you have SCSI, SCSI Generic and SCSI Disk support in the kernel.

----------

## philip99

 *ravon wrote:*   

> It works for me now. I got the initrd to work properly, but that driver didn't work with my chipset. I use the driver I got from their Linux support.
> 
> Philip: Check that you have SCSI, SCSI Generic and SCSI Disk support in the kernel.

 

I do... Its the standard enterprise kernel from mandrake9.0... The support is build as modules, but as far as I have understood the entire scsi subsystem is placed in scsi_mod, and devfs support for scsi is placed in sd_mod... Once these have loaded, all that remain is the specific cntrl.card driver.. Such as aic7xxx... or FastTrak (I assume)..

Ravon: Did you use the sourcecode you gave me a few posts above when you compiled your kernel? Did you staticly link it? Or did you use the initrd image, and included the various drivers here?

----------

## ravon

 *philip99 wrote:*   

> Ravon: Did you use the sourcecode you gave me a few posts above when you compiled your kernel? Did you staticly link it? Or did you use the initrd image, and included the various drivers here?

 

I used the source that I got from the Promise support (http://ormgas.com/misc/OpenSourceSATAb15.zip) and compiled the module by using their makefile. I then took an initrd image from a RedHat install, copied my ft3xx.o to the image and changed linuxrc so it only loaded my module.

----------

