[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

2.2.13 - modules - failed dependancies




Okay...this I've been racking my mind over and still haven't got an answer. 
This Dell Poweredge we have at work - it runs Redhat 6.1 Deluxe, and comes 
with a 2.2.13 kernel (dunno if RH have modified it so it has RH specifics). 
Now...I've had to do a recompile (lots of options to take out, others to put 
in, and knock processor from i386 to PIII). But...I'm getting a right host of 
annoying dependancy problems. For example, the following:

insmod lp: (mostly fails due to parport.o not being in, but see below)
./lp.o: unresolved symbol parport_claim_or_block_Rsmp838a926d
./lp.o: unresolved symbol parport_release_Rsmpaf96f96f
./lp.o: unresolved symbol parport_register_device_Rsmp89eb5971
./lp.o: unresolved symbol parport_unregister_device_Rsmp69396e60
./lp.o: unresolved symbol best_copy_from_user
./lp.o: unresolved symbol parport_enumerate_Rsmp0594a49a

insmod fat:
/lib/modules/2.2.13-0.13/fs/fat.o: unresolved symbol best_memcpy
/lib/modules/2.2.13-0.13/fs/fat.o: unresolved symbol best_memset
/lib/modules/2.2.13-0.13/fs/fat.o: unresolved symbol best_copy_to_user
/lib/modules/2.2.13-0.13/fs/fat.o: unresolved symbol best_copy_from_user

insmod loop:
/lib/modules/2.2.13-0.13/block/loop.o: unresolved symbol best_memcpy
/lib/modules/2.2.13-0.13/block/loop.o: unresolved symbol best_memset
/lib/modules/2.2.13-0.13/block/loop.o: unresolved symbol best_copy_to_user
/lib/modules/2.2.13-0.13/block/loop.o: unresolved symbol best_copy_from_user

insmod parport:
./parport.o: unresolved symbol best_memset

Yes, they are fresh modules with the kernel build (I checked the 
timestamps)...I've copied System.map into /boot...but this always pops up. 
depmod has a right fit, with over 100 modules failing dependancies. I will 
eventually take most of them out, but I just can't see at the moment why its 
failing so much. The important stuff (SCSI and network) I've ended up 
building into the kernel directly else the machine would be useless.

The kernel is an SMP PIII kernel (Dual PIII 500) with enough memory (512MB) 
and disk (well over 100GB) to see it through without a problem. On the plus 
side, a kernel builds in 10 mins or so (be quicker once all the modules are 
out), which is nice :) I want to resolve this though - if not a problem now - 
it is something I want to resolve in my own mind...I've done more than the 
odd kernel rebuild in the past and I've never had this problem with it, so 
any help would be appreciated :)

Thanks,

Chris...


-- 
@}-,'--------------------------------------------------  Chris Johnson --'-{ [at] 
    / "(it is) crucial that we learn the difference / sixie [at] nccnet.co.uk  \
   / between Sex and Gender. Therein lies the key  /                       \ 
  / to our freedom" -- LB                         / www.nccnet.co.uk/~sixie \ 


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.