# Faild to automatically start RAID devices (Kernel 2.6.17)

## blubbi

Hi all,

yesterday I upgraded my system from Kernel 2.6.16-gentoo-r12 to 2.6.17-gentoo-r4 and the new baselayout-1.12.4-r7

After that I had and still have a lot of trouble.

Two hraddrives are attached to a Highpoint RockedRaid 454 for which I use the opensource driver (successfully! Modules called hpt374).

The driver works fine with the new kernel BUT something is screwd up. My system tries to initiate the md device bevore ANY module has been loaded.

How can I prevent raidtools or mdadm to bring up my devices bevore the hpt modules has been loaded?

After the modules have been loaded, there is no problem starting the raid devices (just a raidstart -all or mdadm --assemble -s , works flawless)

I tried to generate an initrd file, but without success.

For now I tried an ugly hack. I wore a startscript which I wanted to be run bevor checkfs (what btw did not work, the script gets started right bevore runlevel 3 so I still have to hit STRG-D and mount all devices manually, than restart all apps which could not find their folders...) Seems as if my Depend is ignored completely

```

depend() {

        after checkroot

}

start() {

ebegin "Setting up raid device md1"

mdadm --assemble -s

result=$?

eend $result

}

```

Settings changed in rc

RC_PARALLEL_STARTUP="no"

RC_NET_STRICT_CHECKING="yes"

Any help appreciated

best regards

blubbi

This is what I get from bootlog:

 *Quote:*   

> 
> 
>  * Starting up RAID devices (raidtools) ...
> 
> /dev/md1: Invalid argument
> ...

 Last edited by blubbi on Wed Aug 30, 2006 1:00 am; edited 2 times in total

----------

## troymc

I'm a little confused by your post.

You mention using "a Highpoint RockedRaid 454" and it's open source drivers and reference a thread dealing with dmraid.

But everything else in your post deals with kernel raid. (mdadm, /dev/md1, etc).

So my first question is: Which are you using? Kernel-based software raid, or device-mapper software raid (dmraid)?

My first inclination is to think that you've confused the two, and have a dmraid setup that you are trying to configure/mount/etc as if it were kernel raid.

troymc

----------

## blubbi

Okay, I confused myself... I just use kernelraid

----------

## tomatopi

This may be completely out to lunch, but it's not a typo like in your post of in "Dedepend" rather than "depend" that makes the initscript ingnore the order?

----------

## blubbi

arrrgs, once more. This shows that one (especially me ) shoudn't code at 4am

Thanks

But the bootorder is still unimpressed

blubbi

----------

## blubbi

Okay, maybe this gets me to change to use some other linux distri on my server.

No one can explain why the damn raidtools, or mdadm ar trying to init raiddevices BEVORE anything else.

This is damned to fail. No Modules loaded, nothing.

Alll this came with a recent baselayout update and kernel upgrade.

If I woun't get that problem solved, I am forced to switch my distri ... sad, but true.

hope someone can help to fix it

----------

## appelgebak

You must not change:

Got the same problem here, have it second time-

at the first time i had some changes in config-files  i did not remember, so- after doing an 'etc-update' after world-update 

i think i was a little bit to fast merging a new file without thinking in the same speed as typing.

Now i have same prob again, and i will close the problem today or tomorrow.

Then, after i won the game i will place solution here.

Appel

----------

## blubbi

I now managed to crate a initrd.

With the drivers loaded while the kernel is loading, there are no more problem.

But I would be interested in an other solution without creating an initrd file.

regards

blubbi

----------

## appelgebak

Well, i also packe the module for scsi-disk into the kernel, and have no more probs.

But i wonder about the change etc-update made...

appel

----------

## drescherjm

 *Quote:*   

> No one can explain why the damn raidtools, or mdadm ar trying to init raiddevices BEVORE anything else.
> 
> This is damned to fail. No Modules loaded, nothing. 

 

Anyone with an idea how to stop this behavior or rearrange the boot order such that /etc/init.d/modules starts before the array is started? I recently upgraded baselayout on a server at work and I am experiencing a similar problem as above. The problem is that the raid array is trying to be started before the driver for the sata is loaded from /etc/modules.autoload.d/kernel-2.6.

[EDIT]Ok there is a bug report here: https://bugs.gentoo.org/show_bug.cgi?id=144017 and it is said that this is fixed in baselayout-1.12.5. I was using baselayout-1.12.4-r7 so I guess its time to upgrade that...[/EDIT]

[EDIT2]Since it is 5:17AM and I am not at work yet   :Laughing:  I do see the patch was applied in baselayout-1.12.5.[/EDIT2]

----------

## drescherjm

Emerging baselayout-1.12.5 solved the problem for me.

----------

