One more note, I'm using grub, not lilo. Brian
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Andrew > Sent: Friday, March 22, 2002 12:13 AM > To: [EMAIL PROTECTED] > Subject: Re: Log Errors > > > > --- Brian Witowski <[EMAIL PROTECTED]> wrote: > > > Where is it determined that it would be looking in > > > /lib/modules/2.4.2... > > From: "Net Llama" <[EMAIL PROTECTED]> > > > 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. > > > > _______________________________________________ Linux-users mailing list - http://linux-sxs.org/mailman/listinfo/linux-users Subscribe/Unsubscribe info, Archives,and Digests are located at the above URL.
