SysV-Init scripts...change order during bootstrapping?
 

Running:
Mandrake10 official
kernel 2.6.3-14mdk


I hope this is an easy question.

Here is the situation. I need to change the order in which my programs and modules are loaded during bootstrapping. My wireless "driverloader" is installed after eth1 is brought up. This causes eth1 to fail and I have to manually load the driver from a terminal. Usually I use the GUI tool kdeadmin-sysV-init editor for this kind of operation. I have installed that program but it crashes and is thus useless--very strange by the way, because I have two machines with almost the exact same configuration and sysV-init runs on one but not the other. It doesn't really matter.

Here is the question. What script or file do I need to edit/change so the driverloader will move ahead in the batting order? Or is this going to be a huge hassle of reconfiguring the kernel? God, I hope not.
In any case, thanks in advance for any tips and or solutions.


regards,
tsw

hi,

i don't think this is going to be a major hassle for you.

i use SuSE 9.0 so there may be some detail differences.

Your init scripts should be located in /etc/init.d. Then you should see a number of subdirectories relating to each of the run levels - rc0, rc1, ... etc.

you'll certainly want to have a look at run level 5 - go into rc5.d.

Now, here's where I'm going from memory somewhat (I'm at work, not in front of my linux box..). Anyway, you should see a load of symbolic links, of the form 'S01', 'K01', etc. The S refers to startup, k (i think it's k....) shutdown.

Each of these links will point to one of the init scripts in /etc/init.d, the number representing the order of execution (1 first, 99 last) - so by altering the name of any link refering to your wireless driver, you can change the order in which it is loaded...

Thanks for the response,

Yeah, it seems pretty straight foward. Great explanation. I am assuming that I need to rename the scripts for each of the rc.d files (run levels). I am pretty sure I do. At least that is how that GUI program operated. In fact, this doesn't seem any more difficult and is much less frustrating than trying to track down the cause of a crashing program. Again, thank you. I appreciate your time today.

tsw