Log Errors

[Brian Witowski]

Mike,

Thanks for that explanation!  Most of the docs out there tell you what to do
and when to do it but they don't tell you why!  I need to know the 'nuts and
bolts'.  Once I know that, I can fix anything myself.

I am indeed running 2.4.18.  I recompiled my kernel last night and went
through xconfig slowly and deliberately.  And guess what?  Even though I
didn't compile in sound, I was getting a char-major-14 error in my logs.  I
read at another site on the web that even though sound isn't compiled in, it
will generate those errors if an application attempts to use sound.   It
also advised putting 'alias char-major-14 off' in my modules.conf file to
stop the error from appearing in my logs.

Now that is something nobody else ever suggested.  An app would try to use
sound, which would in turn try to load a module that didn't exist and thus
create an error.  The end result being there is nothing wrong with my kernel
or the way I compiled it.  That of course doesn't explain all of the errors
(the rtc thing was my fault) but it does suggest we shouldn't jump to
'compile errors' as a first resort.

Thanks again for your detailed explanation.

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.
>
>
>
>