QUESTION: 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.
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:
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.
However this just says which kernels are supported, not which ones are considered compatible.
QUESTION: Example case, practically: How likely will I be in trouble when running Lucid's kernel on Precise?
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).
QUESTION: 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?
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.
QUESTION: How does Desktop/Server edition differ in this?
They do not differ in any way. This is partially proven by the fact that both Desktop and Server edition use the same kernel.
QUESTION: Is Ubuntu simply not bothering about these cases or am I missing a resource on this?
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.
Remove the manually copied biokernbase.ko from /lib/modules/3.13.0-123-generic/kernel/drivers/misc/
.
Edit dkms.conf
like this... (keep the original as a .bak file)...
PACKAGE_NAME="biokernbase"
PACKAGE_VERSION="3.1.2.1"
CLEAN="make clean"
MAKE[0]="'make' all KVER=${kernelver}"
BUILT_MODULE_NAME[0]="biokernbase"
DEST_MODULE_LOCATION[0]="/updates/dkms"
AUTOINSTALL="yes"
Perform a sudo dkms build
again and see if this fixes the problem.
Best Answer
Unpack the *.deb file containing the modification to see in what form the module is distributed. Also have a look at the content of the other package and see what files are shipped there. If some files are precompiled modules for a specific kernel version (*.ko files), then those modules will almost certainly fail to cooperate with a more recent kernel, and updating Ubuntu without updating the kernel is asking for trouble as well.
If, on the other hand, the kernel modules are distributed in a source format (*.c), perhaps containing some binary blob, then the deb package will likely use dkms or similar to have modules compiled for the current kernel, and the shell script might do some compilation for the current kernel as well. In those cases, you should see whether the modules do compile against the sources of a current Ubuntu kernel. You should be able to compile them on a test system, not using the target hardware just yet.
If they do compile successfully, chances are good that they will run as intended, although there are of course no guarantees. If they fail to compile, you can see whether you can locate a kernel version recent enough to support an upgrade but still old enough to be compatible with those modules. Or you could adjust the module sources to take kernel API changes into account.