|Deletions are marked like this.||Additions are marked like this.|
|Line 6:||Line 6:|
|Welcome to the [[Kernel]] 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.||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.|
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.
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
The latest information on the Ubuntu Lifecycle and Release Cadence.
The Ubuntu LTS enablement (also called HWE or Hardware Enablement) stacks provide newer kernel and X support for existing Ubuntu LTS releases. These enablement stacks can be installed manually but are also available when installing with Ubuntu LTS point release media. These newer enablement stacks are meant for desktop and server and even recommended for cloud or virtual images.
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, starting with Ubuntu 12.04, the desktop kernels and server kernels both receive five years support, 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.
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.