MainlineBuilds

Differences between revisions 35 and 37 (spanning 2 versions)
Revision 35 as of 2014-11-06 15:15:41
Size: 6497
Editor: penalvch
Comment: 1) Testing -> using 2) Clarified when to use lowlatency.
Revision 37 as of 2014-11-28 05:33:12
Size: 6614
Editor: penalvch
Comment: Due to LP#1392460 and many others, recast article to advise first to remove proprietary & out-of-tree modules before attempting to install mainline.
Deletions are marked like this. Additions are marked like this.
Line 28: Line 28:
= Preparing to install an upstream kernel =

First, if one is using select proprietary or out-of-tree modules (ex. vitualbox, nvidia, fglrx, bcmwl, etc.) unless there is an '''extra''' package available for the version you are testing, you will need to uninstall the module first, in order to test the mainline kernel. If you do not uninstall these modules first, then the upstream kernel more than likely will not boot.
Line 30: Line 34:
To boot into an upstream kernel you only need to download and install the *image*.deb package that corresponds to your architecture. In addition, if you need to build any external modules you also need the correspinding headers-<kernelname>_<architecture>.deb and headers-<kernelname>_all.deb packages. To boot into an upstream kernel you need to download and install the packages that corresponds to your architecture.
Line 57: Line 61:
== Problems installing an upstream kernel == The headers-<kernelname>_<architecture>.deb and headers-<kernelname>_all.deb packages allow one to build external modules.

= Problems installing the upstream kernel =
Line 62: Line 68:
}}} This would be due to a conflict with the installed software (VirtualBox, nvidia proprietary drivers, fglrx, wl, etc.). If possible, one would want to uninstall the conflicting package(s) first, then install the upstream kernel. This will allow you to test the upstream kernel, and provide another data point on if the removed software has a relationship to your problem. }}} This is do to how one did not follow the previous directions of uninstalling out-of-tree modules, in this case virtualbox.

Introduction

By default, Ubuntu systems run with the Ubuntu kernels provided by the Ubuntu repositories. However it is handy to be able to test with unmodified upstream kernels to help locate problems in the Ubuntu kernel patches, or to confirm that upstream has fixed the issue. To this end we now offer select upstream kernel builds. These kernels are made from unmodified kernel source but using the Ubuntu kernel configuration files. These are then packaged as Ubuntu .deb files for simple installation.

We currently build five sets of upstream kernels. All formal tags from Linus' tree and from the stable trees, plus:

  1. the daily tip of Linus' linux kernel source tree,

  2. the tip of the drm-next head of Dave Airlie's linux repository daily,

  3. the tip of the drm-intel-next head of Keith Packard's linux repository daily,

  4. the tip of the master branch of the debloat-testing tree daily,
  5. tags from the combined v2.6.32.x.y tree (by StefanBader) which is v2.6.32.x with DRM from 2.6.33.y.

This makes these kernels closer to the Lucid kernels which are based on 2.6.32 kernels with DRM backported from the 2.6.33 series.

Upstream kernels archive

The upstream kernels archive is located at the URL below. There is a directory for each build. Note, if you are testing for a bug, please do not use the daily folder, but use the latest mainline kernel at the top:

The tagged releases are found under a directory matching their tag name and which kernel configuration they were built with (<tag>-<series>). Daily releases are found in the daily sub-directory named for the date they were made.

Each build directory contains the header and image .deb files for the generic flavour i386 and amd64 architectures.

Preparing to install an upstream kernel

First, if one is using select proprietary or out-of-tree modules (ex. vitualbox, nvidia, fglrx, bcmwl, etc.) unless there is an extra package available for the version you are testing, you will need to uninstall the module first, in order to test the mainline kernel. If you do not uninstall these modules first, then the upstream kernel more than likely will not boot.

Installing upstream kernels

To boot into an upstream kernel you need to download and install the packages that corresponds to your architecture.

For example, let us use http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14.4-utopic/.
If you are using a 32-bit/i386 architecture, you would want those marked A.
If you are using a 64-bit/amd64 architecture, B.
(Use generic kernel unless the issue is only reproducible in a lowlatency kernel).

B  linux-headers-3.14.4-031404-generic_3.14.4-031404.201405130853_amd64.deb
A  linux-headers-3.14.4-031404-generic_3.14.4-031404.201405130853_i386.deb
   linux-headers-3.14.4-031404-lowlatency_3.14.4-031404.201405130853_amd64.deb
   linux-headers-3.14.4-031404-lowlatency_3.14.4-031404.201405130853_i386.deb
AB linux-headers-3.14.4-031404_3.14.4-031404.201405130853_all.deb
B  linux-image-3.14.4-031404-generic_3.14.4-031404.201405130853_amd64.deb
A  linux-image-3.14.4-031404-generic_3.14.4-031404.201405130853_i386.deb
   linux-image-3.14.4-031404-lowlatency_3.14.4-031404.201405130853_amd64.deb
   linux-image-3.14.4-031404-lowlatency_3.14.4-031404.201405130853_i386.deb

It is best to downloaded the files into a folder by themselves. Then, one may install all the packages simultaneously by executing the following in a terminal:

sudo dpkg -i *.deb

When this process completes you should have a new entry on your boot menu representing the upstream kernel. This will appear as an entry like this:

Ubuntu Trusty, kernel 3.14.4-031404-generic

The headers-<kernelname>_<architecture>.deb and headers-<kernelname>_all.deb packages allow one to build external modules.

Problems installing the upstream kernel

Warning /!\ Some have found issues installing an upstream kernel due to an error. For example:

Error! Bad return status for module build on kernel: 3.7.0-030700rc2-generic (x86_64)
Consult /var/lib/dkms/virtualbox/4.1.18/build/make.log for more information.

This is do to how one did not follow the previous directions of uninstalling out-of-tree modules, in this case virtualbox.

Uninstalling upstream kernels

The upstream kernels have their own ABI namespace so they install side by side with the stock Ubuntu kernels (each kernel has a separate directory under /lib/modules/VERSION for example). This means that you can keep several mainline and Ubuntu stock kernels installed at the same time and select the one you need from the GRUB boot menu.

If you would like to uninstall an upstream kernel anyway, first use:

dpkg -l | grep "linux\-[a-z]*\-"

to find the exact name of the kernel packages you want to uninstall, and then do:

sudo apt-get remove KERNEL_PACKAGES_TO_REMOVE

Remember that several packages can belong to one kernel version: common headers, architecture specific headers and the architecture specific image.

Mainline build tool chain

These kernels are built with the tool chain (gcc etc.) from the previous LTS (Ubuntu 8.04/10.04/12.04) depending on version. Therefore, out-of-tree kernel modules built with tools from other versions likely will not work. The file BUILD in later mainline builds detailing what was used.

Mainline kernel mapping to Ubuntu kernel

The Ubuntu kernel is not bit-for-bit the same as the mainline. However, one may find the upstream release that the Ubuntu kernel is based on via the Ubuntu to mainline mapping table.

Does the kernel team support the mainline kernel builds?

The mainline kernels builds are produced for debugging purposes and therefore come with no support. Use them at your own risk.

Kernel/MainlineBuilds (last edited 2023-11-10 10:07:24 by juergh)