Downloading and using kernel source code ( and newer) on CentOS

If you know you need to get your kernel source (or at least its headers) for a kernel version and newer, you can find instructions to do so on CentOS here.

Why would I want kernel source code?

There may come a time when you need the kernel source code, usually to build kernel headers, compile a module or some other server voodoo. Most users won't need to mess with the kernel source on a virtual server, so if you don't know that you need it, you probably don't and can safely skip this article. If you know you do, though, read on.

Note that the instructions in this article apply to kernels version and newer. We'll cover checking the version in a bit. If you do have an older kernel version you'll need to check another article, or pop into support chat for help finding the right source code package.

Install development tools

To do much with the kernel source once you have it, you'll want some development tools installed on your server. If you don't know that you have those tools installed already, you can run an install of a convenience package to be sure.

sudo yum groupinstall 'Development Tools'

Not everything that metapackage installs is needed to compile the kernel, of course, but it includes packages useful for other development as well (they might be needed if you're compiling a module next, for example).

If you're the curious sort and want to see just what actually is needed to compile the kernel, then once you have the source unpacked you can take a look in the "Documentation" directory. The beginning of the "Changes" file lists programs and libraries that can be used when building the kernel, along with their required versions.

Check the kernel version

While you're on the command line, it's a good idea to check the version of the kernel you're running. You can do this through your management control panel (which is where you can install a different kernel version), but it's most reliable to check the version right on the server. Just run:

uname -r

The output will be the version of the kernel running on your virtual server. Something like:

The kernel repository

Slicehost and the Rackspace Cloud use the same kernels, so you'll see both names when you visit our kernel repository:

When you visit that site in a web browser you'll see a simple list of directories for the kernel versions that have source code available there. Click the one that corresponds to your kernel.

A choice of sources

Inside each of those directories are some other directories that offer you a choice of "flavor" when selecting your kernel source, something like:

Index of /

Name                Last Modified           Size    Type
Parent Directory/                           -       Directory
patched_source/     2010-May-19 20:35:30    -       Directory
patches/            2010-May-19 20:40:47    -       Directory
vanilla_source/     2010-May-19 20:39:05    -       Directory

If you're looking for the source code of the kernel you're actually running on your server, you'll want what's in the "patched_source" directory.

The "vanilla_source" directory holds the original kernel source, before it was patched for our virtual environment. The "patches" directory contains the patches that were applied to the vanilla_source to make the patched_source.

A choice of formats

Finally, in that patched_source directory, you'll find a package with the source code you want. Or...maybe more than one package, with different extensions at the end.

Index of /

Name                        Last Modified           Size    Type
Parent Directory/                                   -       Directory   2010-May-17 19:03:51    62.3M   application/octet-stream    2010-May-17 19:03:52    80.4M   application/octet-stream

Each of those packages contains the same source code, they're just compressed in different formats. The ".tar.gz" package is tarred and gzipped, which is a more widely compatible package format. The ".tar.bz2" package was tarred and compressed with bzip, which makes a smaller package but isn't compatible with as many systems as gzip.

You can safely pick either one, since pretty much any Linux distribution will be using a version of tar that can unpack both formats.

Downloading the source

So now you've identified the package you need. Next it's a matter of getting it onto your server.

If you have wget or curl installed, copy the link and download the package directly to your server. If you don't know what I'm talking about, you can just download the package in your browser instead, then copy it to your server from there using scp or sftp. So long as the package eventually winds up on your server you're good.

Unpack the source

Let's change our working directory to a standard location for linux source code:

cd /usr/src

And then unpack your package (known as a "tarball", in the jargon). If you downloaded the bz2 file, run:

sudo tar -xjvf ~/

Substitute the path to the tarball for the "~/" above if it isn't in your home directory, of course.

If you downloaded the gz file, run:

sudo tar -xzvf ~/

Note that the difference between the commands is that a "j" option is passed to tar for the bz2 file where a "z" is passed to tar for the gz file.

Either way, after watching a bunch of filenames scroll past you'll wind up with a directory named after your kernel version, containing the kernel source. Nice work.

Make the headers

One possible use for the kernel source is to build the kernel headers needed to compile some other program. If that's what you're after, it's a pretty easy task to accomplish now. Change your working directory to the kernel source directory:

cd /usr/src/

And then run the following command:

sudo make headers_install

That's it, you're set.

Preparing to compile a module

If you want to compile a module there's more than one step involved, alas. And you'll actually need more than just the kernel source for this. You'll also need the configuration file that was used to build your kernel.

Thankfully, that's easy to find and put in place. Make sure you're in the kernel source directory, and run:

sudo zcat /proc/config.gz > .config

There you go. No need to muck about in a configuration menu or answer a bunch of yes/no questions, all the work's been done for you.

One more step. Run:

sudo make modules_prepare

You'll see where it's copying files, and maybe a few warnings. Skim the warnings, but if they're just advising you that it's "ignoring return value" of some function you don't need to worry about them.

Now your system should be ready to compile your module. From there follow the directions that (hopefully) came with the module's source code.


You should have the basic steps for getting the source code for your kernel down now: Check your kernel version, hit the kernel repository, pick the package you want, and then download and unpack it on your server. You still won't be able to install any kernel you compile from source, but you should be well-prepared to grab the source again if you upgrade your kernel through the control panel later.

  • -- Jered

Article Comments:

Jon commented Mon Oct 11 19:55:52 UTC 2010:

I just wanted to comment on this because I had a problem using this guide when trying to install dahdi with asterisk on a rackspace cloud centos 5.5 server. I was able to find another guide that helped me here is what you need to do.

mkdir /usr/src/kernels/
tar xzf -C /usr/src/kernels/
cd /usr/src/kernels/
zcat /proc/config.gz > .config
make oldconfig && make modules_prepare

Then once you do that the kernel is ready to be used, just make sure you specify it when running make in dahdi. See how to do that below.

cd /usr/src/dahdi-source
KSRC=/usr/src/kernels/ make
KSRC=/usr/src/kernels/ make install
Want to comment?

(not made public)


(use plain text or Markdown syntax)