Welcome to the Kernel Frequently Asked Questions (FAQ)! The aim of this page is to provide an list of common questions that we get. We encourage you to update this document when something is missing so it becomes a core source of information for the project. Each question has its own page which are listed on the Kernel/FAQEdit page, which also contains guidance on editing the FAQ.
Something is wrong and I do not know where to start?
I have a kernel problem where do I go?
If you have a problem which is related to the kernel you should visit the #ubuntu-kernel IRC channel on FreeNode (See How do I find the kernel team?).
I have problems with Ubuntu where do I go?
If you have general issues you should visit the #ubuntu IRC channel on FreeNode, people here can help you work out where your issue is and to files bugs on it.
Where do I find the Kernel Team's documentation?
How do I find the kernel team?
The Kernel Team is primarily IRC based as we are located in disparate cities throughout the world. We typically hang out on the #ubuntu-kernel channel on FreeNode, please be patient if we seem to be quiet. See the KernelTeam page for more details.
How do I get involved with the Ubuntu Kernel?
The kernel team is always interested in getting community help on the kernel. We need help triaging incoming bugs, reviewing patches proposed for the kernel, as well as helping to fix launchpad bugs. For more details see Kernel/GettingInvolved.
Is there any process documentation for the roles within the Ubuntu Kernel Team?
Some of the activities which are the responsibility of the Ubuntu Kernel Team are documented in the team handbooks, see the Kernel/Handbook section of the documentation.
What do you need help with?
We need help with all aspects of the maintenance of the kernel. Probably our biggest project is triaging all of the incoming bugs filed against the Ubuntu kernel, you can help us to categorise these and get the necessary information to allow a developer to work on them, see Kernel/BugTriage for information on how you can help.
How does a Kernel Team script determine what Ubuntu series the bug was filed against?
The algorithm for determining the series a bug was filed against is given below. The order is significant and indicates the order the checks are made. As soon as a series is found, no further checks are made:
- Look in the bug description for:
"DistroRelease" which apport has been putting into the description for quiet some time.
- "Linux version string"
- "Description:" name/value pair which can contain the series version.
- "Release:" name/value pair which can contain the series version.
The string: "Ubuntu <series>".
- Look in log files that the original submitter has attached to the bug:
- "Dmesg.txt" / "dmesg.log"
- Look at the tags that have been added to the bug for a valid series. Note, there can be multiple specified so the first one found "wins".
- Look in the bug title for a valid series name. Again there can be multiple and again, the first found "wins".
How do I report a problem with the Kernel?
Details on how to file a kernel bug can be found on the Kernel/Bugs page.
LTS HWE Stacks
Include: Nothing found for "To remain on the original Precise stack"!
The Ubuntu LTS enablement stacks provide newer kernel and X support for existing LTS releases. These can be installed manually, or are automatically shipped if installing from 12.04.2/14.04.2 and newer release media.
These newer enablement stacks are meant for desktop and server use only, and not recommended for cloud or virtual images. To remain on the original stacks the options are:
Install from a previous 12.04.0/12.04.1/14.04.0/14.04.1 point release and update. Previous releases are archived at http://old-releases.ubuntu.com/
- Perform an update or upgrade to and LTS release from a previous release.
Perform a network install using the netboot images rather than the new <release>-netboot images.
The 14.04.2 and newer point release will ship with an updated kernel and X stack by default. If you have installed with older media you can use the following to install the newer kernel from 15.04 (Vivid):
sudo apt-get install --install-recommends linux-generic-lts-vivid xserver-xorg-core-lts-vivid xserver-xorg-lts-vivid xserver-xorg-video-all-lts-vivid xserver-xorg-input-all-lts-vivid libwayland-egl1-mesa-lts-vivid
If you run a multiarch desktop (for example, i386 and amd64 on amd64, for gaming or Wine), you may find you need a slightly more involved command, like this:
sudo apt-get install --install-recommends linux-generic-lts-vivid xserver-xorg-core-lts-vivid xserver-xorg-lts-vivid xserver-xorg-video-all-lts-vivid xserver-xorg-input-all-lts-vivid libwayland-egl1-mesa-lts-vivid libgl1-mesa-glx-lts-vivid libgl1-mesa-glx-lts-vivid:i386 libglapi-mesa-lts-vivid:i386
You can install either a kernel from 15.04 (vivid):
sudo apt-get install --install-recommends linux-generic-lts-vivid
Or you can install a kernel from 15.10 (wily):
sudo apt-get install --install-recommends linux-generic-lts-wily
The 12.04.2 and newer point releases will ship with an updated kernel and X stack by default. These current and supported hardware enablement stacks are comprised of the newer kernel and X stacks from 14.04 (Trusty).
Anyone wishing to opt into the hardware enablement stack for Precise may do so running the following commands:
sudo apt-get install --install-recommends linux-generic-lts-trusty xserver-xorg-lts-trusty libgl1-mesa-glx-lts-trusty
sudo apt-get install --install-recommends linux-generic-lts-trusty
Check your support status
If you want a tool to determine if your install is still supported please use hwe-supoprt-status as documented on https://wiki.ubuntu.com/1204_HWE_EOL
Below contains additional specifics regarding the exact policies and procedures regarding the support, maintenance, and upgrade paths for these hardware enablement stacks.
12.04.5 + 14.04 Hardware Enablement Stack Policies and Procedures
- For the 12.04.5 CDs, we will default to the new Trusty HWE stack. Due to size limitations we are unable to provide options for both the Trusty HWE stack and the original Precise stack.
- For the 12.04.5 DVDs, we will default to the new Trusty HWE stack as well.
The 12.04.0 and 12.04.1 point releases will be archived and available at http://old-releases.ubuntu.com/.
- For the 12.04.5 CDs and DVDs, we will document that anyone installing and wishing to remain on the original 12.04 stack to please install from the 12.04.0 or 12.04.1 media and update.
- We only intend to support HWE stack package combinations in 12.04 which are derived from the same release, eg. the 14.04 X.org must be used in conjunction with the 14.04 kernel and vice versa. Intermixing a 14.04 enablement kernel with the 12.04 X.org stack or a 14.04 enablement X.org stack with a 12.04 kernel will not be officially tested nor supported.
Anyone running an original Precise stack will NOT be automatically updated to the new Trusty HWE stack. Users can electively choose to install the Trusty enablement stack meta package if they wish to do so.
- Additionally, anyone upgrading to Precise will not be automatically upgraded to the new Trusty HWE stack. Again, they can electively choose to do so by manually installing the appropriate meta package.
- The original 12.04 stack in Precise will remain supported for the usual 5yr life cycle of the LTS release.
- The 14.04 HWE stack will remain supported in 12.04 for the life of the 12.04 LTS release.
- The 14.04 HWE stack will be the last and final HWE stack offered in Precise.
Anyone running with the newer Trusty HWE stack will remain on that stack. Users will NOT be automatically rolled forward to newer releases.
- Anyone running a Raring, Saucy, or Trusty HWE stack in 12.04 might have an unexpected result if they upgrade their entire system to the 12.10 Quantal Quetzal release. The packages offered in the Raring/Saucy/Trusty HWE stack would supersede the 12.10 packages. The decision was for update-manager to only prompt to upgrade to the next LTS release, which is how it is already. Otherwise, there should be some type of package conflicts/replace in place to prevent this from happening. This is only a real concern for the 13.04, 13.10, and 14.04 stacks.
- Apport has and will be updated to allow bug reporting in Precise against the HWE stacks. These bugs will also be appropriately tagged to assist in searching.
- Only the -generic x86 kernel flavor from 14.04 will be supported in the Trusty HWE stack in Precise.
Ubuntu Kernel Release Schedule
The following is a generic view of the Ubuntu release schedule, the kernels delivered, and the support time frames. 12.04, 14.04, and 16.04 will each deliver point release updates respectively (ie. 12.04.x, 14.04.x, 16.04.x) and eventually introduce newer hardware enablement kernels. Please refer to the 12.04.x, 14.04.x, and 16.04.x Ubuntu Kernel Support diagrams in the corresponding sections below for more details.
12.04.x Ubuntu Kernel Support
This is a distilled view of our 12.04.x Ubuntu Kernel Support Schedule.
14.04.x Ubuntu Kernel Support
This is a distilled view of our 14.04.x Ubuntu Kernel Support Schedule.
Ubuntu Kernel Support
This is a combined view of the diagrams from above (ie the Ubuntu Kernel Release Schedule combined with the Distilled 12.04.x, 14.04.x, and 16.04.x Ubuntu Kernel Support diagrams)
LTS Kernel Support Schedule
A more detailed view of our LTS Kernel Support Schedule. This includes views for 12.04.x, 14.04.x, 16.04.x as well as upstream stable commitments.
For more information, please refer to https://wiki.ubuntu.com/Kernel/LTSEnablementStack
Where can we find your Mailing List?
As with the majority of teams our major decisions are discussed and recorded on the Ubuntu Kernel Team mailing list. Join our mailing list at https://lists.ubuntu.com/mailman/listinfo/kernel-team. You can read an archive of messages at https://lists.ubuntu.com/archives/kernel-team
My bug is Fix Committed but the fix is not in the kernel?
Once a fix has been reviewed and approved on the Kernel Team email list it will then be applied to the kernel git tree. When sufficient updates have accumulated a -proposed kernel will be uploaded; you need the proposed pocket enabled to get these kernels. It can take some time before these changes are uploaded, however every day the tree is checked and if there are any new patches a new pre-proposed kernel is automatically uploaded to the kernel team pre-proposed PPA ppa:~kernel-ppa/pre-proposed. Adding both the proposed pocket and the pre-proposed PPA will get you all pending fixes as soon as possible. See Kernel/Dev/KernelTesting for details.
How do you manage and track incoming patches?
Patches are submitted to the Ubuntu kernels via the kernel-team mailing list. We use this list as the primary record of the discussions, acceptance, or rejection, of each patch (see Kernel/FAQ/GeneralMailingList). We use the patchworks patch tracking system to aid in this process http://patchwork.ozlabs.org/project/ubuntu-kernel/list/. See Kernel/Handbook/Patchworks for documentation on how we use patchworks within the team.
Which kernels does the Kernel Team support?
The Kernel Team provides support (security updates etc) for the Ubuntu kernels on all currently active releases, we do not support any non-Ubuntu kernels. A full list of the currently active releases can be found on the Releases page. For Long Term Support (LTS) releases the desktop kernels drop from support before the server kernels, this is reflected in the Releases page.
What differentiates the Ubuntu Kernel from the upstream Linux Kernel?
Ubuntu kernels are rebased against stable releases only through the development cycle, with many patches on top of the stable tag. Once the final release is made the master branch is never rebased again. While stable updates (post release) are usually applied, we sometimes make patch decisions that are counter to the stable releases.
So, the best one could say is that Ubuntu kernels are only loosely based on upstream stable. You'd have to examine the changelog to know exactly what goes into a particular kernel.
With every Ubuntu kernel release, we attempt to remain as true to the upstream Linux kernel as possible. However, there are inevitable patches which we carry on top of the upstream Linux kernel which differentiates the Ubuntu kernel from the upstream Linux kernel. This document attempts to describe the general set of patches which are carried and why: Kernel/FAQ/UbuntuDelta
What does a specific Ubuntu kernel version number mean?
The official version of an Ubuntu kernel tells you a number of things, including the base upstream version, the current Ubuntu ABI identifier and the kernel flavour. (See How can we determine the version of the running kernel? to find your current version number.)
Given a version like 2.6.35-6.9-generic this can be broken into four parts as below:
<base kernel version>-<ABI number>.<upload number>-<flavour>
The base kernel version represents the mainline version on which the Ubuntu kernel is based. The ABI number represents significant changes in the kernel Application Binary Interface. The upload number is a monotonically increasing counter for each upload of this base version. The flavour indicates which kernel configuration variant this is (See What is a Kernel Flavour?).
How can we determine the version of the running kernel?
The official version of an Ubuntu kernel is found in the /proc/version_signature file. This file contains both the full Ubuntu version of the kernel and the mainline version on which it is based. The first field is always Ubuntu, the second field is the Ubuntu kernel version, and the final field is the upstream version:
$ cat /proc/version_signature Ubuntu 2.6.35-6.9-generic 2.6.35-rc3 $
Given an Ubuntu kernel package version how do we find the exact mainline release it is based on?
The exact upstream mainline tag from which the Ubuntu kernels were forked can be found in the mainline kernel mapping table.
Given an Ubuntu kernel package version how do we find the release it is from?
The kernel package version is of the following form 2.6.35-6.9. The numbers before the - represent the base upstream version from which this kernel was forked, the first number following the - represents the ABI number, the final number is an upload number. Taking the package version first remove the upload number, then round the ABI number down to the nearest hundred (which can include 0), for example:
2.6.35-6.9 => 2.6.35-6 => 2.6.35-0
Look up the final version in the Kernel/Dev/TopicBranches mapping tables (see Current Branches). Once you have the release and branch you can obtain the source.
Where can I find out what the Kernel Team is doing?
The Kernel Team has a weekly status meeting to report on progress and to discuss issues. These meetings are held on #ubuntu-meeting on FreeNODE every Tuesday at 1700 UTC. Meeting agendas and previous meeting minutes can be found at KernelTeam/Meeting. There is also an accumulated live status for the current development release tasks, see Kernel/Release.
Why did a bot come along and mark a bug "Won't Fix"?
The reason the bug was marked as "Won't Fix" is because it was filed against an Ubuntu series that is no longer supported. Which series a bug was filed against is determined by a number of methods based on the data the original bug submitter provided.
The linux project within Ubuntu has over 6500 open bugs filed against it. There is a constant stream of new bugs coming in every day. There is no way the 8 person kernel team can stay on top of all those bugs. Therefor we employ a number of scripts to help with some of the trivial management of the bugs.
The purpose of marking bugs as "Won't Fix" is to indicate to those that care, that the bug will not be looked at any longer. It also tells them that if the bug does still exist on a supported series, they should just open a new bug.
We don't claim that the script is perfect and won't impact some bugs that it shouldn't. The kernel team will continue to refine its scripts as time goes on.
Kernel Tweeking/Configuration Questions
How do I add a Kernel Boot Parameter?
Easy instructions for temporarily or permanently adding a kernel boot parameter to your Ubuntu system can be found in this KernelBootParameters guide.
I heard the Kernel Team were asking for testing, where can I find details?
The currently open Calls for Testing are listed on the Kernel/Testing page. All open and closed calls should be listed there. We are obviously most interested in testing on the open calls.
I have problems with my system how can I diagnose the issue?
There are a number of specific diagnosis guides for kernel related issues in the Kernel/Debugging guide. You should likely file a bug against the linux package in LaunchPad if you do no already have one. File a bug using the command below:
Do we have upstream kernels for Ubuntu?
The kernel team does build upstream kernels for debugging use. These are built automatically as the upstream kernels release and published in the KernelTeam/MainlineBuilds archive.
Why do mainline kernel builds have a -<series> suffix?
Each mainline build is named by the base upstream version suffixed with an Ubuntu release name, 2.6.35-maverick. This tells us the upstream version which was built, and additionally which configuration was used to build it. This tells us which release is most compatible with the kernel as built. This does not prevent the kernel being used on other releases, though it is most likely to work correctly on the release it is build for, or earlier ones. The further away from your base kernel release you are the more likely that there will be an incompatible userspace interaction which will prevent them working for you.
Do mainline kernel builds include Ubuntu specific drivers?
By definition the mainline kernel builds are made from virgin unaltered mainline kernel sources and therefore do not, and should not, include any Ubuntu patches or drivers. There are also no binary drivers for these kernels.
What is Bug Triage?
Bug Triage is the process of vetting incoming bugs to ensure they have all the information they need to be worked on. See Kernel/BugTriage/Process for details on the process itself, see Kernel/BugTriage for pointers on triaging.
What is meant by Triage Levels?
We refer to the increasingly detailed and technical reviews of incoming bugs as Triage Levels, currently there are three triage levels. More details can be found at Kernel/TriageLevels.
Where can I find Triager resources and documentation?
We maintain a wiki of triager resources to share across the team and the community in the kernel team wiki in the Triage section, Kernel/BugTriage.
When I try to build the kernel I get an error telling me to run "make mrproper" what should I do?
This implies there are left over files in your tree which are not meant to be in a clean tree. A clean source tree is required for an out of tree (make O=<directory> style) build, which is what the Ubuntu packaging uses. The most common cause is the creation of the include/config directory. You can try removing this:
If that does not work it is normally safest to clean all extraneous file out of your tree as below. Note that this removes each and every file which is not committed to git, it will remove any patches etc you have lying around within the build directory:
git clean -x -f -d
Where can I find Development resources and documentation?
We maintain a wiki of development resources to share across the team and the community in the kernel team wiki in the development section, Kernel/Dev.
What is a Kernel Flavour?
It is impossible to build a single kernel for every occasion, any such configuration cannot be optimal for all use cases. As a result we offer a number of kernel variants for each release, these variants termed flavours. We commonly refer to those flavours using the flavour name, for example: generic, generic-pae, and server.
How do we choose which Flavours are supported in a release?
At the Ubuntu Developer Summit (UDS) we will discuss the current flavours and their applicability. During this discussions we will make recommendations for additions to or removals from the supported flavours. Those recommendations feed into the development for that upcoming release.
What are Kernel Flavour transitions?
Over time the supported kernel flavours have evolved. This means that sometimes it is necessary to move from one kernel flavour to another for a specific use case. More details on why we might need such transitions, and information on the transitions which have been needed previously can be found on the Kernel/Dev/Flavours page.
What Kernel Flavours exist for each release?
The flavours available for all supported releases are documented on the Kernel/Dev/Flavours page. This includes information on where support is obtained for these flavours.
Can I get a patch included in the Ubuntu Kernel? / How can I submit a patch to the Ubuntu Kernel?
Normally we consider patches for inclusion which are sent to the firstname.lastname@example.org email list. See Kernel/Dev/KernelPatches for more details.
Why does a local build produce such enormous packages?
Our build includes CONFIG_DEBUG_INFO in order to produce linux-debug-image packages. We then manually strip the modules after build.
If you re-use our config for your own build, your best bet is to change this line in the config:
# CONFIG_DEBUG_INFO is not set
Where can I find Kernel related bugs to work on?
The Kernel bugs are maintained in LaunchPad, the full list is at https://bugs.launchpad.net/ubuntu/+source/linux/+bugs
Where can I find the Ubuntu Kernel source code?
You can access all the kernels for previous and current development releases at http://kernel.ubuntu.com/git. There are repositories for each supported release under ubuntu/ubuntu-<release>.git. We use git to maintain all our trees. See Kernel/SourceCode for more details.
What are the supported Kernel Meta Packages?
The Ubuntu kernel meta packages facilitate the use of the different supported kernel flavors. These meta packages group a set of existing kernel related packages into a single set. Information documenting the set of supported kernel meta packages can be obtained at Kernel/Dev/Meta-Pkgs.
What are these topic branches in the Ubuntu Kernel?
Normally all of the source code for the Ubuntu Kernels are stored on the master branch of the Ubuntu git repository for a release. However where there are significantly different kernels for different systems, for example it may be at an older mainline level, or may contain very invasive changes, those cannot be merged safely into the master branch. In this case the source code is maintained on a topic branch (see Kernel/Dev/TopicBranches). We use a split debian system to allow these to cleanly coexist in the same repository (see KernelTeam/AbstractedDebian)
How do I use git with the Ubuntu kernel?
git is a fairly complex program to use and you are recommended to read up on and understand git's philosophy before attempting to work with the Ubuntu kernel trees, we recommend at least reading the Git Community Book. Once you are conversant with git you should read the KernelTeam/KernelGitGuide which describes how to find our respositories and how we use them. You may also find the KernelTeam/GitCheatSheet useful.
There are also 2 books that we know of:
- Pragmatic Version Control Using Git by Travis Swicegood
- Version Control with Git by Jon Loeliger
Why is feature X not enabled in the Ubuntu Kernel?
Often features have never been requested before and therefore not enabled, in other cases they may be incompatible with other features and cannot be enabled. Contact the Kernel Team (See How do I find the kernel team?) and ask.
Why is patch X not applied to Release Y?
It is not always possible to backport a fix to an older release. The key requirement for any changes applied to older releases is that they not introduce any regressions for other users. The fix may help your case but cause issues on other systems. This introduces risk in releasing fixes in older releases and may sometimes prevent us fixing your problem. Often we will only be able to fix these types of issues in the next release. This is outside the kernel team's control, see the StableReleaseUpdates and KernelTeam/KernelUpdates pages for details.
I have uploaded a new Ubuntu kernel, who needs to know about it?
A number of groups are affected by new Kernel uploads we therefore send out an announcement email to a number of groups for each upload. We announce each Kernel upload to the people indicated in the Announce kernel uploads section of the KernelTeam/KernelMaintenance guide.