Log Errors

[Brian Witowski]

One more note, I'm using grub, not lilo.

Brian

> -----Original Message-----
> From: linux-users-admin at linux-sxs.org
> [mailto:linux-users-admin at linux-sxs.org]On Behalf Of Mike Andrew
> Sent: Friday, March 22, 2002 12:13 AM
> To: linux-users at linux-sxs.org
> Subject: Re: Log Errors
>
>
> > --- 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.
>
>
>
>