Welcome to the new location of Alien's Wiki, sharing a single dokuwiki install with the SlackDocs Wiki.

Welcome to Eric Hameleers (Alien BOB)'s Wiki pages.

If you want to support my work, please consider a small donation:

no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.


Previous revision
Next revision
—linux:kernelbuilding [2008/04/11 14:36] – alien
Line 1: Line 1:
 +===== Building a Linux Kernel from source =====
 +-----------------------------------------------
  
 +**This is a short recap of how I build my 2.6 kernels.**
 +
 +==== X and su ====
 +
 +I run the commands from an X terminal, and at some point start the X based kernel configurator. I run my desktop as "myself" but I build my kernels as root. In order to let root use my X display, I do the following in my X terminal: get root rights; merge my own (alien's) Xauthority file with the one from the root user, and set the DISPLAY variable. After doing that, I can run X applications from the "su" terminal.
 +<code>
 +echo $DISPLAY                  # you'll be needing this value 3 lines below
 +sudo -i                        # or "su -" on older Slackwares
 +xauth merge ~alien/.Xauthority # use your own username here instead of "alien"
 +export DISPLAY=:0.0            # use the value of DISPLAY you've seen 3 lines before
 +</code>
 +
 +
 +==== Downloading and configuring ====
 +
 +Now that the build environment is set up, let us continue with obtaining the sources.
 +
 +Download a new kernel, unpack it into ''/usr/src'' and create the "linux" link so that the commands are a little more generic. I will take a kernel version of "2.6.17.13" as an example. If yours is a different version, you'll know where to change the version strings in the rest of the story below. If you want to know how to verify the integrity of the source code archive using the kernel GPG key, read the [[#gpg_signature | last chapter]] below.
 +<code>
 +wget http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.4.tar.bz2
 +tar -C /usr/src -jxvf linux-2.6.24.4.tar.bz2
 +cd /usr/src
 +rm linux
 +ln -s linux-2.6.24.4 linux
 +</code>
 +
 +You will probably notice more linux-* directories in ''/usr/src'' but it is common to let the "linux" link point to the kernel you are working with.
 +
 +<note>There is a debate whether you should build your kernels in the ''/usr/src'' tree or somewhere entirely else.\\ The cause is an [[http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html|old post by Linus Torvalds]] (from July 2000) where he advises people to build from whithin their homedirectory. I believe this advice is irrelevant for Slackware and the way it has it's kernel headers and glibc package setup. So, **my** advice is to ignore this old post by Linus and install your kernel sources into ''/usr/src'' if you want.</note>
 +
 +Now, get a Slackware kernel config file for a headstart during your own configuring. Pat's config files are pretty generic. By the time you read this, there might be a config for a newer 2.6 release available:
 +<code>
 +wget http://slackware.mirrors.tds.net/pub/slackware/slackware-12.1/source/k/config-generic-smp-2.6.24.4-smp
 +cp config-generic-smp-2.6.24.4-smp /usr/src/linux/.config
 +</code> Alternatively, you can grab the configuration for the kernel which is currently running: <code>
 +zcat /proc/config.gz > /usr/src/linux/.config
 +</code>
 +Run //make oldconfig// in the kernel source directory so that the defaults are used from the .config file you just installed. Because your kernel sources are probably newer than the .config, there will be new options to choose from. You will only have to answer these (press <key>ENTER</key> for the default answers which are mostly fine, or <key>m</key> to build new drivers as modules).
 +<code>
 +cd /usr/src/linux
 +make oldconfig
 +</code>
 +
 +You now have configured a pretty generic kernel (that is the reason why Pat calls them "kernel-generic" probably :-) but you will want to change some of the defaults to suit your needs. Run the X based configurator (if you do not run X but are at a text console, just run "make menuconfig" to get the curses-based dialog program instead)
 +<code>
 +make xconfig
 +</code>
 +
 +Walk through the forest of options. What I usually change are things like:
 +
 +  * build the ext3 (needs the jbd driver as well) and reiser fileystem drivers into the kernel instead of compiling them as modules - I do not need to create an additional "[[#creating_an_initrd|initrd]]" then\\ (see under "Filesystems" in the configurator).
 +
 +  * enable support for dual procesessors and hypertreading - naturally this only helps if you have a HT Intel CPU, or a dual-CPU board or a dual-core CPU\\ (under "Processor type and features" > "Symmetric multi-processing support").
 +
 +  * enable 4GB of RAM.\\ (under "Processor type and features" > "High Memory Support (4GB)").
 +
 +  * enable the "low-latency" kernel if you run a desktop/laptop computer - multimedia apps will run much smoother\\ (under "Processor type and features" > "Preemption model" > "Preemptible kernel").
 +
 +  * set a 1000Hz timer (under "Processor type and features" > "Preemption model" > "Timer frequency").
 +
 +  * ... and more I can't think of right now. You can decide to disable a lot of the modules that the default config will build, to cut down on time, if you don't have the hardware in your computer. You could also looka at software suspend and CPU frequency scaling (under "Processor type and features") if you own a laptop.
 +
 +And finally save your configuration if you're satisfied.
 +
 +==== Building your kernel ====
 +
 +Now, start the build of kernel and modules, and install them to the proper places.
 +
 +<code>
 +make bzImage modules            # compile the kernel and the modules
 +make modules_install            # installs the modules to /lib/modules/<kernelversion>
 +cp arch/i386/boot/bzImage /boot/vmlinuz-custom-2.6.24.4  # copy the new kernel file
 +cp System.map /boot/System.map-custom-2.6.24.4           # copy the System.map (optional)
 +cp .config /boot/config-custom-2.6.24.4                  # backup copy of your kernel config
 +cd /boot
 +rm System.map                                            # delete the old link
 +ln -s System.map-custom-2.6.24.4 System.map              # create a new link
 +</code>
 +
 +==== Modifying lilo.conf ====
 +
 +Edit ''/etc/lilo.conf'' and add a new section for your new kernel. Remember, your new kernel may not even boot if you made a mistake somewhere, so you will want to leave the sections for your current kernel(s) intact. Your current ''/etc/lilo.conf'' will have a section somewhat like this, near the bottom of the file: <code>
 +image = /boot/vmlinuz
 +root = /dev/hda1
 +label = linux
 +read-only # Non-UMSDOS filesystems should be mounted read-only for checking
 +</code> Add another section just below (adding it below will guarantee that your current kernel will remain the default to start):
 +<code>
 +image = /boot/vmlinuz-custom-2.6.14.4
 +root = /dev/hda1
 +label = newkernel
 +read-only # Non-UMSDOS filesystems should be mounted read-only for checking
 +</code>
 +After adding a stanza for your new kernel to ''/etc/lilo.conf'' and saving the file, run lilo to activate your changes: <code>
 +lilo
 +</code>
 +
 +Now is the time for a reboot, to test the results! In the lilo boot screen, select the "newkernel" option instead of the default "linux" option.\\
 +If the new kernel boots fine, you can add this line to the top of ''/etc/lilo.conf'' and re-run "lilo": <code>
 +default = newkernel
 +</code>
 +
 +===== Other packages that contain kernel modules =====
 +
 +Most certainly you will have packages installed that contain kernel modules that are not part of the default kernel. Slackware has "alsa-driver" for instance, and if you installed any wireless driver, these are basically kernel modules too.\\
 +Now, with the installation of your new kernel, you will lose these modules, and you have to recompile the sources so that the binary modules match the new kernel.\\
 +You can get an overview of all packages that have installed a kernel module for your current kernel by running this command (i.e. you must run this command while still running your old kernel): <code>
 +cd /var/log/packages
 +grep -l "lib/modules/$(uname -r)" *
 +</code>
 +All the mentioned packages will need a recompile.
 +
 +For ALSA you have a choice: either enable the ALSA driver that is part of the kernel you've just downloaded, or leave the kernel configuration like Slackware's: disable all ALSA support in the kernel and instead re-build the alsa-driver package. The 2.6 kernels of Slackware 12.1 have all the ALSA drivers built-in because they will not work with the ALSA driver releases you can install separately.
 +
 +
 +===== Creating an initrd =====
 +
 +In case your kernel does not include the driver for your root filesystem, or a driver for your SATA bus, or other stuff that is only built as modules, your kernel will panic if it boots and can not access the necessary disks, partitions and/or files. Typically, this looks like <code>
 +VFS: Cannot open root device "802" or unknown-block (8,2)
 +Please append a correct "root=" boot option
 +Kernel Panic-not syncing: VFS: unable to mount root fs on unknown block(8,2)
 +</code> and this means you will have to build an //initrd// or "Initial Ram Disk" containing the required modules. The location of the initrd is then added in the appropriate section of ''/etc/lilo.conf'' so that the kernel can find it when it boots, and is able to load the drivers it needs to access your disks.
 +Creating an initrd is quite simple, and I will show two cases here, one in care you have a Reiser filesystem on your root partition, and the second for the case you have an ext3 filesystem. I assume a 2.6.24.4 kernel in these example commands, if your new kernel is different, change the version number as appropriate.
 +
 +  * Change into the /boot directory: <code>
 +cd /boot </code>
 +
 +  * Run "mkinitrd" to create the ''/boot/initrd'' file containing a compressed filesystem with the modules you tell it to add on the commandline: <code>
 +mkinitrd -c -k 2.6.24.4 -m reiserfs</code> for a Reiser filesystem, or <code>
 +mkinitrd -c -k 2.6.24.4 -m ext3</code> in case you installed an ext3 filesystem on your root partition..
 +
 +  * Add the line "initrd = /boot/initrd.gz" to the newkernel's section in the file ''/etc/lilo.conf'', save your changes and then re-run lilo; I will use the ''lilo.conf'' example section I already used in a previous paragraph: <file>
 +image = /boot/vmlinuz-custom-2.6.24.4
 +  root = /dev/hda1
 +  initrd = /boot/initrd.gz
 +  label = newkernel
 +  read-only # Non-UMSDOS filesystems should be mounted read-only for checking
 +</file> then run <code>lilo</code> On next boot, your new kernel will not panic.
 +
 +<note tip>I have written a shell script ([[http://www.slackware.com/~alien/tools/mkinitrd_command_generator.sh|mkinitrd_command_generator.sh]]) which examines your running Slackware system and shows you an example ''mkinitrd'' command. If you run that ''mkinitrd'' command, it will produce an initrd image that contains all the kernel modules and support libraries so that your system can boot with the Slackware //generic// kernel.\\ Here is an example of how to run the command with it's output shown as well:<code>
 +./mkinitrd_command_generator.sh /boot/vmlinuz-generic-smp-2.6.24.4-smp
 +
 +#
 +# $Id: mkinitrd_command_generator.sh,v 1.11 2008/04/10 23:56:18 root Exp root $
 +#
 +
 +# This script will now make a recommendation about the command to use
 +# in case you require an initrd image to boot a kernel that does not
 +# have support for your storage or root filesystem built in
 +# (such as the Slackware 'generic' kernels').
 +# A suitable 'mkinitrd' command will be:
 +
 +mkinitrd -c -k 2.6.24.4-smp -m ata_generic:pata_amd:mbcache:jbd:ext3 -f ext3 -r /dev/hda7
 +
 +
 +# An entry in 'etc/lilo.conf' for
 +# kernel '/boot/vmlinuz-generic-smp-2.6.24.4-smp' would look like this:
 +# Linux bootable partition config begins
 +image = /boot/vmlinuz-generic-smp-2.6.24.4-smp
 +  initrd = /boot/initrd.gz
 +  root = /dev/hda7
 +  label = 2.6.24.4-smp
 +  read-only
 +# Linux bootable partition config ends
 +</code></note>
 +
 +===== Loading modules on boot =====
 +
 +Prior to Slackware 11.0, modules for your kernel were loaded either by the hotplug subsystem, or by explicit ''modprobe'' commands in the file ''/etc/rc.d/rc.modules''. Having the same ''rc.modules'' file for 2.4.x and 2.6.x kernels was not an optimal situation.\\
 +In Slackware 12.0 and newer the 2.6 kernel the only kernel that is available. The loading of kernel modules is handled by udev and by explicit ''modprobe'' commands: the modules that are not loaded by udev can still be put in a ''rc.modules'' file. Only, there can now be more than just one file. Slackware will look for the existence of the following (executable) files in this order:
 +  * If ''/etc/rc.d/rc.modules.local'' exists, it will be run
 +  * Else, if ''/etc/rc.d/rc.modules-$(uname -r)'' exists, it will be run
 +  * Else, if ''/etc/rc.d/rc.modules'' exists, it will be run
 +The **$(uname -r)** is the current kernel release. If your kernel version is ''2.6.24.4-smp'', then Slackware will look for a file ''/etc/rc.d/rc.modules-2.6.24.4-smp'' to run. This way, specific //rc// files for different kernels can be present, allowing an optimal tuning for your system.
 +
 +The Slackware 12.1 package ''/slackware/a/kernel-modules-smp-2.6.24.4_smp-i686-2.tgz'' will install the file ''/etc/rc.d/rc.modules-2.6.24.4-smp''. You can use that as an example if you want to build your own kernel and need explicit ''modprobe'' commands for specific kernel modules.
 +
 +<note>If you decide to build your own 2.6 kernel from source, you might get bitten by the fact that there will not be a file called  ''/etc/rc.d/rc.modules-$(uname -r)'' - you will have to create it yourself. The ''rc.modules'' usually is a symlink to the ''rc.modules-2.6.24.4-smp''. A typical result from the absence of a rc.modules file for your specific kernel is that your mouse will not be working. Take that behaviour as a hint to create the ''rc.modules'' file! You can take a full copy of any existing ''rc.modules-2.6.xx'' file. If your system does not have any rc file for a 2.6 kernel you can take the one on the Slackware CD as an example:\\ 
 +''/source/k/kernel-modules-smp/rc.modules.new''</note>
 +
 +===== GPG signature =====
 +
 +The Linux kernel source archives are signed with the OpenPGP "Linux Kernel Archives Verification Key". This is a means to verify that the source code you downloaded is the original archive and has not been tampered with. The steps for this validation are outlined in this chapter.
 +
 +  * First, import the OpenPGP key into your GnuPG keyring; either by copying the key from the [[http://www.kernel.org/signature.html | signature page]] or by importing it from a keyserver. The kernel key ID is ''0x517D0F0E''. An example goes like this: <code>
 +gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
 +</code> The resulting output will be somewhat like this: <file>
 +gpg: key 517D0F0E: public key "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>" imported
 +gpg: Total number processed: 1
 +gpg:               imported: 1
 +</file>
 +
 +  * Next, get the signature file for the kernel archive you've downloaded: <code>
 +wget http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.4.tar.bz2.sign</code> and make sure it is in the same directory as the kernel archive itself.
 +
 +  *  The final step is to run gpg on this signature file, and check what it has to report: <code>
 +gpg --verify linux-2.6.24.4.tar.bz2.sign linux-2.6.24.4.tar.bz2
 +</code> The output will be like this: <file>
 +gpg: Signature made Mon 24 Mar 2008 08:16:45 PM CET using DSA key ID 517D0F0E
 +gpg: Good signature from "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>"
 +gpg: checking the trustdb
 +gpg: checking at depth 0 signed=1 ot(-/q/n/m/f/u)=0/0/0/0/0/4
 +gpg: checking at depth 1 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/1/0
 +gpg: next trustdb check due at 2012-12-21
 +gpg: WARNING: This key is not certified with a trusted signature!
 +gpg:          There is no indication that the signature belongs to the owner.
 +Primary key fingerprint: C75D C40A 11D7 AF88 9981  ED5B C86B A06A 517D 0F0E
 +</file> If you would have told gnupg to trust this key, the last part would have looked different. To me, adding a trustlevel to this key makes no real sense, except when you've met one of the kernel developers who had the key with him and could present thrustworthy credentials.\\
 +Nevertheless, the outcome is that the source code archive was indeed signed with the key that you just imported. So, that is good news.

Trace:

Building a Linux Kernel from source ()
SlackDocs