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

cd /usr/src/linux
make mrproper

2. Use the provided generic kernel as a template

cp /boot/config-generic-smp-$(uname -r) /usr/src/linux/.config

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.

cd /usr/src/linux # in case you left for some daft reason
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.

cp .config /boot/config-generic-smp-$(uname -r)-<LocalVersion>

where <LocalVersion> is the string you added in the kernel config LocalVersion option.

Time to make your kernel:

make -j7

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:

make modules_install

Told you.

6. Install the kernel, config &

For 32-bit Slackware:

cp arch/i386/boot/bzImage /boot/vmlinuz-generic-smp-$(uname -r)-<LocalVersion>

or if you’re running Slackware64:

cp arch/x86/boot/bzImage /boot/vmlinuz-generic-smp-$(uname -r)-<LocalVersion>

cp /boot/$(uname -r)-<LocalVersion>

config (I know you already did it, but just in case):

cp .config /boot/config-generic-smp-$(uname -r)-<LocalVersion>

7. Update your symlinks

cd /boot
rm vmlinuz config
ln -s$(uname -r)-<LocalVersion>
ln -s config-generic-smp-$(uname -r)-<LocalVersion> config
ln -s vmlinuz-generic-smp-$(uname -r)-<LocalVersion> vmlinuz

8. Update lilo

vi /etc/lilo.conf

You will already have a section like this to boot your new kernel:

image = /boot/vmlinuz
root = /dev/sda1
label = Linux

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.

image = /boot/vmlinuz-huge-smp-$(uname -r)
root = /dev/sda1
label = Slack-HugeSMP

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:

Be Sociable, Share!
  1. Gerard Lally
    September 9th, 2009 at 02:26 | #1

    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!

  2. September 9th, 2009 at 09:49 | #2

    @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.

  3. Gerard Lally
    September 9th, 2009 at 15:27 | #3

    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.

  4. September 9th, 2009 at 15:37 | #4

    @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.

  5. Gerard Lally
    September 9th, 2009 at 16:00 | #5

    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.

  6. Gerard Lally
    September 9th, 2009 at 16:29 | #6

    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?

  7. September 9th, 2009 at 17:47 | #7

    @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.

  8. September 9th, 2009 at 18:02 | #8

    @Gerard Lally

    The page has been updated to include notes at the top regarding root/non-root.

  9. NickC
    September 13th, 2009 at 05:15 | #9

    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.

  10. NickC
    September 14th, 2009 at 01:44 | #10

    NickC :
    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.

  11. TVN
    November 17th, 2009 at 01:06 | #11

    I don’t see in “High Memory Support” in the “Processor type and features” menu (

  12. November 17th, 2009 at 09:29 | #12

    Is this Slackware or Slackware64?

    In a 64-bit kernel there is no need for High Memory Support.

  13. mwnn
    December 9th, 2009 at 15:40 | #13

    Can you please provide a printer-friendly version of this article?

  14. December 9th, 2009 at 15:48 | #14

    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

  15. Rojiru
    January 2nd, 2010 at 23:24 | #15

    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!

  16. January 3rd, 2010 at 14:52 | #16

    Tell your friends :)

  17. February 10th, 2010 at 22:15 | #17

    How about some pointers on upgrading a kernel to a more recent version? ;-) How about including ppc and yaboot specific information ;-)

  18. February 11th, 2010 at 10:18 | #18

    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.

  19. Klein
    March 4th, 2010 at 22:21 | #19

    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?

  20. March 5th, 2010 at 10:16 | #20

    I have no idea what you mean.. can you be a little more clear?

  21. Klein
    March 5th, 2010 at 12:51 | #21

    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…

  22. March 5th, 2010 at 14:24 | #22

    I guess you’re talking about the make targets “localmodconfig” and “localyesconfig” introduced in 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.

  23. May 28th, 2010 at 09:35 | #23

    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 :).


  24. Elias
    June 27th, 2010 at 12:22 | #24

    Can you change “make modules_install” to “make modules && make modules_install”
    Thanks. Great guide too. Very very helpful.

  25. June 28th, 2010 at 09:23 | #25

    “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.

  26. kapz
    December 5th, 2010 at 06:07 | #26

    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 does not match the current kernel (version Stop.

    Is there something I missed or do I need to perform any additional steps?

    Thanks again.

  27. December 1st, 2011 at 06:34 | #27

    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!

  28. December 1st, 2011 at 12:41 | #28

    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- ./module-builder

  29. December 1st, 2011 at 12:43 | #29


    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 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.

  30. mike
    January 29th, 2012 at 01:52 | #30

    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.

  31. axwell
    February 25th, 2012 at 13:26 | #31

    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 ?

  32. kscharf
    January 11th, 2013 at 20:25 | #32

    Hmmm, why not just put a simlink to /usr/src/linux to point to the real source location to the current running kernel?

  33. January 15th, 2013 at 09:54 | #33

    In the above, that is done. Note the first step is “cd /usr/src/linux”.

  1. December 3rd, 2009 at 16:53 | #1
  2. February 14th, 2010 at 04:21 | #2
  3. April 12th, 2010 at 19:28 | #3
  4. April 20th, 2010 at 10:27 | #4
  5. August 25th, 2010 at 15:49 | #5
  6. December 4th, 2010 at 19:54 | #6
  7. December 5th, 2010 at 21:26 | #7
  8. January 19th, 2011 at 03:24 | #8
  9. February 16th, 2011 at 19:54 | #9
  10. June 23rd, 2011 at 14:39 | #10
  11. August 31st, 2011 at 04:00 | #11
  12. August 31st, 2011 at 04:34 | #12
  13. December 3rd, 2011 at 13:06 | #13
  14. January 28th, 2012 at 20:46 | #14
  15. March 9th, 2012 at 02:47 | #15
  16. April 3rd, 2012 at 21:06 | #16
  17. July 8th, 2012 at 06:49 | #17
  18. July 10th, 2012 at 00:37 | #18
  19. July 10th, 2012 at 01:08 | #19
  20. July 10th, 2012 at 14:08 | #20
  21. September 24th, 2012 at 13:40 | #21
  22. January 11th, 2013 at 17:23 | #22
  23. September 25th, 2013 at 02:11 | #23
  24. November 5th, 2013 at 22:54 | #24
  25. November 9th, 2013 at 22:07 | #25

Note: Commenter is allowed to use '@User+blank' to automatically notify your reply to other commenter. e.g, if ABC is one of commenter of this post, then write '@ABC '(exclude ') will automatically send your comment to ABC. Using '@all ' to notify all previous commenters. Be sure that the value of User should exactly match with commenter's name (case sensitive).