Log Errors

[Mike Andrew]

> > --- Brian Witowski <brianw at torchlake.com> wrote:
> > > Where is it determined that it would be looking in
> > > /lib/modules/2.4.2...
>
> From: "Net Llama" <beemer9 at yahoo.com>
>
> > Well, Caldera has an ass-backwards modutils, which i believe looks in
> > /etc/modules/default
>
 I've been following this thread. It would seem to me that you are not
booting the kernel you think you are, OR, you never booted the (new) kernel
that you previously thought you did. And the answer is really simple, you
did some minor thing to make things different just a few days ago, only you
can't (obviously) see the connection between the events because you're
assuming, quite wrongly as it turns out, that the compile went 'ok', it did
not, and llllama hit the target first time because all messages about unable
to find a heap of char major anythings are kernel miscompiles. More
correctly: it's symptomatic of not including some kernel options in an
otherwise good compile.

first thing to do is

 uname -r

 this will tell you unreservedly THE kernel you have currently booted.
 Chances are high that you have a misconfigured lilo.conf (not having a shot
 at you, am covering some non-obvious bases).

 To answer your above question, kernd (the kernel module daemon within the
 kernel) passes requests to modprobe to find it's modules. It is modprobe
 which determines which /lib/path to use. It is fixed in concrete that it
 will be /lib/modules/<uname -r>, unless specifically over-ridden (as likely
 as hell freezing over).

 Caldera's /etc/modules is chalk and cheese, /etc/modules/ is simply a (very
 sensible) method of supplying a one-stop shop for ALL modules to be loaded
 at boot time, it is a look-up list written against Caldera's version of the
 /etc/rc.d/sysinit scripts, not _the_ modules, and is agnostic to kernel
 versions (again, unless hell freezes over, Col 2.2 is version sensitive,
the
 others are not).

 Using poetic licence, the actual modules created are derived from
 /usr/src/linux/<uname -r>/modules. This directory is created on the fly
from
 /usr/src/linux/<uname -r>/drivers during compile time (and destroyed at
 'make modules" incantation).

 'make modules_install' copies these binaries to the correct
/lib/modules/<newkernel uname -r> path and then runs a fudged depmod -a to
correctly sync this stuff. That bit has never worked as advertised for
reasons no-one has ever been able to explain to me. As a result, all distros
I am aware of run a hidden depmod -a at boot time. Each distro hides this in
a different way, but the end result is identical, depmod (the modprobe
generator) _guarantees_ that the modules the booted kernel wants, are
indexed correctly. 'Correctly' means depmod is going to scream blue murder,
at boot time, if it can't find THE location of _the_ kernel version modules.

That doesn't mean all modules are 'ok' it means it can find them. So to
answer a question you were thinking, there is no way on the planet that
kernel-2.4.18 will use anything other than /lib/modules/2.4.18. And contra,
no way on earth kernel 2.4.10 will use 2.4.18 compiled modules (There are
if's and but's to that statement, but you can take it at face value).

 As far as deleting /usr/src/anything, the answer is: irrelevant to the
problem. /usr/src/linux is not used at any time by the kernel or it's
friends. It is simply a convenient hole in the ground to compile, well gee,
user / source. Anything required from /usr/src/ is, as stated above, copied
out of there, in the expectation that you will indeed delete /usr/src at
some future date.

 To get back to Lllllllllllllama's original reply, he is spot on. You don't
in fact have an issue with any of the above, it will all work as advertised
and you aint gone done broken it. The truth is,  you've missed out a few
options on the compile. See the SxS which contains fairly bullet proof gif
images of each dialog box during 'make xconfig', or, use Keith's equally
good text based version.