Akmods not finding kernel source (& Kernel Module size too large in Custom Compile)

jbkt23 · #1 6th July 2009, 06:30 PM

I have been trying to get the size of my custom compiled modules to be the same size as the distro release modules. The ones that I compile are 10 to 20 times the size of the same module in comparison.
I have looked through the srpm top level Makefile for the flags passed to gcc and found that " -O2" is the default. I increased this to "-O3" with no difference. I did not see any option call for debugging.
How do I find out what the default options to gcc are, and then how do I override them to get the results I want.
Please understand I know little about programming, but I have been compiling custom kernels for 10 years now. Initially to enable hardware to work but now I am just seeing what tweaks I can make to improve performance and satisfy my curiosity.
I have perused "man gcc" to get familiar with the options available.

***Hlingler*** · #2 6th July 2009, 06:48 PM

Try prepending compiler options to whatever build command you use, e.g.:
$ CFLAGS="-O2 -pipe -m32 -march=i386 -mtune=generic" CXXFLAGS=$CFLAGS make ...

You would of course have to adjust the above options to suit your OS ARCH and so on.

'-g' switch is "include debugging", and therefore you could/should omit; '-O3' does NOT necessarily yield smaller binaries than '-O2', but rather "optimized" for speed and/or various other "optimizations".

V

P.S. You may never be able to build custom kmods to match the sizes that are compiled/included with "stock" kernels - I have not, rather, I see similar results to what you describe. Oh, well, if they work....

jbkt23 · #3 6th July 2009, 07:53 PM

Thanks Hlingler,
I did as you recommended the other night with no net change in module size. I've also diffed the .config for my kernel and the stock kernel to see if there was a telling difference and I saw nothing there.
I'm wondering what I would get if I ran "strings" on the stock module and my module. Is there a lot of commentary in mine that is stripped out by the professionals? Well tonight I will see.

sideways · #4 6th July 2009, 07:55 PM

are you compiling from a kernel source tree? if so, run make menuconfig and disable Kernel debugging in the Kernel hacking section.

jbkt23 · #5 7th July 2009, 04:17 AM

Sideways, you nailed it. I knew and in the past have disabled this. When I compared the stock config that is installed in boot the hacking debug was enabled.
I just finished compiling and the finished rpm is 1/10th the size of my previous compile. I don't know if what I compiled works but that is for tomorrow to find out.

till next

jbkt23 · #6 7th July 2009, 01:59 PM

The new kernel booted but the akmod couldn't build the nvidia driver nor could dkms build the VBox module. So I need to do some research. If I can't figure it out I'll start a new thread in a different forum.

sideways · #7 7th July 2009, 02:14 PM

Quote:

Originally Posted by jbkt23

The new kernel booted but the akmod couldn't build the nvidia driver nor could dkms build the VBox module. So I need to do some research. If I can't figure it out I'll start a new thread in a different forum.

that's because you don't have a kernel-devel package to match the custom kernel.

You can create the custom kernel and kernel-devel rpms using this guide

(basically, instead of running 'make' after the usual kernel build steps you run rpmbuild)

alternatively, create a symbolic link from /usr/src/kernels/$(uname -r) to the kernel source directory you have used to compile the kernel.

'uname -r' is just the name of the current booted kernel, which will be what you called it when compiling (usually by specifying the EXTRAVERSION in the makefile)

jbkt23 · #8 9th July 2009, 06:09 PM

I have compiled a custom kernel rpm and installed it. I created the symlinks to the source from /lib/modules/<kernelversion>/build & source. I have traversed the links to confirm they are valid. The .config and Makefile are valid for my kernel in the source directory.

When I boot into this custom kernel akmod is complaining it can't find the source and fails.
Oh, there is one other boot message that says something to the effect that the device.mapper is ???? sorry, can't remember the message verbatim. Now that I think of it I may have to remake initrd. I bind certain directory paths when I compile that don't exist after rpmbuild is done. So, initrd is looking in the wrong place.

I'll check when I get home and do a fresh mkinitrd.

***Hlingler*** · #9 9th July 2009, 06:52 PM

The question appears to be answered in sideways' last post of your other kernel-related thread: http://forums.fedoraforum.org/showthread.php?t=225820

Is there any reason why this discussion cannot be continued in the other thread?

V

jbkt23 · #10 9th July 2009, 08:32 PM

I didn't consider this a programming issue. Akmod and dkms are software that I am not compiling. Also, I've done in essence the second option that sideways suggested which has worked when I needed to compile additional modules for the running kernel. The source does exist at /usr/src/kernels/<kernelversion>

How do akmod and dkms find the sourec? Do they follow the links from lib/modules or do they look for an environment variable that is exported to the shell? Or do they search /usr/src/kernels/$uname -r ?

I'll eventually figure it out and the answer to the above questions will be of interest to the wider audience of the forum than just programmers.

***Hlingler*** · #11 10th July 2009, 12:06 AM

OK then, I've merged the two threads, moved to "Software" section, and re-titled. Send me a PM if there's any problem with any of that, and I'll fix/change it again.

In future: you can always send a PM to any on-line Staff member asking for a thread to be moved, re-titled, & etc.

V

jbkt23 · #12 10th July 2009, 03:38 AM

I've figured out from reading the logs /var/cache/akmods/nvidia/<nvidia-version>.log that akmod looks for kernel-devel-<kernel version> in the rpm data base and if it can't find it it fails. Their appears to be no way to change this behavior or pass the path on the command line. So I will have to go and build the source with rpmbuild and install it.
Dkms also looks for the kernel-devel package but the documentation indicates you can change the path to the source on the command line.

jbkt23 · #13 11th July 2009, 06:36 PM

So how do you make a kernel-devel package for a custom kernel?
There is no target to do so with rpmbuild.
Is there a way to rename the kernel-devel<nearest-kernel-version>.rpm to match my kernel name and also edit the path within the rpm to match the custom kernel?
That way I could install the rpm to the correct location and then substitute the files that differ for my custom kernel version like the .config, Makefile, system.map and I think maybe two other files.

Gödel · #14 12th July 2009, 01:17 PM

Quote:

Originally Posted by jbkt23

So how do you make a kernel-devel package for a custom kernel?
There is no target to do so with rpmbuild.
Is there a way to rename the kernel-devel<nearest-kernel-version>.rpm to match my kernel name and also edit the path within the rpm to match the custom kernel?
That way I could install the rpm to the correct location and then substitute the files that differ for my custom kernel version like the .config, Makefile, system.map and I think maybe two other files.

If you need to apply specific code patches then see http://fedoraproject.org/wiki/Docs/CustomKernel

If you are just compiling with a custom .config choice, then instead of 'make' use the rpmbuild command to build the -devel (and -firmware) packages

Install the source and make the custom .config as usual (with make menuconfig)

Code:

yumdownloader --source kernel
rpm -ihv kernel*.src.rpm
rpmbuild -bp ~/rpmbuild/SPECS/kernel.spec
cd ~/rpmbuild/BUILD/kernel*/linux*/
cp /boot/config-$(uname -r) .config
make oldconfig
make menuconfig

(ensuring you disable Kernel debugging in the Kernel hacking section as pointed out above)

Now add '# i386' or '# x86_64' to the first line of .config and copy to ~/rpmbuild/SOURCES/config-i686 or ~/rpmbuild/SOURCES/config-x86_64-generic. Then edit the kernel.spec file to uncomment the line '#% define buildid .local', (remove any spaces around the '%' so it's '%define'), change .local to .test or whatever as desired.

Now run this to generate kernel, kernel-devel, kernel-headers and kernel-firmware: (for a multithreaded compile use alias make='make -jN' where N>=2, the number of threads)

Quote:

rpmbuild -bb --target=$(uname -m) --with baseonly --with firmware --without debuginfo ~/rpmbuild/SPECS/kernel.spec

and the rpms will end up in ~/rpmbuild/RPMS/$(uname -m)

jbkt23 · #15 13th July 2009, 06:02 PM

I did has Godel outlined and the build provided the kernel, kernel-devel, kernel-firmware and kernel-header packages. I have not installed them because I need to go back and tweak the configs.

One question I have is why does the "bb" option rebuild the sources that were already built for the target platform with the "bp" option when I initially installed and configured the source? It seems a waist of clock ticks and created some problems because I didn't anticipate that.

Is there a way to prevent rebuilding the source again?