Creating a custom Kernel (the non-Fedora way)

[beissemj]

Many people think that creating a custom kernel is difficult, when in fact nothing could be farther from the truth. Compiling your own kernel is rather simple, and is much easier than the Fedora way (http://forums.fedoraforum.org/showthread.php?t=144066) (imho). Compiling a kernel the Fedora way gets you the bonus of the Fedora patches and a nice easy RPM. However, it is rather simple to compile a kernel generically.

Why would I want to do this?
Well, I think that building a kernel manually takes away some of the magic in using linux. You will also get a smaller kernel, which will result in a faster boot time (most likely), and a smaller kernel compile time (mine was 12m27.094s). Finally, sometimes you need to apply a patch to the kernel to enable support for a particular device, and that can be done quite easily this way.

1. Straight to the source.
Assuming you don't want Fedora patches (as I would say the average user doesn't use them anyways), then you'll need to download the kernel source from kernel.org (http://www.kernel.org). They provide both stable and testing kernels, so take your pick. The kernels are available in either tar.bz2 format or tar.gz format and are usually around 30-40MB. Either format will do, however you might as well get the tar.bz2 format as it is smaller.

2. Unpack the source
Now that you have your kernel source e.g. linux-2.6.19.1.tar.bz2 we need to unpack the kernel sources and create a symlink to the kernel sources directory:
# cp /location/to/kernel/linux-2.6.19.1.tar.bz2 /usr/src
# cd /usr/src
# tar -xjpf linux-2.6.19.1.tar.bz2
# ln -s linux-2.6.19.1 linux
3. (Optional) Applying patches

Move the downloaded kernel patch to the /usr/src/linux directory.
#cd /usr/src/linux
If you downloaded a patch with a .gz extension, execute the following command: gunzip patch-2.2.x.gz
If you downloaded a patch with a .bz2 extension, execute the following command: bunzip2 patch-2.2.x.bz2
There should now be a file called patch-x.x.xx in the /usr/src/linux directory. Apply the patch to the kernel source tree with the following command: # patch -p1 --dry-run < patch-x.x.xx
# patch -p1 -s < patch-x.x.xxThe first command is just a test, it does nothing to your sources. If it doesn't show errors, you can run the second command which actually applies the patch. Don't do it if the first command shows errors!

4. Configure The Kernel
It's a good idea to clean out any old stuff, and then start with your current configuration so: # make mrproper
# cp /boot/config-your-config /usr/src/linux/.config
# cd /usr/src linux ; make oldconfig
(just keep hitting enter until it's done)
# make menuconfig
(if you get an error you probably need to install ncurses-devel)Now all that's left is to configure your kernel. Press 'h' to get help on a particular item, and press '/' to search for something. When you are done save and exit.

5. Compile and install
To compile and install your kernel along with copying all important data to /boot/ do: # make prepare
# make all
# make modules_install
# make install
# cp Module.symvers /boot/symvers-2.6.19.fc6.gz
# cp .config /boot/config-2.6.19 Now you are all set. Your grub/menu.lst will automatically be updated, and you will have an initrd.img (provided you have that kernel option enabled). So now reboot and try out your new kernel.

Troubleshooting
Q. I get a kernel panic when I try to boot?
A. There are many reasons for this, however the most common are lack of support for ramdisks, initrd, and/or the filesystems that you use (e.g. ext2, ext3, reiserfs, etc)


Advanced
So you want to use an .rpm and you want the Fedora patches, and you don't want to build it the Fedora way. Okay, you can do that too.

A. Using an .rpm
Get your rpm (http://download.fedora.redhat.com/pub/fedora/linux/core/development/source/SRPMS/) (e.g. kernel-2.6.19-1.2906.fc7.src.rpm).

Now extract the contents and install the patches.
# mkdir /usr/src/rpm
# mv /your/location/kernel-2.6.19-1.2906.fc7.src.rpm /usr/src/rpm/
# cd /usr/src/rpm/
# rpm2cpio kernel-2.6.19-1.2906.fc7.src.rpm | cpio -idmv
# tar -xvjpf linux-2.6.19.tar.bz
# ln -s /usr/src/rpm/linux-2.6.19 /usr/src/linuxMove and apply Fedora patches# mv /usr/src/rpm/*.patch /usr/src/linux/

Now we need a short script to apply the patches because there are a lot of them. This script uses quilt (yum-getable), as that was the first thing I thought of.#!/bin/csh
#/usr/src/linux/patch.sh

foreach i ( `ls *.patch | sed s/\.patch//` )
quilt add $i.patch
end# sh ./patch.shNow proceed to configure your kernel as you normally would.

[alpha645]

Wow, easy :D . One minor adjustment, the difference between the Fedora and your way is that you miss certain Fedora patches... ;)

[paul matthijsse]

Interesting. How long takes the compile and install process roughly? And can you tell me what the advantages are to do it this way ("by hand")?

Thanks, Paul.

[alpha645]

Interesting. How long takes the compile and install process roughly? And can you tell me what the advantages are to do it this way ("by hand")?

Thanks, Paul.

I don't want to be negative about this guide, but you should also look at this (http://forums.fedoraforum.org/showthread.php?t=141782) one. Non-fedora guide is better if you have trouble installing or creating RPM's, or using other distributions.

The other one creates RPM's with all the Fedora patches. You can also chose in the other guide to use the most recent (2.6.20rc4) kernel or the source where the latest public kernel is build with.

BUT, the Non-Fedora guide is more usefull when it comes down to solving problems plus, you are more aware of what you are doing. Files are manually placed :) . RPM packages do that fully automatic, this can give errors.

The time, I don't know in this guide. But the other guide I use, gives me a total compile time of 15 minutes :D . How?
- Remove all the useless junk (with menuconfig)
- Disable XEN
- Disable KDUMP
- Disable PAE
- Disable Debug packages

And I also think that this way doesn't compile the kernel-devel. So you won't be able to build your own modules against it.

[beissemj]

You can also chose in the other guide to use the most recent (2.6.20rc4) kernel or the source where the latest public kernel is build with.
Last time I checked, kernel.org has some of the newer ones ;).

And I also think that this way doesn't compile the kernel-devel. So you won't be able to build your own modules against it.
Not sure what you mean by this. Kernel-devel just provides the kernel headers (to my knowledge they are also not the complete kernel headers due to some backwards compatibility issues (eg API calls), I could be wrong though), and you definately need those so gcc know what to do :). Now this is fine for most people, but can be annoying if you are trying to build 3rd party modules, or if you are working on a senior design project and need to write your own device driver. :cool:

Also, the point of the guide is just to let people know that their are other ways of compiling the kernel, and just to increase one's knowledge about linux in general. I think the more knowledge you have the better.

-Cheers

[alpha645]

Did you look for the newest kernel at this (http://download.fedora.redhat.com/pub/fedora/linux/core/development/source/SRPMS/) location. It is 2.6.20rc4 . This also includes Fedora patches and stuff.

Well, I said I THINK it doesn't create the kernel-devel. In the RPM way, the program creates 2 rpm's. The kernel and the kernel-devel. So, if you are right, that means that in your way the kernel-devel is already build in. Plus, I don't know exactly what the kernel-devel contains.

[beissemj]

Actually, you just gave me a really good idea! Use 'alien' to convert the rpm, and then I have the fedora patches too. I'll look into that, although I'm not sure if glibc will break.

[alpha645]

Does alien accept the output of your way of compiling the kernel?
I never heard of it before, but it could be real good.

[leigh123@linux]

Does alien accept the output of your way of compiling the kernel?
I never heard of it before, but it could be real good.

debian-leigh:/home/leigh# alien --help
Usage: alien [options] file [...]
file [...] Package file or files to convert.
-d, --to-deb Generate a Debian deb package (default).
Enables these options:
--patch=<patch> Specify patch file to use instead of automatically
looking for patch in /var/lib/alien.
--nopatch Do not use patches.
--anypatch Use even old version os patches.
-s, --single Like --generate, but do not create .orig
directory.
--fixperms Munge/fix permissions and owners.
--test Test generated packages with lintian.
-r, --to-rpm Generate a Red Hat rpm package.
--to-slp Generate a Stampede slp package.
-l, --to-lsb Generate a LSB package.
-t, --to-tgz Generate a Slackware tgz package.
Enables these options:
--description=<desc> Specify package description.
--version=<version> Specify package version.
-p, --to-pkg Generate a Solaris pkg package.
-i, --install Install generated package.
-g, --generate Generate build tree, but do not build package.
-c, --scripts Include scripts in package.
-v, --verbose Display each command alien runs.
--veryverbose Be verbose, and also display output of run commands. -k, --keep-version Do not change version of generated package.
--bump=number Increment package version by this number.
-h, --help Display this help message.
-V, --version Display alien's version number.

Its a very useful tool :cool:

[alpha645]

So, that package allows you to grab a .deb package and turn it into an .rpm :) .
Windows has only one package :p .

[leigh123@linux]

Alien is a program that converts between the rpm, dpkg, stampede slp, and slackware tgz file formats. If you want to use a package from another distribution than the one you have installed on your system, you can use alien to convert it to your preferred package format and install it.

Despite the large version number, alien is still (and will probably always be) rather experimental software. It has been used by many people for many years, but there are still many bugs and limitations.

Alien should not be used to replace important system packages, like sysvinit, shared libraries, or other things that are essential for the functioning of your system. Many of these packages are set up differently by Debian and Red Hat, and packages from the different distributions cannot be used interchangably. In general, if you can't uninstall the package without breaking your system, don't try to replace it with an alien version.

http://kitenet.net/~joey/code/alien.html

[beissemj]

Looks like alien is not what I want. Not only is it not in the yum repository (easily fixed (http://www.hccfl.edu/pollock/AUnix1/alien/) though), but I just want the contents of the archive. Turns out
#rpm2cpio kernel-2.6.19-1.2906.fc7.src.rpm | cpio -idmv does the job nicely.

Also, the kernel FC6 2.6.19 (patched to .20) has around 90 or so Fedora patches applied to it. I looked at the changelogs/grepped through a lot of them, and most of them are trivial, but there are some nice ones (xen support and the like).

Obviously applying 90 patches is ridiculous (and this way you don't have to apply the ones that aren't needed), so you'll want something to do it for you. quilt (http://www.die.net/doc/linux/man/man1/quilt.1.html) works pretty well although I'm still trying to figure out how exactly the spec file works, so don't have it quite working yet. Looks like it should be pretty easy to get a kernel with the fedora patches though.

[alpha645]

Looks like alien is not what I want. Not only is it not in the yum repository (easily fixed (http://www.hccfl.edu/pollock/AUnix1/alien/) though), but I just want the contents of the archive. Turns out
#rpm2cpio kernel-2.6.19-1.2906.fc7.src.rpm | cpio -idmv does the job nicely.

Also, the kernel FC6 2.6.19 (patched to .20) has around 90 or so Fedora patches applied to it. I looked at the changelogs/grepped through a lot of them, and most of them are trivial, but there are some nice ones (xen support and the like).

Obviously applying 90 patches is ridiculous (and this way you don't have to apply the ones that aren't needed), so you'll want something to do it for you. quilt (http://www.die.net/doc/linux/man/man1/quilt.1.html) works pretty well although I'm still trying to figure out how exactly the spec file works, so don't have it quite working yet. Looks like it should be pretty easy to get a kernel with the fedora patches though.

The specfile allows you to change settings during the building of the package. Look at the HOWTO I gave in the second post. Scroll down, you will see that I disable useless packages and change the kernelstring. It's part of rpmbuild btw