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 mrproperRecompiles 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.
$ cp /boot/config /usr/src/[version]/.config
$ make menuconfig
$ make dep
$ make bzImage (or just "make")
$ make modules
# make modules_install
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 System.map --- 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 "System.map", 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
$ cat /proc/cpuinfoI 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).
$ echo | gcc -dM -E - -march=native
compiling
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 mrproperKernel compilation varies depending on the processor speed and the number of cores. See "j" flag options for "make".
$ make menuconfig
$ make dep
$ make bzImage (or just "make")
$ make modules
# make modules_install
post-compile
Booting requires System.map and vmlinuz. And, each kernel requires its own System.map 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/System.map /boot/System.map-20090312
# 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.
LILO
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/etc/lilo.confThen to update LILO:
image=/boot/vmlinuz-20090312
label= somenameforscreen
root= /dev/sda1
read only
# lilo -v
Appendix - Cleaning source
(courtesy http://linuxgazette.net/111/krishnakumar.html)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 cleanThis 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 mrproperThis 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:
Post a Comment