Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Sat, 12 Nov 2005 14:17:21 +0100 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Your clock is WAY out! "chris" <christian at dumont.homelinux.net> wrote: > My problem is that once compiled, the drbd.o driver installs itself > easily on the machine which did the compilation, but it doesn't want > to install itself on another machine. (same kernel 2.4.20.18, same > processor PII 400, same Linux version installed SME 6.0.1) Error > messages speak about symbol not resolved. Here is an example of error > message. (ex : /lib/modules/2.4.20-18.7/kernel/drivers/block/drbd.o: > unresolved symbol zone_table_R8be3c0bb ) Somehow, you are not running exactly the same kernel on the machine that you are installing DRBD on as the one you built it on. Firstly note the specific kernel versions. The kernel isn't "2.4.20.18" as you quoted, but "2.4.20-18.7", which means a 2.4.20 kernel with Red Hat (?) patches. It might sound irrelevant but it can make all the difference. Also, although I guess it's unlikely, check to make sure that your machine is not running an SMP kernel since that module is built against a uniprocessor kernel. > One of my colleague try the compilation on his own machine (same as > mine), and sent me the rpm... and then, the drbd.o didn't want to > install itself on my machine. He said me that he made his own kernel, > with module support, That's probably the problem then. If he has built his own kernel then most likely it is not *exactly* the same version, or built against exactly the same target architecture or something and thus the module symbols are different. Note in particular that vendor kernels (especially Red Hat ones) can in some cases be *very* different to the "upstream" (vanilla) kernels. If you don't believe me, install one of the Red Hat source RPMs and look at the literally hundreds of patches. That's not (necessarily) a bad thing, but it can cause problems and does mean you need to be very careful when rebuilding kernel-level stuff. > So anyone have an idea ? a) Make sure both your machines are *absolutely identical*. If you are using a package-based system (e.g. Red Hat, Fedora, SuSE, Debian) then be strict about *only* using packages (even for stuff that you rebuild yourself, especially kernels), then you won't get this kind of confusion. Forbid yourself from running "make install" as root under any circumstances whatsoever. b) Where reasonably possible stick to vendor kernels, at least for production machines; although not always ideal, it will save you a world of pain in situations like this. If you can't, build a replacement package which is as close to the vendor kernel as possible (for example, I needed a custom (newer) kernel for some Red Hat Enterprise 3 machines, so I took the Red Hat SRPM for the latest kernel, and painstakingly went through the spec file and patches to update them to a newer kernel version. It took ages, but at least we ended up with a kernel which was RPMified, exactly matched the usual vendor conventions and which we could thus install, distribute and build modules against in exactly the same way as normal) c) If you want to build stuff that is going to be used on other machines, I highly recommend having a separate "build machine" which is absolutely "clean" and which you use for nothing else except building packages on. This doesn't mean you have a buy another PC - just use some kind of virtualisation such as User-mode Linux, Xen or VMware to create a "virtual machine". I have a whole selection of VMware build machines with clean OS installs on for doing exactly this kind of thing, and it makes life a lot easier (especially when coupled to an APT or yum repository, but that's a different issue). Tim