📅 December 6, 2014
The Linux kernel is the engine of Linux. The core. And just as a newer automobile engine can offer improvements and features not found in older models, a newer Linux kernel can offer bug fixes and improvements lacking in earlier versions.
Linux kernels are continually being improved, updated, and endowed with newer features for improved compatibility with new hardware technologies, so if you are experiencing hardware issues, then a kernel update might be worth trying.
Maybe you seek a kernel more recent than what is offered in the current repository? Perhaps you are curious to install the latest kernel to see what it can do? Whatever the reason, this article will show you how to easily install an upstream kernel in your Ubuntu-based Linux distribution.
In this article, I will be upgrading a Linux Mint 17.1 64-bit Cinnamon installation with the latest stable generic kernel 3.16.7. Rest assured, the process is easier than it sounds.
When we mess with the kernel, we are dealing with the “heart” of a Linux installation. If this is your first time to upgrade a kernel, I would recommend practicing inside a virtual machine, such as Linux Mint running in VirtualBox, to gain confidence and familiarity with the process before performing the update on your main machine…Just in case.
Also, backup any important data. I have never experienced any data loss or system corruption due to a kernel update, but again, this is just in case. Kernel updates are practically foolproof, but it never hurts to be sure.
On a final note, be aware that a system reboot is necessary following a kernel installation. Yes, yes, I hear the argument, “But Linux rarely ever needs to reboot!”
Yes, this is true, but when we update critical Linux system files, such as the kernel, a reboot is essential.
You can have many kernel versions installed at once, but only one runs at a time. There is no need to uninstall any previous kernels unless you wish to conserve hard drive space.
When the system boots, the default kernel (usually the latest installed) is loaded, but you can boot to the GRUB menu and choose which kernel you wish to use. Only one kernel is active at a time no matter how many are present on your system.
This is a good thing because it means you can test the new kernel, and if things do not work out, then you can boot to an earlier kernel and remove the new kernel using the Synaptic Package Manager.
Once the new kernel is confirmed to be working properly, I would recommend uninstalling unneeded kernels to save space. Many unused kernels together can consume several gigabytes of hard drive space, which is a precious commodity on a solid state drive should Linux be installed on one.
However, do not uninstall the first kernel that was originally installed with the Linux distribution since that is your fallback kernel guaranteed to function correctly with your chosen distribution. Also, it is usually a good idea to keep all kernels present that were installed as a result of a distribution upgrade.
Source or Precompiled?
This article uses precompiled kernel packages from http://kernel.ubuntu.com/~kernel-ppa/mainline/. While you can download and compile your own kernel from the Linux source code, I have found this to be a labor and time-intensive process. The last time I compiled a Linux kernel, the entire process took over five hours.
That was some time ago using slower processors. With Ubuntu-based distributions, we have the convenience of using the latest upstream kernels that have been compiled for us to save time.
Using precompiled kernels does carry a few risks:
1. We assume that the kernel is trustworthy. (Not malicious, no hidden rootkits, not filled with sneaky spyware, and so on.)
2. We assume that it will function as intended. (People make mistakes, and programmers are no different. Bugs can happen despite the best intentions.)
I have been using these kernels over the past several years, and I have never encountered any problems.
However, if you are paranoid or wish to compile a kernel with custom features, then give compilation a try. Kernel compiling is a great system-level experience…but you might find, like I did, that it is not something you will want to perform often.
Visit the uptream kernel web site and go straight to the kernel listing at http://kernel.ubuntu.com/~kernel-ppa/mainline/. We want mainline kernels. Each version resides in its own directory.
Kernel versions are labeled with a number, such as v3.16.7, v3.17, or v3.18. The higher the number the more recent the kernel.
But be aware!
There are two types of kernels: Developmental and Production. Developmental kernels have an odd second number (3.13, 3.15, 3.17), and they are under development until the bugs have been worked out. Think of them as beta kernels. Often, these kernels will run fine, and many distributions use them.
When a kernel’s bugs have been resolved and all is satisfactory, then the minor version number is rolled to the next higher even number, and the kernel is considered stable and fit for production machines. For example, 3.12, 3.14, 3.16, and 3.18 are production kernels of kernels 3.11, 3.13, 3.15, and 3.17. I always use the production kernels for stability.
Tip: When upgrading to a stable x.y.0 release, such as 3.14.0, 3.16.0, or 3.18.0, always check back for new x.y.1 updates. Often, an update will be released within a few days following an x.y.0 release. The release is usually accompanied by messages to the effect, “users should/must upgrade.”
For example, 3.18.0-vivid was released on December 8, 2014, and 3.18.1-vivid was released nine days later with an urgency to update on git.kernel.org. Nothing is perfect — even for a kernel release that is considered stable.
Even with production kernels, fine-tweaking might be required, so the third revision number indicates a revision. Higher revision numbers are newer kernels. As of this writing, kernel 3.16.7 is the latest production kernel, which is newer than 3.16.5 and 3.16.6, for example.
More information about kernel version numbers can be found in the book Linux+ Guide to Linux Certification.
Kernel Code Name
After the version, you will see the nickname used for Ubuntu distributions. In general, use the kernel that matches the name of your Ubuntu-based Linux distribution. For example, if you are using Ubuntu 13.04 (Raring Ringtail), then use a raring kernel. If you are using a Trusty Tahr distribution, then use a trusty kernel. However, this is not always straightforward.
“Does it matter?”
From my usage…maybe, but not always. At least not recently. Sometimes, the newer upstream kernels will use the next Ubuntu code name, but they will be completely compatible with the previous code name base.
Other times, I have tried to “mix and match,” but the the kernel refused to install due to compatibility/dependency issues. This happened often with Ubuntu 10.10 and anything above kernel 3.4.0. I found it problematic to use a 3.4-quantal (Quantal Quetzal) kernel in Ubuntu 10.10 (Maverick Meerkat). There were only two options at that point: Either limit myself to 3.4-precise or upgrade to a Quantal distribution in order to use newer kernels.
Lately, I have had no problems using a kernel labeled with the next successive code name. However, if I see that the kernel uses the same code name as the distribution I have installed, then I use that one.
Right now, I an using 3.16.7-utopic in Linux Mint 17.1 even though Linux Mint 17.1 is a Trusty Tahr distribution (The 14.04 LTS series). It installs and runs perfectly, and that is what this article describes.
Note: Some kernels, such as the 3.18 series at the moment, will have something like “rc1” or “rc7” prepended before the code name. From what I understand, these are “release candidate” kernels. Even though they carry the even minor version number that indicates a production kernel, they should be regarded as beta versions undergoing final testing before the true 3.18 kernel is released. The idea is similar to how some Linux distributions are released as “release candidate” distributions before the final release. Personally, I avoid all release candidate kernels and prefer to wait for the final production release.
Open the 3.16.7-utopic directory, and take a look inside. We see a list of files.
There are a number of files available, so let’s review them briefly in order to determine what we need to download.
32-bit or 64-bit?
Very important. If you are running a 32-bit (i386) Linux distribution, then you need to download the 32-bit (i386) kernel. If you are running a 64-bit (and64) system, then you need the 64-bit (amd64) kernel. Kernel files are labeled with either amd64 or i386 to indicate which is which.
Generic or Low-Latency?
You will notice an additional kernel choice in addition to 32-bit or 64-bit: Generic and Low-latency. Generic kernels are the default. They are supplied and installed by default in most distributions and suitable for everyday use. If you are running the default Ubuntu, Xubuntu, or Linux Mint, then you are already using a generic kernel.
A low-latency kernel is one that has been optimized for real-time or almost real-time events, such as real-time audio production or digital video editing where any delays in processing could produce out-of-sync results.
The low-latency kernel is better suited for specialized cases and distributions, such as Ubuntu Studio, so I will be using the generic kernel.
You can install both generic and low-latency kernels on the same computer, but only one kernel of any type and version can be active at a time. The selection must be performed at the GRUB boot menu.
Which Files to Download?
Only three are needed. In the example, we want to use the 64-bit generic kernel, so we select these three files:
linux-headers-3.16.7-031607-generic_3.16.7-031607.201410301735_amd64.deb linux-image-3.16.7-031607-generic_3.16.7-031607.201410301735_amd64.deb linux-headers-3.16.7-031607_3.16.7-031607.201410301735_all.deb
For a 32-bit system, select the i386 files instead.
linux-headers-3.16.7-031607-generic_3.16.7-031607.201410301735_i386.deb linux-image-3.16.7-031607-generic_3.16.7-031607.201410301735_i386.deb linux-headers-3.16.7-031607_3.16.7-031607.201410301735_all.deb
The format to remember is,
linux-headers....amd64.deb linux-image......amd64.deb linux-headers....all.deb
Notice that the same linux-headers…all.deb file is chosen. Generic, lowlatency, i386, and amd64 all share this same file.
Download these three files to a dedicated downloads directory.
What Kernel Do I Currently Have?
Open a terminal and enter,
This will return a line of information about the currently running kernel. The version appears after the computer name, and it should read something like 3.13.4 or 3.16.3. We will compare this version number after installation to see if the new kernel is installed and running.
You could double-click and install each .deb file individually, but I find it easier and faster to use the command line. Open a terminal in the directory containing the downloaded kernel .deb files, and type:
sudo dpkg -i *.deb
A few minutes will elapse, but when done, you will see the command prompt again. If no errors occur, then the new kernel has been installed.
Do We Need update-grub?
In the past, it was necessary to run sudo update-grub in order to update the GRUB boot menu with the new kernel, but with recent Linux distributions, I have found that step unnecessary. The kernel installation updates GRUB automatically. If you find that GRUB has not been updated with the new kernel (old kernel still being used upon future reboots), then you might need to manually enter,
Restart the System
The new kernel is installed, but it is not running yet. We must reboot. Restart the system normally. The new kernel should now load by default.
Is the New Kernel Installed?
Okay, your system is up and running. Nothing looks any different. How can we tell if Linux is using the new kernel? Open a terminal, and type,
You should see a line of information, and after the computer name should be the version of the new kernel. If it says 3.16.7, then well done! Linux is using the new kernel.
If the previous kernel version is shown, then the new kernel is not running. Use sudo update-grub and restart the system. Perform the uname -a test again. If you still do not see the new kernel, then we need to ensure that it has been installed.
Open Synaptic Package Manager and search for 3.16.7. All three 3.16.7 packages should appear. Synaptic will alert you to any installation errors, such as unresolved dependencies. If all looks good in Synaptic, then we might need to reinstall the kernel. First, choose all three 3.16.7 packages and mark the for complete removal. Apply. Reboot. Reinstall the kernel package files with dpkg. Test again. If the new kernel still does not work, then double-check that the correct files were downloaded. (If the wrong files were downloaded, then errors should have appeared during the first installation.)
Cleaning Up Unneeded Kernels
Once your new kernel is confirmed to be working properly, you might want to remove older, unneeded kernels from your system to conserve hard drive space. Open the Synaptic Package Manager, and search by the kernel version you wish to remove.
Suppose we want to remove the 3.16.7 we just installed. We type 3.16.7 in the Quick filter text box (or use Search), and a list of the three kernel packages appears.
Mark each for complete removal.
Click apply. When done, the files will have been removed, but the 3.16.7 kernel will still be running in memory. We will need to restart the system, but do not restart just yet. We need to update GRUB so it knows about the changes we just made.
Open a terminal and type,
Even though we could skip the update-grub step during kernel installation with dpkg, we cannot skip it here. When done, reboot the system. By default, the latest kernel present on the system will be loaded for use.
Always keep the default kernel that was installed with your Linux distribution. This is a safety precaution in case you ever need to return to a known, working kernel.
There have been times when new kernels produced problems with proprietary video drivers, and the only way to resolve them was to boot to the default kernel that was originally installed with the system.
That’s all there is to installing an upstream kernel. Now, you can enjoy whatever fixes and features are made available in new kernels without waiting for official distribution upgrades.
Kernels are always being improved, but the installation principles remain identical. So, even though this article deals with kernel 3.16.7, you can apply the same process to future kernels.
For additional information about upstream kernels, read https://wiki.ubuntu.com/Kernel/MainlineBuilds to get started.