[DRBD-user] insmod drbd.o >>>> unresolved symbol

Tim Jackson lists at timj.co.uk
Wed May 11 13:42:01 CEST 2005

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, 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 "" 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).


More information about the drbd-user mailing list