Results 1 to 4 of 4
Thread: My custom-built kernel is huge!
Enjoy an ad free experience by logging in. Not a member yet? Register.
My custom-built kernel is huge!
As a part of a project, I need to tweak the kernel configuration and apply a minor patch to a few of the source files.
I did the following (based mostly on the /usr/src/linux/README.SUSE file):
- Copy the source tree to my home directory:
$mkdir -p ~/builds/kernel/linux-3.0.26-0.7/src $cd ~/builds/kernel/linux-3.0.26-0.7/src $cp -R /usr/src/linux-3.0.26-0.7/* .
- Clone the running system's configuration and then launch menuconfig to tweak that:
$make cloneconfig $make menuconfig
- Make the following changes to the configuration
- Change the local version string
- Enable the TCP MD5 option
- Enable IPv6 multicast routing
- Eanble IPv6 multicast multi-table support
- Enable IPv6 PIM-SM
- Make my changes to the sources
- Build and install and make RPMs
$make $make modules_install $make install $make rpm-pkg
When I do this, the kernel I get is gargantuan compared to the binaries provided by SUSE, even though I am supposedly using the same configuration they used.
- Their /lib/modules directory is about 91M, while mine is 1.8G
- Their /lib/modules/kernel/drivers directory is about 60M, while mine is 1.3G
- Their /lib/modules directory contains 2167 files while mine has 3772
- Individual module files are much larger. For example, their kernel/drivers/net/e1000/e1000.ko is 260K while mine is 2M.
- Their initrd file is 7.1M while mine is 14M
- Their vmlinuz...gz file is 4.3M while mine is 43M
- The RPMs generated don't match. SUSE provided kernel-default, kernel-default-base, kernel-devel, and linux-kernel-headers. I got only two (kernel- and kernel-headers)
- The sum total of the SUSE-provided kernel RPMs (kernel-default, kernel-default-base, kernel-devel and linux-kernel-headers) is about 38M. The sum of the two kernel RPMs I got is about 321M
I assume that my build is packed full of debug info and theirs isn't. Are there alternate make targets I should be using?
If there are no magic command line parameters to give make, then it would appear that the config file I extracted from /proc/config.gz is not the one SUSE used to compile their kernel. Or at least not for compiling all the modules.
What should I change in the configuration to bring my build down to a reasonable size? There are many symbol/debug options, but I don't want to just go randomly flipping switches trying to find the magic combination SUSE used.
- Copy the source tree to my home directory:
- Join Date
- May 2011
i am sure you are right and it is the debug info. i don't know of any way to disable the debugging stuff except for via running config (or xconfig, etc.). it used to be under Kernel Hacking, i think, but i'm sure a google search would unearth it.
After more investigation, it appears that I've tripped into a rats nest here!
I was working with sources installed from the kernel-source-<version>.rpm file, which installs sources in /usr/src/linux-<version>
As it turns out, however, that's not what SUSE uses to build their kernels. They have another package: kernel-source-<version>.src.rpm, which installs tarballs and patch files in /usr/src/packages/SOURCES and an rpmbuild spec in /usr/src/packages/SPECS. And two more packages (kernel-default-<version>.nosrc.rpm, and kernel-syms-<version>.src.rpm) which add more scripts and rpmbuild stuff.
When I run rpmbuild against one of these specs, the script unpacks the tarball into a directory under /usr/src/packages/BUILD, applies patches, compiles, performs all kinds of post-processing, and then makes the RPM.
It's in that post-processing where they seem to be performing all kinds of magic hackery with debug symbols. I'm not exactly sure what the script is doing, but it seems to be selectively copying debug symbols into separate files (perhaps for creating the kernel-syms package) and then stripping them from the executable files.
Unfortunately, adding my own tweaks to this may be painful. There's a common tarball where they store config files and I can put my own in there, but any changes to the sources is going to require adding a .patch file and figuring out how to tell their scripts to apply it. If I just make the "prep" phase of rpmbuild to extract the sources, my changes will be blown away when I run rpmbuild to complete the process. (Unless there's a way to make rpmbuild perform the build/install/package stages, skipping the prep stage. I don't yet know if there is a way.)
One more followup: It appears that it's not too hard to add custom patches to the SUSE build system.
In /usr/src/packages/SOURCES, there is a patches.addon.tar.bz2 tarball. It normally only contains an empty patches.addon directory. You can, however, put your own .patch file (in git format) in there, along with a "series" file naming the patch file. Doing so causes the SUSE rpmbuild script to apply your patch to the sources as a part of its build process.
So..... I went back to my build tree where I developed my changes, did a "git diff" and saved the result as a patch file. Put that in patches.addon.tar.bz2 and voila. The SUSE packages are now being regenerated with my changes.
I'm sure all this is documented somewhere (probably as a part of the OpenSUSE project) but I'm just glad to have figured it out.