Monday, March 30, 2009

slackware 12.2 - kernel recompile

Last edited: 2013/05/03
Links: slackware compile simple   good: includes LILO   full Debian   gentoo instructions w/LILO   arch instructions   kernel performance
Kernel builds are straightforward and can be done in user mode in /usr/src/[version]
$ make mrproper
$ cp /boot/config /usr/src/[version]/.config
$ make menuconfig
$ make dep
$ make bzImage (or just "make")
$ make modules
# make modules_install
Recompiles are mostly the same, but we use same source version repeatedly. That is, each recompile uses source with the same version number. That causes a modules problem.

the problem and solution

A problem with using the same version source repeatedly is that modules are installed according to kernel version numbers. The modules go into /lib/modules/[version]. We don't want modules for each recompile overwriting or mixing with the prior recompile. We want a unique directory for each build's modules. How do we do that? We could just change $MOD_INSTALL_PATH, in the Makefile. However, we also need our new kernel to be able to find its modules. A better option then, is to change $EXTRAVERSION to something unique. This will then be incorporated into $KERNELRELEASE, and everything downstream -- the module directory, and pointers to those modules within --- will be properly named and installed. So, before running "make menuconfig", change the top-level $EXTRAVERSION (or occasionally "$EXTRAVER") variable in Makefile to a different suffix for each build. Before running "make", double check the Makefile for your identifier. There is also apparently an option for "local version" suffix creation within the make menuconfig process beginning with kernel 2.6.

Note: to examine the running kernel settings in a GUI without changing the settings, run "make xconfig". This displays the configuration of the booted kernel. Select "discard changes" before exiting. To do the same in an ncurses CLI interface, the command is "make menuconfig" (also discard changes when exiting).

Other - unintended effects

There's a small chance one's video drivers or other hardware will act odd with the new kernel and modules. It's therefore worthwhile to back-up the old modules in case one needs to use the old kernel. If one recompiles GLibC, it's nearly certain some applications will have to be recompiled.

Other - what is /boot/vmlinuz?

When bzImage is created in /usr/src/[version]/arch/i386/and we copy the bzImage to /boot, we change its name. The file is the same, but we change it to "vmlinuz". We also append a suffix to its file name to distinguish it from other kernels in /boot. For example, we might title it "vmlinuz-20120604" or "vmlinuz-test". We add this same suffix to the "config" and "", files for that build when they are copied to /boot.

pre-compile: patches, optimizations, modules

Patches are accomplished prior to opening the configuration files; they potentially expand the kernel options with new features. To patch, put the patch in the same directory as the source, consider the level for "p" (in this example I'll use "1") and:
$ patch -p1 < patchname

For optimizing the kernel, hardware information: # lshw or # lspci. Save this to a file, and print it. For example, I have one older laptop with
    AMD Athlon(tm) X2 Dual-Core QL-60 64 bits, 1900MHz,L1 256 capacity, L2 2x512KB capacity
It appears the processor will be able to run an i686 instruction set (using amd 64 / i686). Instruction sets are backwards compatible to 386,486,586. It's also worth reading here about CFLAGS (SLKCFLAGS for Slackware) CHOST, and so on, for compilation notes, since the compilation of the kernel is just another compile. Also examine these two
$ cat /proc/cpuinfo
$ echo | gcc -dM -E - -march=native
I save march info to the lshw file. Of course, we can adjust the march to something forced, but it's valuable to start with examining what's automatically selected (by gcc).


So "vmlinuz" is simply "bzImage" renamed and copied into /boot. If we compile using the standard make install technique, the vmlinuz file in /boot will be overwritten during that step. Instead, use make (or make bzImage) without "install". Later, we'll manually copy the new kernel, "bzImage" into /boot, changing its name to, say, vmlinuz_20090312 as we do so, and preventing overwrites.
$ make mrproper
$ make menuconfig
$ make dep
$ make bzImage (or just "make")
$ make modules
# make modules_install
Kernel compilation varies depending on the processor speed and the number of cores. See "j" flag options for "make".


Booting requires and vmlinuz. And, each kernel requires its own file. These both need to be in /boot. Also the ".config" file should be placed in /boot for future reference. Make them easy to locate within /boot. Eg, supposing the unique identifier for that build were "20090312", then I would move the files to /boot from /usr/src/linux/) as
# cp /arch/i386/bzImage /boot vmlinuz-20090312
# cp /usr/src/linux/ /boot/
# cp /usr/src/.config /boot/config-20090312
# rm /boot/vmlinuz
# ln -s /boot/vmlinuz-200903312 /boot/vmlinuz

Double check kernels, System.maps, config files and proper softlinks within /boot.


If you're certain about a single kernel, a single softlink named "vmlinuz" to that kernel will work, as just described. LILO needn't be changed. However, if wanting to select between multiple kernels at boot time, LILO needs additional entries. The one we have been doing above would be added as
  label= somenameforscreen
  root= /dev/sda1
  read only
Then to update LILO:
# lilo -v

Appendix - Cleaning source


After we have initiated compilation once on the source if we want to clean the object files and other temporary files then we have to run the following:
make clean
This will remove most generated files but will keep the configuration file. If we need an absolute cleaning, i.e. if we want to return the source to the state in which it was before we started the compilation, then do a
make mrproper
This command will delete all generated files, the configuration file as well as various backup files. This will in effect unwind all the changes we made to the source. The source after this step will be as good as it was just after the download and untar.

No comments: