Compiling your own kernel in Slackware Linux in 10 easy steps…
- This guide assumes you are logged in as root.
- This guide is for re-compiling a Slack kernel rather than upgrading it.
- If compiling the kernel as root worries you, compile as a non-root user.
- DO NOT compile a pre-release kernel as root.
- Slackware ships with stable, tested kernels so don’t worry.
- I personally follow this process as root.
- I make no guarantees of any kind.
1. Clean your kernel source
make mrproper
2. Use the provided generic kernel as a template
3. Modify the config
This is the hardest part. But it’s hard like a three month old banana is hard.
You can choose one of three tools for the job: config, menuconfig or xconfig. If you choose anything other than menuconfig you are insane and will be shot when the new world order comes to fruition.
make menuconfig
You will now be presented with the kernel configuration menu.
a. Change your LocalVersion
You could overwrite the old generic kernel if you wanted to. Don’t. Re-label your kernel so that it’s called something else.
- Select “General Setup”
- Press Enter
- Press the down cursor key once
- Press Enter
- Type the “-” key and then a word that pleases you. I usually use the hostname of the machine.
- Press Enter
- Press the right cursor key once
- Press Enter
Voilá, you’re back at the first screen. From this point on I am going to assume that that was sufficient practice for you to handle modifying a kernel option on your own and will become less patronising.
b. Select your processor family
This isn’t technically required, but to build your own kernel and not have it optimised for your processor is insane. So do it.
- Select “Processor type and features”
- Select “Processor family”
- Select the right processor family for the processor in the machine on which the kernel will be running
If you don’t know which processor family is right for your processor, follow this link.
c. While you’re there, how much RAM have you got? (32-bit Slackware only)
If you have 3.5GB RAM or less, skip to the next step. If you have more than 3.5GB RAM, while in the “Processor type and features” menu, go down to “High Memory Support” and change it to 64GB. Don’t argue, just do it.
d. Compile-in your root file system
I’m going to assume you know what file-system you have installed on your root (/) partition. If you don’t know then it’s ext3 if you’re on Slackware 12, or ext4 on Slackware 13. Go back to the main menu and head down into the “File systems” submenu. Find your file system in the list and once it’s highlighted, press “y” to ensure that it’s compiled-in [*] rather than compiled as a module [m] or not compiled at all [ ]. There are more options for your file system, but the defaults will suit you just fine.
e. Compile-in the storage controller for your main hard disk
This is probably the hardest step of the entire process. It’s not month old banana, more like week old pear. The reason it can be difficult is you need to find out what driver is required for your disk controller. Some are easy, some aren’t. For example, an Asus motherboard with an nForce chipset has six or so primary SATA ports. If your disk is plugged into one of these, the option you want is:
- “Device Drivers” -> “Serial ATA (prod) and Parallel ATA (experimental) drivers” -> “NVIDIA SATA Support”
If you have an Intel motherboard then almost certainly all you’ll need is:
- “Device Drivers” -> “Serial ATA (prod) and Parallel ATA (experimental) drivers” -> “Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support”
In any case, it is up to you to be sure what you need. If you get it wrong, it’s not the end of the world, you just reboot into the working kernel and try again, but if you want to save yourself hassle, get it right first time. Once you know which one you need.. make sure it is selected for compile-in [*]. If you’re feeling experimental, you can then change any other controller that is currently compiled-in to compile as a module [m] by highlighting it and pressing “m”. This will make your kernel image smaller and your system leaner and faster as you wont have unnecessary code clogging up your kernel, but it won’t make your system any less functional as you can always load the code as a module if you need it.
That’s it.. it’s all downhill from here.
4. Compiling the kernel
Exit the config utility and save the kernel config when prompted.
Copy the config right now. Since you’ll copy it later anyway, do it now so you have a backup in case you do anything stupid like a `make mrproper` in the kernel source directory.
where <LocalVersion> is the string you added in the kernel config LocalVersion option.
Time to make your kernel:
This will compile your kernel and on a reasonable system take 20-ish minutes. The -j7 tells the compiler how many threads to run at once. On a single core, single processor system, reduce this to -j3. On a reasonably average system use -j5 or -j7. On a Xeon E5520 single-processor system (8 cores) use -j11. On a twin-processor, Quad-Core Xeon system use as many as you want.
Go make a cup of coffee while it compiles..
Go on.. I’ll wait…
Ok, so that’s it, you’ve compiled your kernel.
5. Install the kernel modules
This bit’s really hard:
Told you.
6. Install the kernel, config & System.map
For 32-bit Slackware:
or if you’re running Slackware64:
System.map:
config (I know you already did it, but just in case):
7. Update your symlinks
rm System.map vmlinuz config
ln -s System.map-generic-smp-$(uname -r)-<LocalVersion> System.map
ln -s config-generic-smp-$(uname -r)-<LocalVersion> config
ln -s vmlinuz-generic-smp-$(uname -r)-<LocalVersion> vmlinuz
8. Update lilo
You will already have a section like this to boot your new kernel:
root = /dev/sda1
label = Linux
read-only
although you may want to change the label to reflect that it’s your new custom kernel.
You also need to add a line for the huge kernel as a just-in-case. This will allow you to boot straight back into your system in case your generic kernel is borked. You need to check your /boot directory for the correct filename, but it will almost certainly be exactly like the example, but with a specific kernel version in the name.
root = /dev/sda1
label = Slack-HugeSMP
read-only
9. Run lilo
10. Reboot
Cross your fingers, because if all is well, you will now reboot into your own custom kernel. No initrd, no bloat, just Pat’s generic kernel with a performance tweak and the drivers you need to boot with.
Tell me that wasn’t simple(!)
This guide is purely for the idiot-proof 10-step simple-rebuild process. If you want to upgrade to a new version, or start with a clean config, or do more aggressive kernel tweaking, or play with on-boot modules, or make an initrd (shudder) then you should head over to alienBOB’s guide on the SlackBook Wiki: http://alien.slackbook.org/dokuwiki/doku.php?id=linux:kernelbuilding

This is a good how-to – the best I’ve seen. I’ve used Debian and OpenBSD for a while but I’m totally new to Slackware. There are many things about it that attract me, especially now that we have an official 64-bit port.
One question I can’t seem to find a satisfactory answer to – does compiling or updating a kernel break software installations? And if so, is it more likely to break pre-packaged software or roll-your-own software? Perhaps compiling a new kernel should be the first thing you do on a new system for this reason?
Don’t flame me – I’ve looked into loads of things on the web and my head now hurts with all the info taken in. Sometimes all a person needs is a simple answer, and sometimes the simple answer is the hardest to come by!
@Gerard Lally
You have asked a good question.
In general, a different kernel will not affect software you have installed. There are exceptions, specifically if you make a major version jump – but this guide is about making a custom kernel from a template of the same version rather than upgrading – upgrading has new steps to follow and I might add something about this later on.
What you *do* need to be concerned about is kernel modules. When you re-compile your kernel, you are creating a new kernel modules tree in /lib/modules/$(uname -r) and any kernel modules you have compiled will need to be re-compiled. Technically you could copy them from the old modules tree, but I do not recommend this.
The most common kernel modules that people create are for drivers and virtual drivers. In my case, that would be the NVidia graphics driver, and the VirtualBox networking driver. If I compile a new kernel, then my very next job is to re-install the graphics driver (taking the opportunity to get the latest version) and use sbopkg to re-compile the VirtualBox driver. Basically ANY kernel module you’ve created alongside installed software should be recompiled.
As you stated, this is made a lot easier by making the new kernel the first thing you do after installation of the operating system, I certainly do.
Thank you. I am particularly interested in the kernel modules aspect because I am running my Debian host as a KVM host, a Samba and NFS server to KVM guests, and a Postfix server to guests as well. KVM in this case would have to be recompiled but Samba and Postfix not?
Debian is serving me quite well as a KVM host but Slackware seems to be a leaner distro by default, which appeals to me because I want to reserve most resources for the guests. One of the reasons I want to move from Huge to Generic. Your guide answers a lot of questions I had.
@Gerard Lally
Good reasons all. I definitely recommend Slackware above all else for pretty much any purpose. I use it for servers, desktops, laptops — anything really. Always suits my needs.
My KVM knowledge is very limited, but it sounds like you have it right. Userland samba tools won’t need recompiling, NFS (and parts of samba) is actually part of the kernel itself, so when you recompile, you will automatically be recompiling NFS.
I was under the impression KVM was part of the kernel, and if it is, then again it will be compiled when you compile the kernel (whether as a module, or built-in), but if there is anything related to KVM that you are adding from external code built as a module, then those module(s) will need rebuilding.
KVM is comprised of kernel modules and userland. Kernel modules do come with the distro but the latest version is also bundled with userland in the source package you get from the KVM site. It’s probably best to compile these newer ones into the kernel, although the latest Slackware most likely has them already.
As an aside, I have found KVM leaner and faster than VBox. It’s worth another look.
One last question and I’ll leave you in peace: in his book, Linux Kernel in a Nutshell, kernel developer Greg Kroah-Hartmann is adamant you should NEVER compile as root. Yet most guides including yours take su to root for granted for all steps. I think this is something you could clarify in your guide. Should we compile as ordinary user in our home directory, leaving root to do just the final install, or as root all the way, in /usr/src?
@Gerard Lally
It’s your choice.
As far as I understand it, the reason it is recommended that you do not compile the kernel as root is that the compile process includes all kinds of scripts and code from many different sources. If one of those bits of code does something malicious, even if it’s accidental or because of a typo somewhere, because the compiler is running as root it is free to trash your system.
For what it’s worth: DO NOT compile a pre-release kernel as root.
As for what you do on your system with stable, released kernels – it’s entirely up to you. Compiling as root is not “wrong” per se.. just potentially dangerous. How risky it is is for you to decide.
@Gerard Lally
The page has been updated to include notes at the top regarding root/non-root.
Re compiling as root:
My (limited) understanding about this is that it is not so much about compiling as root but compiling in place in the /usr/src tree (which you need to do as root, of course). Somewhere recently I came across some remarks that the reason it wasn’t recommended was that, historically, too many ignorant users were unintentionally recompiling libc as well with newer headers, which of course potentially broke already-compiled programs.
The kernel-devs got tired of responding to complaints about how “compiling the kernel broke my system”, so started to recommend the new source tree be placed somewhere else and the compile done there, thereby preventing recompiles of system libraries. Over time, it’s taken on a bit of a mantra.
From memory, I read this in Slackbook’s section on kernel compiling, but don’t quote me.
Update: It was alienBob’s guide to building a kernel.
I don’t see in “High Memory Support” in the “Processor type and features” menu (2.6.31.6)
@TVN
Is this Slackware or Slackware64?
In a 64-bit kernel there is no need for High Memory Support.
Can you please provide a printer-friendly version of this article?
@mwnn
Look at the very bottom of the article. Under the heading “Share and Enjoy: ” the first icon is a link to create a print-friendly version using printfriendly.com
Thanks for such an easy to follow method! It is greatly appcreciated. Everything went smoothly for me! Now it is time to move onto more fun stuff! patching…
Happy New Year!
@Rojiru
Tell your friends
How about some pointers on upgrading a kernel to a more recent version?
How about including ppc and yaboot specific information
@ant2ne
This guide is intended to be as simple as possible; a ten step guide anyone can follow to make their first generic kernel based on Pat’s and learn from the experience so that they can do it again or do upgrades or other customisations later.
I might put up a separate post some time about the upgrade process, even though it’s pretty simple.. but I’m unlikely to put up ppc/yaboot specific info as I use neither.
Hey Zordrak,
about new kernels (2.6.33 as example), there are new ways to get the modules compiled right?
you have already tried?
you will update this post to complain with new rules?
@Klein
I have no idea what you mean.. can you be a little more clear?
i read in somewere that new kernel compilation process use information about lsmod and another things to automatic built in the modules that are loaded in the system.. but I dont know details and haven’t tried…
@Klein
I guess you’re talking about the make targets “localmodconfig” and “localyesconfig” introduced in 2.6.32:
http://kernelnewbies.org/Linux_2_6_32.
Personally, I do not use them. Generally, I do not recommend using them. They are simply a way of avoiding learning about what you are doing. Bypassing the learning is the Red Hat Way; it is not my way.
Also, you can get very unexpected results such as lacking any kernel support for hardware you use because the hardware wasn’t plugged in or the module wasn’t loaded when you did the configure.
Stick to the manual way that keeps you on top of your system.
Hi Zordrak,
Great article which has guided me through my first kernel compile on Slackware 13.1 with absolutely no problems at all. Thanks a lot
.
Andrew
Can you change “make modules_install” to “make modules && make modules_install”
Thanks. Great guide too. Very very helpful.
@Elias
“make modules” is superfluous. For some time now, the default make target for the kernel has been compiling the kernel and the modules, so instead of make && make modules && make modules_install, all you need it make && make modules_install.
Hey thanks Zordrak!
I have a custom recompiled kernel up and running in my first attemp!
But now I am unable to compile nvidia/vbox as it says that kernel source don’t match the version, like this:
Makefile:170: *** Error: /usr/src/linux (version 2.6.33.4) does not match the current kernel (version 2.6.33.4-kpz). Stop.
Is there something I missed or do I need to perform any additional steps?
Thanks again.
Hey, thanks for the great guide! Before I did this, I didn’t take note of how much disk space I was using. Now that I have two options when I boot, normal, and high mem support, and I using significantly more disk space? If so, what could I delete to free up some space. Thanks!
@kapz
Following the guide, /usr/src/linux should be the configured source for your running kernel. If for whatever reason the location of your configured kernel source is different to /usr/src/linux, then you need to tell that to the build system for any modules you want to compile.
e.g. $ KSRCDIR=/usr/src/linux-2.6.24.5-newkernel ./module-builder
@Dominic
If you didn’t take note of how much disk space you were using before.. how do you know you are using a lot more now?
Pull “ncdu” from slackbuilds.org and use it to find out where your space is being used. I wouldn’t expect there to be lot of use by kernel sources and build directories – but it entirely depends on what “a lot” means to you and what available resource your machine has.
I’m trying to re-compile based on the 13.37 dvd iso, my system is a 12.0 system. I’m compiling the kernel for another system which has a lsi raid controller and the lsi does not work with the huge.s kernel from slack 13.37 so.. what things do I have to do differently when A) compiling for 13.37 using the iso I downloaded (while on my 12.0 machine) and B) compiling the kernel for use on a different system that may have a different architecture.
Hy all, i have followed the tutorial, no errors but slackware stil sees only 3 gb. I don’t know to do. I can’t do a fresh install. Any ideas ?
@Zordrak
Hmmm, why not just put a simlink to /usr/src/linux to point to the real source location to the current running kernel?
@kscharf
In the above, that is done. Note the first step is “cd /usr/src/linux”.