You must rebuild the latest stable Linux kernel from source on your system. While many distributions provide both binary and source packages for their version of the kernel, you will download the latest version of the stable kernel from www.kernel.org. You will verify you have all the kernel building requirements (proper versions of tools, enough disk space), then configure, build, and (as root) install your new kernel. Note you don't have to be root to build a kernel, just to install one.
Make sure your new kernel includes the features needed in this course, including:
iptablespacket filter code) and related features
.configsupport → Enable access to
(Building features you don't need, even as modules, takes extra time and disk space. Don't include features you are sure you don't need (e.g., ISDN support). If in doubt, you can include the features as modules.
Make a copy of your system journal pages that document the steps done and the kernel configuration you chose. (Note if you get the configuration wrong, it is a simple matter to change it and then rebuild the kernel from that point to use the new configuration.)
(See the kernel resources on our class web page.)
For this project, you may work either individually or in a group. Each student must submit their own copy of the assignment, which must include your name and the names of the others in your group.
dnfupdates (and installing if needed
make, and other required tools). A good way to do this is to install the various
dnfgroups, such as “Development Tools” and “Development Libraries”. That will install most but not all items needed to run
make xconfig. Don't forget to add to your journal, all the software you installed.
unamecommand to check.)
2.6.X.Y. The version numbers of more recent kernels are
4.X.Y.) (You can easily find out from www.kernel.org/kdist/finger_banner, or just from the home page.)
df -hcommand. (Note the download, even after uncompressing, isn't this large: about 40MB to download and about 550MB to unpack). But many large files are created during the install, so this much space is needed, at least temporarily.) Which filesystem has sufficient space? (Prefer
/usr/src(not recommended!) you must take care not to overwrite existing files there. Depending on your distribution, you may have to rename some directories and files there. If you ignore my advice and install there anyway, then rename an existing source directory of
/usr/src/linuxto include the kernel version. For example, if you currently have version
4.5-1.358installed, the source should be in a directory
/usr/src/linux. Also check for a
/usr/src/.configfile, and copy it to
/usr/src/config.old. A backup of your
lilo.conf) would be a good idea as well.
If not using
/usr/src/ (a wise decision!) then you might
config file of your currently running kernel
Try looking in
/boot/ for a kernel
kernel.orgto find the correct URLs to use, something like the following should work:
mkdir ~/build; cd ~/build wget ftp://ftp.kernel.org/pub/linux/kernel/v4.x/linux-4.X.Y.tar.xz wget ftp://ftp.kernel.org/pub/linux/kernel/v4.x/linux-4.X.Y.tar.sign
gpg. What is the ID of the Linux Archives GPG key? What was the result of the verification? To save disk space, you can verify the file without uncompressing first, by using a command line similar to:
xz -cd linux-4.X.Y.tar.xz | gpg --verify linux-4.X.Y.tar.sign -
If the verification fails, it might be that the procedure has changed (it has in the past!), or your download might be faulty. In that case, check for the proper procedure (using your awesome Google skills), and/or try downloading again.
tar -xf linux-4.X.Y.tar. (This may take a short while.) (Note, doing this step can double the disk space used. You can recompress the tar-ball (if you uncompressed it earlier), and unpack the smaller, compressed archive directly.) This should create a new subdirectory named “
When installing under
/usr/src, at this point you should
to create a symbolic (soft) link to the
with the name
Then you can
cd /usr/src/linux and complete the
install from there.
(Of course you should build in your home directory.
The kernel build system allows the source to be built in one
place and installed in another.)
cdinto the new subdirectory and clean up the source with the commands
cd ~/linux-4.X.Y make mrproper
(That last step shouldn't be need for fresh source, but it can't hurt!) The source is now installed and ready to be configured and built.
If you had any patches to install, now would be the time. Note that Red Hat does provide a source RPM package containing the patches they used for the shipped kernel for Fedora, but we shouldn't need it for this project.
To patch the Linux kernel, make sure you have the correct source code version for which the patch applies. Linux 4 patches apply to the head source code (4.X), not the latest stable code (4.X.Y)!
For example, if you have 4.5.2 and want to apply patches to get to 4.7.3, you need the 4.5 source code installed, then apply the 4.6 patch, then the 4.7 patch. These kernel patches aren't cumulative (unlike Microsoft service packs). You need all the patches between the version you have and the version you want, and must apply them all in order.
Once you have patched your way to the correct 4.X version, you can then apply a single (cumulative) patch to that to get the latest stable version (4.X.Y).
Unofficial patches are more dangerous than official ones.
Make sure you really need to do this!
In all cases use
gpg to verify the originator and
integrity of the patch file you have downloaded.
To apply some patch called
to the source do the following:
# mv patch-4.X.xz ~/build # the parent directory of the kernel source # cd /usr/src/linux # bzip2 -dc ../patch-4.X.xz | patch -p1
For Solaris and other commercial Unixes the patches are binary files
that modify the kernel image file (and LKM files).
To patch your kernel with a Solaris (binary) patch you can use the
patchadd -p to see list of installed
Or you can use
to manage your patches.
However the easiest way to manage Solaris patches is to use the
popular (but 3rd party)
You can obtain
Solaris patches can be download from www.sun.com/sunsolve/patches/. (Note Oracle no longer distributes Solaris patches for free.)
gccis installed with
gcc --version. What version of
gccdo you have installed, and what is the minimal version required?
(lspci; dmesg; cat/proc/cpuinfo) |lpr
Other commands may be available such as “
you install them.
make helpfor choices, and note that Fedora puts the installed kernels' config files in
The current config is a good place to start.
Copy the current kernel's config file to
Now run these commands to begin:
make silentoldconfig # to update .config with new options; choose the defaults
When it pauses to ask you about a new configuration item, you can hit the
Enter key to choose the default choice.
When done, the original
.config file is saved as
Once you have updated your configuration for the options of the new
kernel, it is time to “tweak” it.
You need to run one of the various config user interfaces, for example:
make xconfig # to complete the configuration usig a Qt GUI interface
The error message(s) you might get first when you try to run
make xconfig” will likely tell you what's
missing, and some work with
dnf will tell you which package(s) you
need to install (almost certainly some
Hint: A message about “can't find
means the compiler couldn't locate the library file
Again you can use
dnf to see what package provides the missing
Be sure to add to your journal all the packages you needed to install.
For most choices you have the option of including the code in the
base kernel (a checkmark shows), including it as a module (a dot
shows), or not including it at all (the checkbox is empty).
The defaults include a lot of useless stuff as modules, which
doesn't hurt a thing except take up extra disk space.
However it can cause the build to last several hours!
If you skip some code for now and decide you need it later,
it is not hard to re-run “
make xconfig”, and
mark the code to be included as a module.
Then you build just the missing code with
make all modules_install”.
(Of course you will need to update the
as well, or your new module won't be available to the kernel until
after the root filesystem has been remounted.)
If you're not sure which options to include, examine the system information you printed earlier for clues. A number of changes to the default configuration are shown below, by way of illustration. Your configuration will be very different than this! I provide this information for an example only.
LOCALVERSIONstring to “
.config support and access means you can
extract the config information from the running kernel,
Loadable module versioning can cause headaches and is only
useful if you try to run modules from different kernel versions.
I selected the correct CPU type I actually have.
You also need to enable Preemptible Kernel or your
GUI will be horribly slow!
(This is due to a change made in the 2.6 kernel.)
The SELinux options support
SELinux in the kernel, but you still need to
enable it by default when booting.
The other options I changed just for fun.
I also disabled some code built as modules by default, stuff like
ISDN, frame-relay, battery monitor, and other laptop
A more through job of turning off stuff that isn't needed would have
saved a lot of time!
Note that features built as modules aren't available until the module is
For example, if the
/proc/config.gz support is built as a module
(which is the default), the file won't be there
until you load the correct module (using
You have the option to build most features (including that one) into the
base kernel directly, if you wish.
(Or you can configure
modprobe to load a module automatically
at boot time.)
Go through the configuration choices and read the help on each before deciding what to change.
Remember you must include support for your hardware and IPv4,
netfilter (iptables), Preemptible Kernel, a custom “LOCALVERSION”
string (see below), and Kernel
.config support →
Enable access to
What configuration settings did you change
from their default (or current kernel's) values?
(Just describe briefly.)
The installed kernel will have a version number of
If you install any patches or have custom configuration, you may
end up with several kernels with the exact same name.
To avoid this,
you should change the value for
LOCALVERSION to something like this:
Here I use a dash, my initials and the date, but you can use any
string you wish that makes sense to you.
The resulting kernel will have the name
You will find the setting for this under the “General Setup”
section when you configure the kernel;
double-click the option and you will be allowed to type in the new value.
.configfile produced as a result of your
make xconfig. You can also use
diffto compare this configuration to the old Fedora one. If you change your mind about any options, you run the “
make xconfig” command again and make any needed changes.
Show the results of running diff on the original and final .config files.
Make a backup copy of your final
.config file someplace.
Be sure to name it correctly with the kernel version
(and local version string).
date >~/build-date make -j $(nproc) # This can take several hours if you use one core only! sudo make modules_install # you need to be root for this part! date >>~/build-date
When I compiled my model kernel using the above steps, it took
about 2.5 hours using one core only.
You can greatly speed up the build on a multi-core machine
by using the “
-j number” option,
where “number” is the number of cores on your
You can determine this by examining
or (as shown above) use the
When this runs in verbose mode, a lot of messages will scroll by very quickly,
including some “warning” messages.
This is normal.
The time to worry is when you see “error” messages.
(When I built a kernel, there were some warnings, and one error message
for the third-party “VirtualBox” kernel module.
However the kernel works without it, and that module should be built later
How long did the build take?
(Just look at the
build-date file and compare the times
make mandocs sudo make installmandocs
You should expect to see many warnings, which you can ignore. (This step can take over an hour! I have never understood why it takes so long to format and copy documentation, but I was told the time it takes is the reason why Fedora no longer includes a kernel documentation package.)
make installcommand (which must be run as
root), but this may or may not work correctly on all systems. (Currently it works fine on Fedora and other Red Hat like systems.) This command invokes the shell script
/usr/src/linux/arch/i386/boot/install.shto do the install. This script in turn runs an
installkernelscript if it exists. (It does on Fedora, in
/sbin.) Otherwise, the script tries to install the kernel itself, unfortunately configuring LILO and not GRUB as the bootloader. Fortunately, Fedora does include a
/sbin/installkernelutility, which copies the files, creates the ramdisk image needed, makes the correct links, and updates the GRUB configuration for you (via another utility,
/sbin/new-kernel-pkg. That script invokes other scripts, and eventually a command called
grubbyto actually update the
make install, you can install the kernel manually. This involves copying (or linking) two files into
/boot, building an initial ramdisk, and updating the boot loader configuration. Part of this process is to make sure you can boot from your previous working kernel if the new one doesn't work.
(Skip this step, as Fedora does support
/boot, using the correct name. Create the correct links. The kernel can be found at
/boot, again using the right names and links.
depmodcommand to update the dependency information for the new kernel modules. Check the man page for the correct options to use.
dracut(or the older
mkinitrd). For example using version 4.4.2 (and no local version):
dracut /boot/initrd-4.4.2.img 4.4.2
vmlinuz-version-localversion(if I used any local version name). Then I use symlinks to the current and previous kernels, with the names
vmlinuz-old. Then I update the boot loader to show both.
make install, you may still need to edit the Grub configuration. This is because by default the system may boot your old kernel, not the new one. You want the new kernel as the default, with the old (working) one available. Changing this depends on which boot loader you use. For old (legacy) grub, change the “
default=1” line to read “
default=0”, assuming your new kernel is listed first in the file. For the newer GRUB2, you can use
grubby(if available), or (on Fedora anyway),
grub2-set-default. Directions for this were given in class; ask your instructor if you need the lecture notes on this topic. (For default on some versions of Fedora, by default GRUB2 will remember the last booted kernel, and boot that by default. You can change the last remembered kernel using
unamecommand to see if it is indeed your new kernel running. (Also check out the
/proc/config.gzfeature!) If it doesn't work, reboot using the old one, change the configuration, build additional (or fewer) modules, and/or patch the source code, and then try again. Make careful notes as you go, so you can correctly update your journal later!
If the kernel build was a success, you can reclaim most of the space
used by running the command “
which will leave the
.config and other files, sufficient to
later build third-party modules.
(Or, you can delete the entire directory, but I would save a copy of
.config file first.)
Answers to the above questions and the relevant system journal entries. You can send as email to (preferred). If email is a problem for some reason, you may turn in a hard-copy. In this case the pages should be readable, dated, and stapled together. Your name should appear on the first page. See System Journal Hints for more details.
Don't turn in your whole journal, you will need to add to it every day in class! It is common in fact to keep the journal as a text file on the system (with a paper backup of course).
Please see your syllabus for more information about submitting projects.