LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (http://www.linuxquestions.org/questions/linux-software-2/)
-   -   Recompiling kernel: Getting lots of __fentry__ errors (http://www.linuxquestions.org/questions/linux-software-2/recompiling-kernel-getting-lots-of-__fentry__-errors-4175472678/)

tkalfaoglu 08-08-2013 02:27 PM

Recompiling kernel: Getting lots of __fentry__ errors
 
While building a new kernel, I'm getting lots of errors during depmod for a missing entry for __fentry__

Any ideas what this is and how to fix it?

Many thanks, -t

Example:
Quote:

depmod: WARNING: /lib/modules/3.10.4-300.fc19.x86_64/kernel/drivers/net/irda/irtty-sir.ko needs unknown symbol kmem_cache_alloc_trace
depmod: WARNING: /lib/modules/3.10.4-300.fc19.x86_64/kernel/drivers/net/irda/irtty-sir.ko needs unknown symbol __fentry__
depmod: WARNING: /lib/modules/3.10.4-300.fc19.x86_64/kernel/drivers/net/irda/smsc-ircc2.ko needs unknown symbol __fentry__
depmod: WARNING: /lib/modules/3.10.4-300.fc19.x86_64/extra/drivers/net/hamradio/6pack.ko needs unknown symbol __fentry__
depmod: WARNING: /lib/modules/3.10.4-300.fc19.x86_64/kernel/drivers/input/touchscreen/mk712.ko needs unknown symbol __fentry__
depmod: WARNING: /lib/modules/3.10.4-300.fc19.x86_64/kernel/drivers/input/tablet/gtco.ko needs unknown symbol kmem_cache_alloc_trace
depmod: WARNING: /lib/modules/3.10.4-300.fc19.x86_64/kernel/drivers/input/tablet/gtco.ko needs unknown symbol __fentry__
depmod: WARNING: /lib/modules/3.10.4-300.fc19.x86_64/extra/VirtualBox/vboxdrv.ko needs unknown symbol __fentry__

sundialsvcs 08-08-2013 04:51 PM

I have a very specific procedure for compiling the kernel:
  1. Make a copy of the (hidden) .config file, creating a new (un-hidden) dated copy of the file in a directory in /root that is set-aside for this purpose. Write-protect the copy.
  2. Temporarily rename the file (which otherwise would be destroyed in the next step).
  3. make distclean
  4. Rename the file back, reversing step #3.
  5. ... the usual make sequence.
I never vary from that. This guarantees that the build always starts from a pristine initial state, and rebuilds everything, all at once. Furthermore, placed safely out of harm's way is an exact copy of the config that was used. (If it turns out to be "wrong," I shove it into a "wrong" subfolder but keep it.) In this way I can always associate any kernel image with exactly what was used to build it, and I know that there were no residuals contributing to what wound up in /boot.

If something "goes wrong," the first thing that I do is to carefully repeat the procedure, and confirm that exactly the same ("wrong") result occurs. Then, I use diff against the current and the previous configs ... both of which I have, and both of which cannot now be altered (because I write-protected them and will never reverse that). This tells me exactly what the differences were between the two. (This usually makes the problem apparent. So I fix the problem. (And, yeah, you guessed it: "now I have three files!" My screw-up is saved for all time.)

It typically takes 5 minutes or so to do the compiles on my modest machine.


All times are GMT -5. The time now is 02:47 AM.