Why older kernel?
For whatever reason out there, you might be forced to run another kernel than the ones provided by Ubuntu. It may even take you back a few years for a kernel that is compatible with specific precompiled kernel modules, your Xen/container-based VPS provider may force you to use his kernel, etc.
I have this question for a long time, but this sparked it again today.
In such a case it would be very useful to be able to say whether you can blame the kernel for issues or whether you should even bother to try to set up a more recent version of Ubuntu in your situation.
Policy, documentation?
I'm particularly interested in what the objectives of the developers/QA are in this regarding LTS releases and newer stable running the LTS-kernel. Some closely related questions:
- What is the policy on compatibility with earlier kernel versions? E.g. no bug reports accepted, must work with all kernel versions back to and including previous LTS, etc.
- Example case, practically: How likely will I be in trouble when running Lucid's kernel on Precise?
- To what extent is software relatively close to the kernel (udev, gvfs, mdadm etc.) being tested on other than the version provided with the release?
- How does Desktop/Server edition differ in this?
The most obvious place to look at this would be the Release notes. However, besides updates/changes to the Ubuntu flavoured kernel, this doesn't mention anything about compatibility with other kernels, while kernel-related features are being mentioned in other parts of the notes, e.g.
Software RAID now supports bad block management (MD).
Is Ubuntu simply not bothering about these cases or am I missing a resource on this? Besides the release notes, I have used Google to quite some extent using keywords: Ubuntu 12.04 minimal kernel version required and several variants to it. Yet, no statement about it appears to be made on those results. I now find this question popping up as only relevant resource. I did find this answer, tough, and it looks very promising, yet it's about a specific issue/environment and not really about server/desktop usage.
Userspace vs kernel
I know most pieces of userland software should not bother about kernel versions, but it's getting more complicated for VPN software or applications interacting with hardware, like the one above, but also for example V4L2, Network Manager, Alsa, etc.
Debian vs Ubuntu
Debian is really clear on this. Already for Wheezy, we know that if you rely on udev, it will require 2.6.26 to run properly from it's release notes (in the works):
The udev version in wheezy requires a kernel of version 2.6.26 or newer with [...]
What I'm not asking for
I am very well aware about the backports provided for newer kernels from newer releases to the current LTS version. This question is about the opposite.
Please avoid any discussion like "why would one want to run an older kernel?" - you just don't have a choice sometimes and it's not about what we want, but how one can deal with such a given situation.
I'm a member of the Ubuntu BugControl team and I can say that only bugs in non-obsolete Ubuntu packages are considered. If you install your own kernel or if you use a package from a different distribution and report a bug, your bug will be invalidated. See these two stock responses:
Also, the Ubuntu Kernel team has a FAQ that you might find interesting:
However this just says which kernels are supported, not which ones are considered compatible.
This is a pretty difficult question to answer. Especially because it really depends on what applications/modules you will be using. We can restrict this question to the "standard" Ubuntu Desktop or Server, but even then it would be too difficult to answer: there is not enough documentation and the information available are sparse.
For example, to check whether udev from Quantal is compatible with the Lucid kernel you would have to see the M, N, O, P, Q release notes, kernel changelogs and udev changelogs. And then proceed to an another package, e.g. libc, upstart and so on. All these packages depend on specific kernel versions and all these packages are not controlled directly by Ubuntu (in the sense that it's not the Ubuntu Team that decides the compatibility policies of that packages).
The Ubuntu Testing team and the Ubuntu Quality team do not test kernels not provided by Ubuntu. The proof is that there are no test cases nor test activities for obsolete kernels.
They do not differ in any way. This is partially proven by the fact that both Desktop and Server edition use the same kernel.
Ubuntu is not bothering about these cases. Not supporting a kernel version, but being compatible with it would be just extra work with few benefits.
Whether one may like it or not, one of the Ubuntu practices is to look forward and try to support the most recent technologies, rather than the most outdated. You can find an example of this when the Ubuntu CD has been dropped in favor of the DVD, or when Unity 2d has been removed from Quantal.
Also, and this is the most important point in my opinion, Ubuntu is not interested in distributing software which works, but software which works and is supported. There are important differences between these two terms.
The only officially supported kernel is the one shipped with that Ubuntu release. If you have issues due to using a different kernel, you will be on your own. If an issue is suspected to be related to using a non standard kernel, you will be asked to at least test the standard one to see if it actually is related.
There are too many potential issues that could result from using an older kernel to have any sort of accurate list of what works and what doesn't; you will just have to try for yourself.
Making an educated guess, I don't think older kernels are even considered for any Ubuntu release. ...and why would they be? The 'required kernel' is simply the one a release ships with.
Why would one want to use an older kernel on a new release, rather then the older release itself?
AFAIK, the kernel team looks forward rather then backward. They backport newer kernels from newer releases, for example, Quantal kernels get backported to Precise, but not the other way around.