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