INITTAB SYSV and BOOT MODULES
Written for COL2.2, differences exist in COL2.3. Redhat 6.x also differ in specifics. The overall structure remains the same for all.
This guide focuses on boot modules, specifically
/etc/rc.d/rc.modules. Other areas are intentionally
glossed over to get to this point.
Once a Linux Kernel has loaded itself into memory, the first (and only) process ever invoked by the kernel is init. The kernel does not load modules, does not check for soundblasters, and is not that interested in file systems.
The kernel takes no further part in the running of a Linux operating system. It is there to attach and detach resources to other resources as may be requested from processes running under, and including, init. The Kernel does not 'run' Linux. The processes do that. It is the processes that 'flavour' your version of Linux, not the kernel.
The mother of all processes, all programs, all activity in Linux is init. It is a program just like any other. It spawns all other processes that ever occur inside a linux operating system. This methodology is known as System V (SysV) unix.
BSD Unix, and other unix variants, are different.
You would imagine then, that init is one hell of a complex program?
The only thing init does, is read a simple configuration file called /etc/inittab to find out what other processes to run.
These other processes read other configuration files to see what processes to run.
These processes read other configuration files to see what other processes to run.
It is. As simple as that.
You can (and do) take this to the Nth degree. Most spawned processes are simple script files, as in humanly readable text, (what a surprise). These simple script files fire up processes such as cron, such as NFS, such as mgettys, and move on to the next layer of complexity.
You should therefore be able to see now, the highly configurable nature of Linux. It will do only what you ask of it, inside a chain of scripts. The simpler, the better.
/etc/inittab spawns all other activity. It consists of three parts.
1) names of Initialisation scripts to be used only at boot time.
The kernel is not concerned your soundblaster wont work. The kernel cares only that it can read write memory and start init. The initscripts are what starts your system, not the kernel.
2) A number of run levels *see below.
3) A number of uninteresting catchall's: power fail, three fingered salute (ctl-alt-del) etc.
Not surprisingly, these catchalls are simple names of scripts to run, just like the initscripts.
Run levels can be a surprise to the un-initiated. They are a woefully bad name to call a simple menu system.
Each run level is a pre-defined series of scripts. A given run level runs the *entire* system in a specific way. You could define a run level to run Spaghetti Accounting using 6 printers and a single console. Another run level to run ONLY Apache (http) and ftp and nothing else. Neither system operates at the same time, it's either, or.
In fact, the following run levels come pre-ordained as follows (remember, nothing stops you from altering this or the exact content)
1: Single Console Used for maintenence mode, absolutely bare
2: Multiple Console only, no networking.
3: Ditto Console only, with networking.
4: Gui, no networking (actually an unused spare)
5: Gui, + networking.
6: Power down.
Taking run level 6, you can imagine, only a small number of scripts necessary to shutdown the system are in this 'menu'.
What you may not know.
Typing "linux 3" (or any other number) at the boot prompt forces you into that specific run level.
/etc/rc.d/init.d and all that.
To understand how runlevels 'work', it is easiest to work
backwards. *Remember*, nothing is pre-ordained, these are
'accepted' file names and locations.
is the location for ALL scripts spawned by init. ALL of
them, regardless of runlevel. 'Spaghetti.rc' might
only be used in
run level 4, it is located along with all others in /etc/rc.d/init.d
The contents of spaghetti.rc (and all other xxx.rc's) is a script.
That script's sole purpose is to start AND stop the spaghetti binary (executable).
The location of the spaghetti binary is totally uninteresting.
In the bad old days, to kill, or restart a binary it was necessary to:
"ps xa | grep spaghetti"
"kill -HUP #numeric pid of spaghetti disclosed above"
Nowadays all scripts residing in /etc/rc.d/init.dare standardised to understand the following commands
"/etc/rc.d/init.d/spaghetti stop , start, restart, or reload"
In this folder is one important script. rc. rc is 'run control' .It is invoked by /etc/inittab as follows
rc simply processes every script it can find in /etc/rc.d/rc.X
Why doesn't innittab call the folder directly?
The simplest reason is why complicate innittab? Why not follow the lead and successively spawn out other processes? (in this case the rc process).
RC does something more. It allows switching of run levels. It first closes down all runnning scripts in the current run level with a continuous stream of "/etc/rc.d/rc.(oldX)/whatever stop"
followed by "/etc/rc.d/rc.(newX)/whichever start"
You should begin to now see the close correlation to what you can type on a command line, and what a script, ultimately does for itself.
These *are* the run level folders. One folder per run-level. The folder contains nothing more than links to whatever script you wish to run in /etc/rc.d/init.d/ Oh, what a suprise.
Everything you wish to do, to personalise a run level, is
contained in the rc.X folder and links to a humungous
pool of scripts
in init.d, only a few of which, might be used.
Again, it is, as simple as that.
init looks at /etc/inittab to see what to do.
the first things init does is
(fires a gui message daemon)
/etc/rc.d/rc.modules (the physical device firing of your system)
/etc/rc.d/rc.serial (normally crippled)
/etc/rc.d/rc.boot (calls rc.modules a 2nd time)
/etc/rc.d/rc 5 (run level 5, X windows)
that is the order of processing, not rc.boot as might be imagined. In fact, rc.boot calls rc.modules again to execute NON boot stuff.
A final script. rc.local is historically present in
/etc/rc.d It is
*supposed* to be run last in the boot process. The only way
however for it to run at all is via a symlink within each rc.X folder. Do not assume it runs at all.
The reason why rc.modules is first cab off the rank (apart from an arbirarty gui display) is that the very first thing rc.modules tries to do is ISAPNP. Without which, some or none of the modules it subsequently tries to load will work.
interested in /etc/modules/<version>/ DOT default
where <version> is your kernel.
Type the magic "uname -r" to find out.
NOTE: DOT default, if rc.modules cannot find that, it will try
You can _easily_ edit the wrong file !!!!
rc.modules then starts loading succesively, each item listed in DOT default using modprobe.
modprobe is smart, it checks as it loads each module and automatically loads dependant modules. Thus, half of the stuff in DOT default isn't required.
who knows, who cares.
If rc.modules discovers a module it is about to load has been pre-emptively loaded by modprobe, it ignores it.
The order of items in dot default is supposed to be
unimportant (see below). This is because it is assumed
modprobe will already load the majority of the modules in that list because they are dependent on others that modprobe will find all by itself.
The parms used for COAS
rc.modules matches each module in /etc/modules/<version>/DOT default against a potential file in /etc/modules/<version>/options/blah
if it cannot find a same-named file it looks secondly in /etc/modules/options/blah
These parms are passed directly to modprobe and over-ride anything modrobe might have inside it's own configuration file /etc/modules.conf
There is one nasty bug which affects many high level device modules. And is the cause of greif and anguish. Suppose the following sequence in dot default.
and assume opl3 is non standard (not io=0x330).
Therefore, quite reasonably, you place in /etc/modules/options/opl3the line
modprobe will load incorrectly.
This is because when 'sb' is passed to modprobe it 'knows' opl3 is required and loads it first. With wrong information. It doesn't know about the non-standard port address. When rc.modules then comes to opl3, it ignores it (and it's options) because it discovers it has already been loaded.
The hard way: check the order of loading in dot default. (specifying opl3 first, avoids the problem)
The easy way: *Always* place the same options in any /etc/modules/options/deviceinto /etc/modules.conf
That way, modprobe will load identically.