There are plenty of guides around how to compile the kernel on Slackware as a simple query with your favorite search engine will show. Most of them are a little out of date but still good to pick up from. Anyway, I thought I'ld update it a bit, so here's my own guide on how to compile the Linux kernel. Some of it is heavily borrowed from this post on Linuxquestions.org by Shilo (is a geek), who also has a great website dedicated to Slackware. Read his Desktop Enhancement Guide of you haven't yet. The post on LQ is from 2004 but still very valid when it comes to the kernel.
Before we begin, there is no need to upgrade or recompile your kernel if everything, that includes peripheral hardware, is working as it should. In the past recompiling was done to trim it down to size, by stripping it of all unneeded modules and functionality, because a slimmer kernel meant slightly faster booting and system operations. This resulted in a highly customized kernel only suitable for that particular machine, unless you had several with an identical hardware setup which were using the same version of your distribution. However, the benefits are debatable and many will state stripping out unnecessary stuff never made a difference to them in terms of speed. Similarly, the difference in speed between a huge kernel and a modular one using an initrd is probably mostly preconception. Has anyone actually ever benchmarked this? Anyway, these days our PC's are powerful enough to make any perceived difference null and void.
The second reason why people used to compile the kernel in the earlier days of Linux was that new features were introduced quite rapidly, and users liked to have the latest as it introduced support for new drivers etc. This is still relevant to a certain extent, although not quite as rapidly as before, and most users will be just fine with an older kernel unless they just went out and bought that bleeding edge piece of hardware literally days ago.
Another reason why to upgrade is that sometimes bugs exist and do get fixed, so if you have a problem with an older kernel this may be the solution. However, bear in mind that there can also be regressions and new bugs can be introduced, so there will never be the perfect kernel. It's a constant process. There may be a
perfect kernel for your needs though, on your machine and for the life of your distribution. Take a look at this thread discussing why you might want to upgrade your kernel and why it may not be necessary at all.
For me the stock 2.6.37.6 kernel in Slackware 13.37 worked perfectly well for close to a year, but it required the broadcom-sta package from SlackBuilds.org. This had been fine for along time but recently started dropping connections on some public network access points, and even at home with the el cheapo router my flat mate had got in. There is a pre-made kernel config for the 2.6.39 kernel provided in the /testing/source directory, config-huge-smp-2.6.39-rc4-smp. Advanced users may also want to try adjusting the compile_kern.sh file in the kernels directory of the DVD or FTP server to build a proper txz package that can be installed and removed with the package manager. The advantage of using this newer kernel will be for me that it supports my Broadcom 43225 wireless natively once I have added the firmware.
So you're all minded to install a new kernel after weighing up the pros and cons. Get the source for your preferred new kernel from www.kernel.org. I'll be sticking to the 2.6 line as indicated above. Save it and after becoming root extract the source tarball to /usr/src. You'll see a new folder, in my case linux-2.6.39.4.
There should also be a folder named linux in /usr/src which is a shortcut to the source of your installed kernel. There are other shortcuts like this on your system pointing to stock kernel files, as so far you've only had one and this made it easier to manage, for example in the boot loader, but we'll come to that.
Delete that folder, unless you want to keep booting your old kernel as the main one, in which case you'll have to deal with your new one using its full version number. Of course you can also boot kernels directly without creating shortcuts to the relevant files and add the full name to your boot stanza, instead of just vmlinuz.
If you want the new kernel to be addressed the way the previous one was and just call it linux, right click on that folder the source extracted to and pick "Make Link" or whatever your file manager shell says. If you use Thunar like I do you can send a shortcut to the desktop and then rename it from "link to linux 2.6.39.4" (in my case) to "linux". If you moved the shortcut to the desktop, move it back to /usr/src after renaming it.
There are a couple more exercises like this ahead. Move into the directory that holds the source for your kernel and open a terminal, or open it first and then type "cd /usr/src/linux" or the full version number if you did not create the link.
Type "make xconfig". There are a couple more options like gconfig or just config, but xconfig allows you to configure your kernel in a nice full-featured graphical environment and is in my opinion the best interface to kernel configuration. Some text should scroll by and a window should open.
If you are recompiling, or compiling a newer kernel from an older working config file, you can also use "make oldconfig". Like using the plain config command this runs in the terminal and will just prompt you for new features that have been added since your last configuration was written. To disable all new features and just use your old config file use "make oldnoconfig".
You might also want to consider just patching your kernel up to the latest version that you require.
Go to "Options" and make sure that "Show all options" is checked. This is to make sure you don't overlook something by mistake. Kernel configuration is dynamic and as you work your way down new options are appearing based on your choices that you knew nothing about.
Noone can help you which options and features you need to enable or disable. Usually one purpose of the exercise is to trim your kernel from stuff you don't need and will never use on your machines. Make sure you have support for all the file systems you're using and accessing on network drives for example. If you don't know about the names of the different file systems and which ones you'll need in day to day operation then you have no business compiling your own kernel and better wait.
You might want to get rid of hardware support for tape drives, joy sticks and game ports if you don't use them and are quite certain you never will. You should choose your processor type rather than just Generic, and a kernel with the PREEMPT option is a good idea for desktop machines as is a tickless kernel. To be honest, I've mostly run Slackware with the main distributed kernel which is built for server use without voluntary preemption and have never felt any performance issues on the desktop or with multimedia consumption. You've also got the option to build with full preemption, i.e. involuntary, which supposedly is best for multimedia production and extremely low-latency. Make sure you don't configure your file systems as modules or you will be unable to boot, unless you're using an initrd or initramfs. I'm now only building huge-smp kernels for Slackware, it's just easier.
When you're done, save your choices and quit. Your new configuration will be saved in /usr/src/linux/.config, or if you had a preexisting one you dropped in it will overwrite it or you can specify a different name like .config-my-kernel-version. For the make process to find it it needs to be called .config though. If you set up /usr/src/linux as a link to your real /linux-2.6.39.4 directory like previously discussed it is really saved there of course.
1.)Almost done now. You should still be in the terminal which has the directory with your linux source open.
Type "make bzImage" and watch your kernel compile. Even better, if you have several processors you can speed up the process. If you have a dual-core, type "make -j4 bzImage", for a triple-core like my AMD Phenom X3 type "make -j6 bzImage" or whatever is double your processor count.
2.)Once finished type "cp /usr/src/linux(-your-version-number if you did not create a link)/arch/x86/boot/bzImage /boot/vmlinuz-2.6.39.4". This copies your kernel to /boot. Obviously substitute the kernel version with whatever you used. You can delete the vmlinuz shortcut for you previous kernel in the boot directory and create a new one pointing to your new kernel, or leave it and just address them both directly with their versions. Same procedure as discussed before with the /usr/src/linux directory.
3.)Go back to the terminal and type "make modules". This will compile everything you set as loadable modules in your configuration.
4.)Type "make modules_install". You can combine step 3 and 4. This installs the modules for you, no need to copy anything this time.
5.)Now type "cp System.map /boot/System.map-2.6.39.4", and then "cp .config /boot/config-2.6.39.4", and then link them to your new kernel if you created the vmlinuz symlink previously, if not you can forget about the rest. You can do this in the file manager or just type "ln -s /boot/System.map-2.6.39.4 /boot/System.map" and "ln -s /boot/config-2.6.39.4 /boot/config".
6.)One last thing, the /etc/rc.d directory since recent versions houses a script that updates modules at every boot, to detect and add new ones. So you'll need to remove the rc.modules symlink pointing to the script aimed at your old kernel modules and add one for your new kernel. You can do it in the file manager or
rm rc.modules
cp rc.modules-2.6.37.6 rc.modules-2.6.39.4
ln -s /etc/rc.d/rc.modules-2.6.39.4 /etc/rc.d/rc.modules
All that's left now is to update and edit Lilo configuration in /etc/lilo.conf to add a boot stanza or adapt an old one if you already had several entries.
# Linux bootable partition config begins
image = /boot/vmlinuz-2.6.39.4
root = /dev/sda1
label = 2.6.39 or whatever you like
read-only
# Linux bootable partition config ends
Save it and run lilo from the terminal so it can find your kernels and update itself, otherwise you will not be able to boot your new kernel but the old one should still work, so don't get rid of it until you are fully certain your new kernel is working as intended in each and every way. That's it, good night.
Further reading:
Linuxtopia- Linux Kernel in a Nutshell (online version)
Building a Linux Kernel from Source
Kernel 3.0 Recompilation
How to compile kernel 2.6.39 in Slackware 13.1
Compilation and installation of kernel 3.0
