In Arch Linux, there are two ways to compile custom kernels:
We’ll use the traditional method because it applies to all Linux distributions, not just Arch Linux. In this document, we will refer to the ArchWiki page on the traditional method as KCT (for Kernels/Compilation/Traditional).
First and foremost, please take a snapshot of your VM before you get started.
Make sure you have the following kernel configuration/compilation dependencies installed:
base-devel bc python
Also make sure that you have
virtualbox-guest-dkms installed; this
will be needed to recompile your VirtualBox Guest Additions after you
build your new kernel.
virtualbox-guest-packages and are running your virtual machine without a GUI.
Upgrade your Arch Linux by running
sudo pacman -Syu.
Reboot and make sure that your system is all good.
uname -r to make sure that you are running the kernel from the
latest Arch LTS kernel package. At the time of this writing, my system
Instead of fetching the Linux source code from kernel.org as directed in the “Download the kernel source” section of KCT, you’re going to be compiling from the kernel source code provided in your GitHub skeleton repo.
The Linux kernel source tree can be found in the
kernel/ directory of
your assignment repo, which has been created from the upstream Linux source
repo from kernel.org. Follow the rest of this guide inside
You will build the kernel as a non-root user (i.e. as the user that you
normally log in as). Since you will be cloning into a local Git repository
from GitHub, you may build directly out of your repo (instead of putting
your repo in
~/kernelbuild/ as KCT suggests).
Don’t forget to run
make mrproper inside your Linux source tree.
Complete the following selected instructions, adapted from the “Configuration” section of KCT:
Generate the kernel
.config file from your running kernel:
$ zcat /proc/config.gz > .config $ make olddefconfig
zcat command dumps the configuration of the running kernel to
stdout, which we redirect to
Since the version of your running kernel is different from that of the
kernel source you will be working with, we run
make olddefconfig to
set the appropriate default values for any configuration options that
are defined for one kernel but not for the other.
You should give your self-compiled custom kernel a unique name to distinguish it from other kernels present in your system.
This is accomplished by setting the “local version” configuration, or
CONFIG_LOCALVERSION variable in your
.config file. You can set
make menuconfig, as described in KCT.
The name of your kernel will be the Linux kernel version appended with
the local version. For example, if we build a 4.9.81 kernel with the
local version set to
-cs4118, it will be named
make menuconfig modifies your
.config file, and creates a back up
of the original
.config file as
.config.old. Take a moment to inspect
the contents of the
Of course, you can modify the
.config file by hand. In that case,
make sure to back up the original
You may verify your changes using the
diffconfig utility script that
comes with the Linux source tree, like this:
$ scripts/diffconfig .config.old .config LOCALVERSION "-lts" -> "-cs4118"
Follow the “Compilation and installation” section of KCT with the following selections/changes:
Compiling a kernel takes a long time–it can take over an hour on a slow
machine. If your computer has multiple CPU cores, configure your VM to
use them all. Then, instead of
$ make -jN
N is the number of parallel jobs you would like
make to spawn.
Use the number of CPUs for
N. So for a 8-core (virtual) machine, you
Whenever KCT says “YourKernelName” or “FullKernelName”, use your kernel
version string, e.g.
For the “Copy the kernel to /boot directory” section, we’re going to be
using the 64-bit kernel, so make sure to grab your boot image from
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-4.9.81-cs4118
For the “Make initial RAM disk” section, just use the one-liner manual method. For example:
# mkinitcpio -k 4.9.81-cs4118 -g /boot/initramfs-4.9.81-cs4118.img
Don’t forget to copy the
System.map file, which will be useful for
# cp System.map /boot/System.map-4.9.81-cs4118
Some old programs look for
/boot/System.map instead of
/boot/System.map-<kernel-version>, so let’s create
# ln -fs /boot/System.map-4.9.81-cs4118 /boot/System.map
Verify that you have the following 3 files and 1 symlink in
vmlinuz-4.9.81-cs4118 initramfs-4.9.81-cs4118.img System.map-4.9.81-cs4118 System.map -> /boot/System.map-4.9.81-cs4118
Now, you need to add your new kernel to the boot menu. Regenerate
# grub-mkconfig -o /boot/grub/grub.cfg
GRUB will automatically find and add all kernels in
/boot to the boot menu.
If we’re using VirtualBox Guest Additions, we need to do one more thing before we reboot to our new kernel. We have to recompile the VirtualBox guest module so that things like screen resizing will still work after we reboot.
vboxguest module version:
$ dkms status -m vboxguest
You may see multiple similar rows, one for each kernel version. The
vboxguest version number is in the second comma-separated column. For
example, mine is
5.2.6_OSE at time of running.
vboxguest module by running:
# dkms remove vboxguest/<vboxguest_version> -k <kernel_version> # dkms install vboxguest/<vboxguest_version> -k <kernel_version>
<vboxguest_version> is what you found in the previous step
<kernel_version> is your kernel version string
from the previous section (e.g.
4.9.81-cs4118). Keep in mind that if you
vboxguest previously installed, the
dkms remove step will
throw an error.
Reboot by running:
and make sure to pick your custom kernel from the bootloader menu.
Now verify that you’re running your own custom kernel by running:
$ uname -a
4.14.19-lts, you should now see your kernel version string,
Last updated: 2018-02-24