Configure, Build and Install a Custom Linux Kernel

From openSUSE

Version 10.3.

By: sgt-d / mailto:sgt-d

Credits: Thanks kukks, stittle and M3phistopl3s for assistance in irc#opensuse-chat

Live Support: irc#opensuse

Status: 20071125 1.05 Rough Draft

Introduction

About this Guide

This guide is simplified and targeted for beginners, not veterans, but should work fine for everyone.

The first half of this guide is mostly notes and information to help prepare you for some possible issues or problems that you might have along the way. Please take some time to read through all of the notes so you are prepared.

I have chosen to use the recommended tweaks for "Enemy Territory Quake Wars" (ETQW) for use in this guide to provide a basic example of how to make changes to an existing kernel configuration.

Many people claim that the tweaks mentioned for ETQW are not necessary and that you don't have to build a custom kernel if you have bleeding edge hardware. There is also a precompiled RT kernel that meets the ETQW recommendations already.

Overview

We will install the latest possible openSUSE kernel and kernel source, then we will boot to the new kernel.

If everything works correctly with the new kernel, we will then copy the currently loaded (and newest possible) kernel configuration for use as the initial configuration for the custom kernel we are going to build.

Finally we will configure, build and install the new custom kernel and then boot from it.

In the end, your system should work identically as before except now it will have a decent performance boost and the recommended settings for ETQW.

From the ETQW Readme

You need a low latency kernel for optimal performance (this applies to both client and server installations).
Make sure your kernel is configured with CONFIG_HZ=1000 and CONFIG_HZ_1000=y.
You should also enable other low latency settings, such as the various preemption settings.
Kernel 2.6, configured for 1000Hz tick and other low latency settings.

References

The official readme for working with the 2.6.x linux kernel can be found in: /usr/share/doc/packages/kernel-source/README.SUSE. This file is only available if you installed the kernel sources.

I have also added the official readme for reference here:

http://en.opensuse.org/Official_openSUSE_Kernel_2.6.22.12-0.1_Readme

Realtime (RT) Kernel Instructions are HERE: http://en.opensuse.org/Rt_Kernel_Instructions

Notes

The remainder of this page is currently unofficial. Mileage may vary.

This document was prepared for openSUSE 10.3 - ONLY.

At the time of this writing, the current openSUSE Linux Kernel version is linux-2.6.22.12-0.1. This exact version (2.6.22.12-0.1) will be used throughout this howto for all of my examples. This version may not match your kernel version. Substitute your kernel version wherever you see '2.6.22.12-0.1' below.

Development Packages

All developer packages (binutils, make, gcc, and preferably ncurses-devel) must all be installed (and updated - next section) before you proceed.

In YaST Community Repositories, add the openSUSE 10.3 Update Repository:

http://download.opensuse.org/update/10.3/

In YaST Software Management, select "Patterns" from the "Filter" drop-down selector (top left).

Check these:

Base Development
C/C++ Development
Linux Kernel Development

Also locate and install the main Xorg/X11 Development packages such as xorg-x11-devel if you cannot use the ncurses frontend and need a pixel-based GUI for the kernel configuration.

System Updates

Make sure your system is as close to 100% current as humanly possible. Install all updates, particularly the newest kernel(s), kernel-source(s) and developer packages before attempting anything on this page.

In YaST Community Repositories, add the openSUSE 10.3 Update Repository:

http://download.opensuse.org/update/10.3/

Then use YaST Online Updates (YOU) to install all possible updates.

After that, use YaST Software Management to upgrade all of the items mentioned at the top of this section.

Important: If you have a kernel update available in YaST Online Updates (YOU), you should install it ASAP, including the newest possible kernel sources. After installing the updated kernel, you must reboot using the new kernel before proceeding. Doing this will guarantee that the custom kernel you are going to build later will be based on the newest possible openSUSE kernel and sources.

Notices

Important: Make sure you keep a working version of the openSUSE -default kernel installed.

Before you start... realize that the first time you boot from your new kernel you will probably see a very small number of new "red" error/failed messages. These new errors will probably be normal and should be limited to a few third party applications that (in the past) had installed their own custom kernel modules.

Examples: NVIDIA, ATI, VirtualBox, VMware, and possibly others.

Fixing these things after the new kernel is installed and being used is covered below in the section titled "Step 9 - Fixing Things".

Aside from these errors which are expected, if you see other failed messages during the boot process it could indicate that there is serious problem with the new kernel and that it might not be usable at all.

Video Drivers / Kernel Modules

If you have installed NVIDIA or ATI video drivers, please pay close attention.

If you installed your video drivers from the online repository or from a 1-click installer, you may not have to do anything for your drivers to work correctly after booting the new kernel. While I know this is true for official kernels (they always keep the video drivers on the online repositories current with the newest official kernels), I cannot guarantee the same will hold true for a custom built kernel - even though it will be "based" on the official kernel.

You should strongly consider changing your video driver in /etc/X11/xorg.conf back to the STOCK (original) video driver that was setup by openSUSE during installation. Typically the stock driver would be "nv" for NVIDIA users and either "radeon" or "vesa" for ATI users. I have no clue what to tell you for any other cards/chipsets other than: "good luck". Making this change to your xorg.conf means that when you boot your new kernel, graphical mode (runlevel 5) will work the way it did when you first installed openSUSE (without a third party video driver). The custom drivers won't be installed, but at least you won't be stuck in text mode (runlevel 3) on your first boot with the new kernel. This is particularly helpful for people that rely heavily on "easy" solutions such as the "1-click" installers. 1-click users might need to rerun the 1-click installer to install their drivers after booting to the new kernel.

If you do not change back to the stock video driver, your first boot with the new kernel might drop you into runlevel 3 (text mode) until you reinstall the kernel module for your video drivers, or reinstall the drivers. This is normal/expected/fine for advanced users, or for people that have been manually installing NVIDIA/ATI drivers for years.

So, heads up! Advanced users might want to download the NVIDIA/ATI drivers and place them in a known location before doing anything else.

Rebuilding video driver kernel modules and installing video drivers after the new kernel is installed and being used is covered below in the section titled "Step 9 - Fixing Things".

Proceedures

Step 1 - Kernel Sources

If you haven't already done this, do it now:

In YaST Community Repositories, add the openSUSE 10.3 Update Repository:

http://download.opensuse.org/update/10.3/

The most current kernel and kernel sources are always located here:

http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/

Use YaST Software Management to install the EXACT kernel source package that matches your currently installed and running kernel, most likely from the openSUSE 10.3 Update Repository.

Informational: The /etc/sysconfig/kernel file is read to determine what modules will be used/built.

If you did upgrade your kernel in this step, check your /boot/grub/menu.lst file to make sure it looks right, then reboot your computer now and make sure you are using this new kernel.

Step 2 - Prepare

Final reminder... if you have not rebooted using the newest possible openSUSE linux kernel, stop what you are doing and boot to the new kernel NOW.

Open a terminal and type 'su' (plus your password) to become root. You will be here for awhile, so get comfortable.

su -

Make a backup of your menu.lst file, eg:

cp /boot/grub/menu.lst /boot/grub/menu.bak

Important: The /usr/src/linux symlink should be pointing to the current kernel source. Please verify that with this command:

ls -l /usr/src/linux

You should see something like this:

lrwxrwxrwx 1 root root 19 2007-11-08 15:10 /usr/src/linux -> linux-2.6.22.12-0.1

Do not perform the next step unless it is absolutely needed. If the link shown above is not pointing correctly to your kernel source, you may need to fix it manually, example:

ln -sf /usr/src/linux-2.6.22.12-0.1 /usr/src/linux

You will have to copy linux-2.6.22.12-0.1 to another directory, or else you will be making it impossible to build 3rd party modules for the SUSE-provided 2.6.22.12 when you run cloneconfig inside it.

cp -a linux-2.6.22.12-0.1 linux-my

Step 3 - Configure

NOTE... Many people suggest to SKIP the "make cloneconfig" step (between SKIP and END SKIP). Do what they say. I skipped this and had NO problems! Note however that you will then not necessarily start with the current configuration from /proc/config.gz.

cd /usr/src/linux-my
make clean
make mrproper

SKIP

make cloneconfig

Note: The 'make cloneconfig' command copies your currently running kernel configuration to:

/usr/src/linux/.config

END SKIP

Open the configuration UI:

make xconfig

Or for a GTK based configuration UI:

make gconfig

or for an Ncurses based configuration tool:

make menuconfig

Note: I prefer the graphical configuration (qconf), so I always use 'make xconfig'.

This will open the configuration screen so we can begin making changes. Please note, the current options that you see checked are what you kernel is currently using... this information was supplied when we used 'make cloneconfig' (above).

Step 4 - Customize

Make sure to change the "Local Version Release String"!

Changing the release string is extremely important. If you don't change it, your new kernel and modules will overwrite the '-default' kernel and modules. We do NOT want that to happen. I used '-sgt' for my release string, so when I was done building and installing, my kernel and modules had a '-sgt' suffix, not '-default'. Example:

vmlinuz-2.6.22.12-0.1-sgt

In xconfig or menuconfig:

Change all settings needed. Again, in this guide I am only focusing on the recommended changes for ETQW.

I didn't see any "other" preempt options than the ones I have shown below, there might be more.

The settings shown below now include additional optimizations. The new HPET settings that are shown are pretty much default for 64bit, but the new "Tickless System", "High Resolution Timer Support" and some of the HPET settings are disabled by default on 32bit. For best performance you should use the settings shown here.

General setup
  Local version - append to kernel release
  - Double click on this to change it
  - Do NOT skip this step!
  - Enter a 'dash' (-) and a string value, eg: -sgt or -etqw

Processor type and features
  (x) Tickless System (Dynamic Ticks) (NO_HZ) (32bit Only)
  (x) High Resolution Timer Support (HIGH_RES_TIMERS) (32bit Only)
  Processor family
    Make sure your processor family is checked, mine were:
      Home:  (x) AMD-Opteron/Athlon64 (MK8) (or: Generic-x86-64 (GENERIC_CPU))
      Work:  (x) Pentium-4/Celeron(P4-based)/Pentium-4 M/older Xeon (MPENTIUM4) (or: 586/K5/5x86/6x86/6x86MX (M586))
  (x) HPET Timer Support (HPET_TIMER) (32bit Only)
  Preemption model
    (x) Preemptible Kernel (Low-Latency Desktop) (PREEMPT)
  [*] Preempt The Big Kernel Lock (PREEMPT_BKL)
  Timer frequency
    (x) Timer frequency (HZ) <- 1000

Device Drivers
  Character devices
    (x) HPET - High Precision Event Timer (HPET)
    (x) Allow mmap of HPET (HPET_MMAP)
    ( ) HPET Control RTC IRQ (HPET_RTC_IRQ)

Make sure that you save the config.

Make a backup of your kernel configuration:

cp .config .config.bak

Step 5 - Verify Release Info (Skip)

M3phistopl3s told me today NOT to use 'make prepare' with openSUSE kernels.

I do not know what the implications of this command are, but I am researching it. (They are: inability to build modules for the kernel you ran cloneconfig in. Cheers. So don't do that.)

If you are 100% certain that you set your "Local Version Release String" correctly in "Step #4" (above), it is SAFE to skip this current step (Step #5) entirely.

I will say that I ran this command several times and didn't have any problems with it, but you should avoid Step #5 until further notice.

--- SKIP TO STEP #6 ---

I am leaving the next few lines here for future reference, you should skip to Step #6 now.

The only thing the next commands do is verifies that a unique release string is being used.

make prepare
make kernelrelease

Example (my) output after running these commands:

2.6.22.12-0.1-sgt

If the release string is not displayed correctly, re-run 'make xconfig', add a release string or fix the problem(s), save, then run 'make prepare' and 'make kernelrelease' again.

Do not continue unless the release string is displayed correctly!

</ignore>

Step 6 - Build

make

This will build the kernel and all modules and it will take some time to complete. The build process can take anywhere from 20 to 60+ minutes.

Step 7 - Install

Everything was built in the previous step, now we have to install it.

We are down to two final commands...

Install the modules:

make modules_install

Note: 'make modules_install' will install modules to:

/lib/modules/2.6.22.12-0.1-your_release_string

Example:

/lib/modules/2.6.22.12-0.1-sgt

Install the kernel:

make install

Step 8 - Confirm and Boot

Verify that the new /boot/grub/menu.lst looks correct, example:

Note: Do NOT use this info in your menu.lst, this is just an example...

title openSUSE 10.3 [sgt] - 2.6.22.12-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.12-0.1-sgt root=/dev/hda1 vga=0x31a resume=/dev/sda1 splash=verbose showopts
initrd /boot/initrd-2.6.22.12-0.1-sgt

Take a quick look at your /boot directory/partition and make sure you see your new '-release' kernel, system map and initrd there, example:

/boot/initrd-2.6.22.12-0.1-sgt
/boot/System.map-2.6.22.12-0.1-sgt
/boot/vmlinuz-2.6.22.12-0.1-sgt

If your menu.lst file looks good, and you see your new '-release' files (shown directly above) in /boot, restart your computer and boot to your new custom kernel!

Step 9 - Fixing Things

During the first boot from your new kernel you probably saw a very small number of new "red" error/failed messages. These new errors are probably be normal and should be limited to a few third party applications that (in the past) had installed their own custom kernel modules.

Examples: NVIDIA, ATI, VirtualBox, VMware, and possibly others. TrueCrypt didn't seem to complain when I used my new kernel.

NVIDIA Fix after Kernel Update

If you are NOT stuck in terminal mode (runlevel 3) when you boot up, and you want to rebuild the NVIDIA kernel module, you will need to do this first:

su -c "rcxdm stop"

or

su -c "init 3"

Either of those commands will drop you to text mode on TTY1.

If you ARE stuck in terminal mode, simply login on TTY1 as ROOT.

Rebuild the NVIDIA kernel module using the installer with the -K option:

su -c "sh NVIDIA-Linux-x86_64-100.14.23-pkg2.run -K"

After the manual rebuild / reinstallation of the NVIDIA or module or drivers, simply type:

su -c "rcxdm start"

or

su -c "init 5"

Either of the commands above will restart your normal X session on VT7.

For more help with NVIDIA drivers, please visit the openSUSE NVIDIA Page:

http://en.opensuse.org/NVIDIA

ATI Fix after Kernel Update

Unknown. I am assuming that if you installed via online repositories or using a 1-click installer, you might not have to do anything... it may just work on it's own. If not, you may have to reinstall or re-1-click.

For more help with ATI drivers, please visit the openSUSE ATI Page:

http://en.opensuse.org/ATI

VirtualBox Fix after Kernel Update

su -c "/etc/init.d/vboxdrv setup"

VMWare Fix after Kernel Update

su -c "/usr/bin/vmware-config.pl"

Informational

What I saw during installation...

wenix:/usr/src/linux # make install
sh /usr/src/linux-2.6.22.12-0.1/arch/x86_64/boot/install.sh 2.6.22.12-0.1-sgt arch/x86_64/boot/bzImage System.map "/boot"
Kernel image:   /boot/vmlinuz-2.6.22.12-0.1-sgt
Initrd image:   /boot/initrd-2.6.22.12-0.1-sgt
Root device:    /dev/disk/by-id/scsi-SATA_WDC_WD2500JD-00WD-WMAEP2899549-part2 (/dev/sdd2) (mounted on / as ext3)
Resume device:  /dev/sda1
Kernel Modules: processor thermal scsi_mod libata pata_amd sata_nv fan jbd mbcache ext3
edd sd_mod usbcore ohci-hcd uhci-hcd ehci-hcd ff-memless hid usbhid
Features:       block usb resume.userspace resume.kernel
Bootsplash:     SuSE (1280x1024)
47368 blocks

My menu.lst...

title openSUSE 10.3 [sgt] - 2.6.22.12-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.12-0.1-sgt root=/dev/hda1 vga=0x31a resume=/dev/sda1 splash=verbose showopts
initrd /boot/initrd-2.6.22.12-0.1-sgt

After booting to my new kernel...

sgt-d@wenix:~> uname --all
Linux wenix 2.6.22.12-0.1-sgt #1 SMP PREEMPT Mon Nov 12 21:18:18 CST 2007 x86_64 x86_64 x86_64 GNU/Linux

Extras

Automate the Build Process

To help with the build process here is a script to run all the make commands needed

#!/bin/bash
echo "Starting kernel build. Please be Patient this will take at least 20 minutes."
echo "We advise you refrain from using your system till the cycle is complete. Thank you"
make && make modules_install && make install

save it as runmake.sh. To run it, change to the source directory using 'cd' and then run it using the full path to the script, like this

sh /home/meph/configs/kernel/runmake.sh

User changeable parameters

Credits for this part:

FIXME Tell user what the files are and which to use.
FIXME Indicate which ones MUST be set and which ones have intelligent defaults.

If set to YES, the script will get the kernel source if it is not already on the drive. If the user chooses NEWESTSTABLE, NEWESTBETA, or NEWESTPCMCIA, this is forced to YES later on.

Only choices (default YES): BKAUTOGET=NO BKAUTOGET=YES

If you have a preferred build type, set it here. Otherwise, leave it at the default. I suggest zImage. The script will automatically try building "b"+whatever_you_chose if the first build failed. Unless you know the target machine has problems with bzImage, I'd leave this at bzImage.

Examples (default bzImage): BKBUILDTYPE=zImage BKBUILDTYPE=zdisk

If you would like to have the kernel also copied to a floppy at the end, set the following to YES and uncomment (for this, you should have a floppy in the floppy drive during the entire run). The floppy _should_ not be mounted (i.e., when you type "mount", /dev/fd0 should not show up in the listing).

Only choices (default NO): BKCOPYTOFLOPPY=NO BKCOPYTOFLOPPY=YES

Uncomment and set to YES if debugging; generally no need to do so. Only choices (default NO): BKDEBUG=NO BKDEBUG=YES

If you want buildkernel to automatically download the kernel source tree and have a preference for a server, set it with this parameter. If you're in a country other than the US, I would strongly suggest setting this to a mirror site closer to you. Better yet, set up a local kernel mirror and use that!

The server you use must publish the kernel .tar.gz's or .tar.bz2's via ftp under the /pub/linux/kernel/vX.Y/ directory - the standard directory structure for a kernel mirror. Possibilities (default ftp.bz2.us.kernel.org if bzip2 is on your system, ftp.gz.us.kernel.org otherwise): BKFTPSITE=ftp.bz2.us.kernel.org BKFTPSITE=ftp.gz.mx.kernel.org BKFTPSITE=ftp.mydomain.net

If your ftp server only has one of the compresed forms of the kernel tree, set the extension to use in the download with this variable. If you're using one of the standard kernel mirrors, this will be automatically detected from the mirror name.

Possibilities: BKGETEXT=bz2 BKGETEXT=gz

If set to YES, the script will allow you to make changes to the kernel configuration and pcmcia-cs configuration during the build process. If set to NO, the build will try to continue without any human interaction. If set to NO and you do not already have a kernel configuration (or, if selected to be built, pcmcia-cs configuration), the build will halt. Only choices (default YES): BKINTERACTIVE=NO BKINTERACTIVE=YES

Which kernel would you like to build? You can technically set this in one of the configuration files and force which kernel gets built. It is also set with the first command line parameter (which overrrides any configuration file entry).

Examples (default is NEWESTSTABLE): BKKERNELTOBUILD=2.1.66 BKKERNELTOBUILD=2.0.32 BKKERNELTOBUILD=NEWESTBETA BKKERNELTOBUILD=NEWESTSTABLE

I suggest one of the following three lines. The first actually raises the priority of the build, speeding it up to some degree, but may make the system unusable for other tasks. The second lets it run with no change in priority. The third (recommended) lets the build proceed with very little effect on other tasks running in the system. BTW, you can't use the first unless you are root.

Examples (default 'nice -n 10'): BKLOAD='nice -n -4' BKLOAD= BKLOAD='nice -n 10'

The build process keeps a log which includes the output from the individual programs and the checks made by the script. You can set where the file is placed after the build is done with this parameter. A copy of this file is placed in /usr/src/configs/bklog

Examples (default '/usr/src/linux/bklog'): BKLOGFILE='~/bklog' BKLOGFILE='/usr/src/linux/bklog'

If set to YES, the script will clean out build files before build. If set to NO, the script will leave any existing build files. Keep in mind that if you set BKOPENFRESH to yes, the build files will be erased anyways as part of removing the old source tree. This option does _not_ apply to the pcmcia-cs package. "make clean" will be executed before that build no matter how you have BKMAKECLEANBEFORE set. Only choices (default NO): BKMAKECLEANBEFORE=NO BKMAKECLEANBEFORE=YES

If set to YES, the script will clean out build files after build. If set to NO, the script will leave build files in place afterwards. Only choices (Default NO): BKMAKECLEANAFTER=NO BKMAKECLEANAFTER=YES

(Note: The BKINSTALLxx options are a work in progress - they may not work correctly or at all. As of 12/27/99, The BKINSTALLxx options have no effect - the kernel installs to the current root filesystem, with the BKCOPYTOFLOPPY option available.) You may very well be transporting this kernel and modules to another system. Buildkernel offers you a few ways to carry the new kernel to a different machine. If BKINSTALLTAR=yes, then buildkernel will create at .tar.gz file that you can transport to another machine. Go to the root directory of that machine and use "tar -xzvf /path/to/newkernel-version.tar.gz". The kernel itself will end up in /boot, and the modules in /lib/modules/version. /etc/lilo.conf.version is a short section that can be added to /etc/lilo.conf. The following will actually get things going for you: cat /etc/lilo.conf.version >>/etc/lilo.conf pico /etc/lilo.conf #replace "pico" with your favourite editor #and make any changes you'd like. Move #this new section to be the first once #you're sure this kernel is the one you #want to use by default. lilo

If you'd prefer to install the new kernel via RPM, set BKINSTALLRPM=yes . If you _only_ want one of the above package types and don't want this kernel on this system at all, change BKINSTALLHERE from its default of yes to no. The final choice for where this kernel goes, BKCOPYTOFLOPPY, is documented above. Note that BKCOPYTOFLOPPY _only_ copies the kernel itself; it does not make a lilo boot floppy and does not copy the modules. The choices are (BKINSTALLTAR and BKINSTALLRPM default to NO, BKINSTALLHERE defaults to YES):

BKINSTALLTAR=YES BKINSTALLTAR=NO BKINSTALLRPM=YES BKINSTALLRPM=NO BKINSTALLHERE=YES BKINSTALLHERE=NO

The linux kernel has three interfaces to the kernel configuration. The original choice, "config", is a one-by-one question and answer program. It tends to be less popular now as one mistake means you have to stop and start over. It can still be very useful if you have neither ncurses nor xwindows installed, or use a telnet program that doesn't handle curses well. The second choice, "menuconfig", uses the ncurses library to give you a text mode display that lets you move back and forth through a hierarchical display. This one's recommended if you have ncurses available. The final choice, "xconfig", is a great graphical version that runs under X windows with (tcl/tk?) libraries. Only choices (default is xconfig if DISPLAY set, menuconfig if ncurses installed, config otherwise):

BKMAKETYPE=config BKMAKETYPE=menuconfig BKMAKETYPE=xconfig

Number of concurrent builds to run. I suggest 1 on an underpowered system or one that needs all the CPU and memory it can get for foreground tasks. Otherwise I suggest setting it to the number of CPUs in your system + 1. "1" works on any system, but may take a little longer to complete. "CPU's+1" is the most efficient way to go. Going beyond that may actually slow the build down because of possible additional swapping from too many tasks taking up memory. If you're not sure, choose "1" if you have less than 16M of memory, "2" if you have 16M or more. Examples (legal values are from 1 to 17, default is the number of CPU's + 1):

BKNUMBUILDS=1 BKNUMBUILDS=2 BKNUMBUILDS=4

If set to YES, the script will open up a completely new source tree and patch it. If NO, the script will assume that you have a kernel in place ready to build with any patches already applied. Only choices (default YES): BKOPENFRESH=NO BKOPENFRESH=YES

If you have pcmcia sockets in your system, the script can build the pcmcia Card Services modules in much the same way as the kernel itself. If you don't have pcmcia sockets, just leave it at the default of NO.

Examples (default: NO): BKPCMCIATOBUILD=2.9.11 BKPCMCIATOBUILD=NO (future option: BKPCMCIATOBUILD=NEWESTPCMCIA)

Set the appropriate root device here. If you would like to use whatever the current root device is, just leave it like the first example: Examples (default: script automatically detects current root device): BKROOTDEVICE= BKROOTDEVICE=/dev/hda3

This is the location (with trailing slash) where the script can find linux-x.y.zz.tar.gz and (if building pcmcia) pcmcia-cs.a.b.cc.tar.gz Examples (default /usr/src/source/kernel/): BKSOURCEDIR=/usr/src/source/kernel/ BKSOURCEDIR=/tmp/

(BKTMPFILEPREFIX is no longer used...)

If set to YES, the script will keep the user updated about its progress and any errors encountered. If NO, the script will only keep the user informed about errors. Examples (default YES): BKVERBOSE=NO BKVERBOSE=YES

This option selects which video mode is used when the new kernel boots. For those that are used to 25 lines by 80 columns, you might want to try some of the other choices; the characters get smaller, but you can see more on your screen. If you're not sure which one to try, use '-3'. When the new kernel boots, you can get a list of available modes and choose one. '-2' is 50 X 80, '-1' is the standard 25 X 80, and 0 and above are specific to your video card. If you accidentally use one that you don't like, simply use the ' vga=ask' command line parameter when booting or edit lilo.conf to permanently select one. Examples (default '-2', which is 50 lines by 80 columns): BKVIDMODE='-3' #ask at boot BKVIDMODE='-2' #50X80 BKVIDMODE='-1' #25X80 BKVIDMODE='0' #card specific BKVIDMODE='1' #card specific BKVIDMODE='2' #card specific BKVIDMODE='3' #card specific etc, up to the limit of your video card. Use -3 to find out what that is.

What text editor would you like to use to edit the Makefile and lilo.conf? Examples (default: first found of pico, mcedit, vi, jove, nedit or emacs): EDITOR=vi EDITOR=pico

I suspect HOSTNAME, HOSTTYPE, and USER are automatically set by the kernel or, perhaps, the RedHat distribution. If the set command does not return the appropriate Architecture, you will have to manually set it here. I am guessing most people will NOT have to do this. To see if these need to be set manually, type the following command: set | grep -E '^HOSTNAME=|^HOSTTYPE=|^USER='<Enter> If it returns three lines with values similar to the examples below, you do _not_ have to set these manually. If not set, HOSTNAME is set to localhost, USER is set to root, and HOSTTYPE is set from `uname -m`. Examples: HOSTNAME=mymachine.mydomain.org HOSTTYPE=i386 USER=root

Files and directories affected by this package

/boot/... New kernel and System.map copied here ~/.bkrc User specific choices for buildkernel /etc/bkrc System wide defaults for buildkernel /lib/modules/... Kernel modules copied here /tmp/ (probably <2M needed) /tmp/BK* Temporary files that should be deleted at end /usr/bin/buildkernel Actual buildkernel script /usr/share/doc/buildkernel-x.yy/ Manuals and docs for this buildkernel (<1M needed) /usr/include/asm Symbolic link deleted and recreated /usr/include/linux Symbolic link deleted and recreated /usr/include/scsi Symbolic link deleted and recreated /usr/src/buildkernel-x.yy/ Place where buildkernel package opens up (<1M needed) /usr/src/configs/ Dir for backups of config files and logs (<300K per version needed) /usr/src/configs/.config.x.y.zz Kernel x.y.zz most recent configuration /usr/src/configs/.version.x.y.zz Kernel x.y.zz last built version /usr/src/configs/.config.mk..a.b.cc Pcmcia a.b.cc config /usr/src/configs/.config.out.a.b.cc Pcmcia a.b.cc config /usr/src/configs/bklog.x.y.zz Log of kernel build for version x.y.zz /usr/src/kpatches-x.y.zz/ User created dir for automatically applied patches (probably less than 5M needed) /usr/src/kpatches-x.y.zz/00 to 20 Up to 21 patches for kernel x.y.zz /usr/src/linux/ Symbolic link deleted and recreated /usr/src/linux-x.y.zz/ Dir created and filled w/ kernel source (probably <70M needed for 2.1.x kernels and below) /usr/src/pcmcia-cs-a.b.cc/ Dir created and filled w/ pcmcia source (probably <10M needed, 0M if your system doesn't need pcmcia) /usr/src/source/kernel/ holds source for kernel and pcmcia (4-10M per kernel source.tar.bz2, <1M per pcmcia version)

FAQ's

Q Couldn't this be simpler?
A

Sure, try this script by Jim Bray <jb@as220.org>, submitted to the linux-kernel mailing list:I finally automated the patch-and-build after typing all this a few hundred times or so:

!/bin/bash
kmake: patch if given, and make kernel

set -v cd /usr/src case $1 in

 patch-*.gz) zcat $1 | patch -p0;;

esac cd linux || exit 1; find . -name "*.rej" -exec sh -c "echo REJECTS; kill 0" \; find . -name "*.orig" -exec rm \{\} \; find . -size 0 -exec rm \{\} \; make oldconfig && make dep && make clean && make zlilo && make modules && make modules_install

If you have your source in place, and any patches applied, I think you could even use:

!/bin/bash

cd /usr/src make oldconfig dep clean zlilo modules modules_install

Haven't tried it, though.

Q

I used buildkernel to install the latest kernel. Everything went fine. When I tried to boot the kernel, it said "No setup signature". What's this? I don't believe its a buildkernel problem, but I don't know.

A

You might want to check back over the build log (usr/src/linux/bklog). Look through for errors or problems during the build. In particular, search for the error: "System is too big. Try using bzImage or modules." One possibility is that you're building a 2.2.x kernel that's too big to be stored in the zImage format (search for "bzImage" in bklog). If the kernel build complains that the image is too large, try adding:

--BKBUILDTYPE=bzImage

to the buildkernel command line and rerun (or add:

BKBUILDTYPE=bzImage

to /etc/bkrc to build this larger kernel type by default).

Configure, Build and Install a Custom Linux Kernel

From openSUSE

Contents

Introduction

About this Guide

Overview

From the ETQW Readme

References

Notes

Development Packages

System Updates

Notices

Video Drivers / Kernel Modules

Proceedures

Step 1 - Kernel Sources

Step 2 - Prepare

Step 3 - Configure

Step 4 - Customize

Step 5 - Verify Release Info (Skip)

Step 6 - Build

Step 7 - Install

Step 8 - Confirm and Boot

Step 9 - Fixing Things

NVIDIA Fix after Kernel Update

ATI Fix after Kernel Update

VirtualBox Fix after Kernel Update

VMWare Fix after Kernel Update

Informational

Extras

Automate the Build Process

User changeable parameters

FAQ's