The kernel source itself is available at http://www.kernel.org/ and perhaps more efficiently through FTP at ftp://ftp.kernel.org/.
You do know how to use anonymous FTP, right? If not, see my guide to using anonymous FTP.
You will need the kernel tar file, a rather large file
named something like:
linux-2.6.release.tar.bz2
and the corresponding very small digital signature file:
linux-2.6.release.tar.bz2.sign
This document uses release to
represent the specific release you are building.
Change it as needed to reflect current reality.
You do not want to run some hacker's operating system instead of the real kernel! You must verify both the integrity of the data you just downloaded and the identity of its source. In other words, is it really the kernel source, and did it really come from the Linux kernel organization?
So, you need to check the digital signature with GNU Privacy Guard (GnuPG) or similar.
See the digital signature section of my "Just Enough Cryptography" page for an explanation of what digital signatures are.
See the page on verifying digital signatures to learn how to apply this technology. Verification is vital, but an explanation right here would make this page at least as much about digital signatures as about building Linux kernels! Really, go look at that other page, this page will be right here waiting for you when you get back....
You need to do some steps as root here, so become root with the su command.
Your distribution or earlier work by yourself or other administrators may have already installed kernel source under a directory named /usr/src/linux-oldrelease with a symbolic link pointing to it. Find out, and if necessary, remove that link:
# cd /usr/src # ls -l # rm linux
Extract the kernel source with the following. You must be in the right directory, /usr/src, and I leave it up to you to figure out where you put that downloaded archive file. I mean, really, if you can't handle that then you have no business trying to build a kernel. But my experience tells me that I need to put two commands here:
# cd /usr/src # tar xvfj /path/to/linux-release.tar.bz2
Recreate the symbolic link, so that other software can be compiled on your system. If you're really curious, software making calls to system libraries need to find the include files under /usr/src/linux/include and this will support that. Or just take my word for it, this is important:
# ln -s linux-release linux # ls -l
The tar archive may have created files owned by some random UID other than 0, meaning root. This is not good! Fix it and make sure that everything has worked so far:
# chown -R root:root linux-release # ls -laF
You should see something like the following:
total 16 drwxr-xr-x 4 root root 4096 May 28 19:02 ./ drwxr-xr-x 15 root root 4096 May 28 21:28 ../ lrwxrwxrwx 1 root root 17 May 28 19:02 linux -> linux-release@ drwxr-xr-x 19 root root 4096 May 28 19:02 linux-release/ drwxr-xr-x 19 root root 4096 Apr 06 08:29 linux-oldrelease/
From here on, we will just rely on /usr/src/linux to be set up and pointing to the new source tree, making the pathnames a little simpler if we need to mention them. However, almost everything should be done in the directory /usr/src/linux and so there is little need to mention full path names!
There are thousands of choices to be made when configuring a kernel build, and if you just dive in and start answering them you probably will not get enough of them right to produce a kernel that boots.
However, you are running some kernel that boots and runs on your hardware. I would presume that it is probably of an earlier release if you are like most people who would read this page, but its configuration would be a good starting point.
The very best solution would be to ask the running kernel how it is configured. That way you would get the truth. So, try that:
# zcat /proc/config.gz > .config
If that worked, great, move on to the next step. If it did not work, you will need to find a configuration file that your distribution has probably stashed away somewhere on the system. Try this while paying attention to the available file name or names. Pick the latest if you have a choice:
# ls /boot # cp /boot/config-release-distro .config
Red Hat has been known to hide the configuration files in other places:
# ls /usr/src/linux-oldrelease/configs # ls /usr/src/linux-oldrelease/.config
If all else fails:
# find / -name 'config-2*'
Or, worse yet, try the following, where CONFIG_EXPERIMENTAL is a configuration variable set in the file regardless of architecture. You will probably find that string in other files so you will need to think a little about what you find.
# find / -type f -exec grep 'CONFIG_EXPERIMENTAL=[yn]' {} /dev/null \;
You need to somehow install something reasonably relevant as /usr/src/linux/.config.
Let's say that you would like your new kernel to describe itself as version 2.6.xx-whatever instead of plain old 2.6.xx when someone runs the command uname -r or uname -a.
The trick is to edit the file Makefile and change its opening to the following:
VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = xx EXTRAVERSION = -whatever
Be careful — you must be very conservative in what you put here! The string needs to be fairly short and contain nothing but letters, numbers, "." and "-". Any other punctuation marks or white space will cause horrible problems later.
Now you are ready for the fun part! You are finally ready to run the kernel build configuration tool. I say "kernel build configuration" instead of "kernel configuration" because that's what you are doing. You are specifying how to build a kernel as opposed to configuring some pre-existing kernel.
The more friendy interface is started like this:
# make gconfig &
However, that may require some Gnome or GTK packages that you haven't installed, and either you haven't set up YUM or urpmi to make installation easy or you just don't want to add those packages. In that case try the following. If that doesn't work either, then it's time to install those packages....
# make xconfig &
The terminal emulator where you ran that command will have lots of output, including some error messages about setting kernel variables that were not defined and perhaps about specified settings for kernel variables that do not exist. Remember what you did — you started with the configuration of an older kernel to build a newer one. The kernel feature set changes from version to version.
You should be pretty close, and in many or even most cases it would be reasonable to just save the settings and exit the tool.
However, you probably should explore the kernel configuration just to learn about how many things the Linux kernel can support.
Just try not to do anything terribly silly like disabling support for your hard drive controller. Unless you really do want a kernel that will not boot...
Save and exit when you have finished exploring.
This has gotten much easier than it used to be. Start by seeing the list of available build targets:
# make help | less
Start building the monolithic kernel and loadable modules:
# make all
Now go get some coffee. Or a pot of tea. Or maybe lunch. This will take a while....
This is also much easier than it used to be:
# make modules_install # make install
Edit /boot/grub/menu.lst or grub.conf to move the stanza for your new kernel to the top of the list and change the default to 0 (GRUB starts counting at zero). It is going to work, right? Do comment out any hiddenmenu line that your distribution might have installed initially because they thought that you shouldn't see what's going on.
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
## hiddenmenu
title linux-2.6.xx-whatever
root (hd0,0)
kernel /vmlinuz-2.6.xx-whatever ro root=LABEL=/ quiet
initrd /initrd-2.6.xx-whatever.img
title Mandriva 2007.0 Linux 2.6.17-5mdv
root (hd0,0)
kernel /vmlinuz-2.6.17-5mdv ro root=LABEL=/ quiet
initrd /initrd-2.6.17-5mdv.img
If you're still using LILO and you don't want to upgrade, then you will need to edit /etc/lilo.conf and make the appropriate changes before running lilo -v to recreate the boot block.
If you're doing this on an Alpha, ignore all this about GRUB and LILO and modify /etc/aboot.conf and then go see my page specifically about building kernels on Alphas for some further details.
# aboot default configurations # NOTICE: You have a /boot partition. This means that # all kernel paths are relative to /boot/ 0:2/vmlinuz-2.6.xx-whatever initrd=/initrd-2.6.xx-whatever root=/dev/sda4 quiet 1:2/vmlinuz-current initrd=/initrd-current root=/dev/sda4 quiet 2:2/vmlinuz-previous initrd=/initrd-previous root=/dev/sda4 quiet
You didn't do anything silly like get rid of your functional old kernel, right? Or configure your boot loader in such a way that it isn't available? Did you??
|
||||||||||||
|
||||||||||||
