Latest stable linux kernel

Ubuntu kernels from Canonical

At the core of the Ubuntu operating system is the Linux kernel, which manages and controls the hardware resources like I/O (networking, storage, graphics and various user interface devices, etc.), memory and CPU for your device or computer. It is one of the first software programs a booting device loads and runs on the central processing unit (CPU). The Linux kernel manages the system’s hardware environment so other programs like the operating system’s user space programs and application software programs can run well without modification on a variety of different platforms and without needing to know very much about that underlying system.

Identifying a kernel

The easiest way to determine the kernel you’re running is to type cat /proc/version_signature on the terminal. For example:

Ubuntu 5.4.0-12.15-generic 5.4.8

This output provides important information about the kernel:

• Canonical adds » Ubuntu «
• Ubuntu kernel-release = 5.4.0-12.15-generic
  • kernel version is 5.4 , which is identical to upstream stable kernel version
  • .0 is an obsolete parameter left over from older upstream kernel version naming practices
  • -12 application binary interface (ABI) bump for this kernel
  • .15 upload number for this kernel
  • -generic is kernel flavour parameter, where -generic is the default Ubuntu kernel flavour
• Mainline kernel-version = 5.4.8

Kernel and OS releases

Canonical provides long-term support (LTS) kernels for Ubuntu LTS releases. Canonical also provides interim operating system releases with updated kernels every 6 months.

For customers and business partners that don’t have specialised bleeding-edge workloads or latest hardware needs, the latest LTS release «-generic» kernel is the best option for them such as the 4.15 default kernel in Ubuntu 18.04 LTS. Customers who need the latest hardware support capability can install the latest HWE kernel such as the ones contained in interim releases, keeping in mind the shorter support lifespan associated with these kernels (9 months). HWE kernel customers are recommended to upgrade to a newer LTS release that supports their hardware and/or software needs as soon as it is available. Another option for customers is to use point releases. For example, there is an 18.04.4 point release as of February 2020, which includes an updated 5.3.x kernel but is also considered LTS, exactly like the original GA 4.15 kernel in 18.04.

Kernel security

The Canonical Kernel Team’s primary focus is the careful maintenance of kernels and their variants for regular delivery via the Ubuntu SRU process and the Canonical livepatch service. This includes rigorous management of all Linux kernel Common Vulnerabilities and Exposures (CVE) lists (with a focus on patching all high and critical CVEs) review and application of all relevant patches for all critical and serious kernel defects in the mailing lists and then rigorously testing newly updated kernels end-to-end each SRU cycle.

General Availability (GA) and variant Ubuntu kernels

The complete functionality of any given kernel is determined by the included modules and the kernel configuration for both hardware and the expected workloads that are run on it.

Kernel modules are binary programs that extend a kernel’s ability to control the computing system’s hardware or add additional system capabilities like high-performance networking or non-standard graphics, etc. The GA kernel that is shipped by default, with the Canonical Ubuntu Long Term Support (LTS) and Hardware Enablement (HWE) releases, are tuned for stable, reliable, secure, high-performance operation over a wide variety of hardware platforms and workloads.

A kernel variant is a kernel that deviates from the generic GA kernel by changes to its configuration, and/or by having modules added and/or removed.

Custom kernels

Canonical advocates for customers to use the GA kernel shipped with Ubuntu as the best and most cost-effective option in their business environment. We also offer the option for customers to customize their own Ubuntu kernels. Several of our enterprise, Telco and cloud provider customers have systems and workload needs, which justify both the time investment to optimise their kernels and the pay to develop and maintain those custom kernels over time.

© 2021 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.

Источник

The Linux Kernel Archives

There are several main categories into which kernel releases may fall:

Prepatch Prepatch or «RC» kernels are mainline kernel pre-releases that are mostly aimed at other kernel developers and Linux enthusiasts. They must be compiled from source and usually contain new features that must be tested before they can be put into a stable release. Prepatch kernels are maintained and released by Linus Torvalds. Mainline Mainline tree is maintained by Linus Torvalds. It’s the tree where all new features are introduced and where all the exciting new development happens. New mainline kernels are released every 2-3 months. Stable After each mainline kernel is released, it is considered «stable.» Any bug fixes for a stable kernel are backported from the mainline tree and applied by a designated stable kernel maintainer. There are usually only a few bugfix kernel releases until next mainline kernel becomes available — unless it is designated a «longterm maintenance kernel.» Stable kernel updates are released on as-needed basis, usually once a week. Longterm There are usually several «longterm maintenance» kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don’t usually see very frequent releases, especially for older trees.

Longterm release kernels

Version	Maintainer	Released	Projected EOL
5.10	Greg Kroah-Hartman & Sasha Levin	2020-12-13	Dec, 2026
5.4	Greg Kroah-Hartman & Sasha Levin	2019-11-24	Dec, 2025
4.19	Greg Kroah-Hartman & Sasha Levin	2018-10-22	Dec, 2024
4.14	Greg Kroah-Hartman & Sasha Levin	2017-11-12	Jan, 2024
4.9	Greg Kroah-Hartman & Sasha Levin	2016-12-11	Jan, 2023
4.4	Greg Kroah-Hartman & Sasha Levin	2016-01-10	Feb, 2022

Distribution kernels

Many Linux distributions provide their own «longterm maintenance» kernels that may or may not be based on those maintained by kernel developers. These kernel releases are not hosted at kernel.org and kernel developers can provide no support for them.

It is easy to tell if you are running a distribution kernel. Unless you downloaded, compiled and installed your own version of kernel from kernel.org, you are running a distribution kernel. To find out the version of your kernel, run uname -r :

If you see anything at all after the dash, you are running a distribution kernel. Please use the support channels offered by your distribution vendor to obtain kernel support.

Источник

Everything you ever wanted to know about Linux -stable releases¶

Rules on what kind of patches are accepted, and which ones are not, into the “-stable” tree:

It must be obviously correct and tested.

It cannot be bigger than 100 lines, with context.

It must fix only one thing.

It must fix a real bug that bothers people (not a, “This could be a problem…” type thing).

It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some “oh, that’s not good” issue. In short, something critical.

Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.

New device IDs and quirks are also accepted.

No “theoretical race condition” issues, unless an explanation of how the race can be exploited is also provided.

It cannot contain any “trivial” fixes in it (spelling changes, whitespace cleanups, etc).

It or an equivalent fix must already exist in Linus’ tree (upstream).

Procedure for submitting patches to the -stable tree¶

For all other submissions, choose one of the following procedures¶

Option 1В¶

To have the patch automatically included in the stable tree, add the tag

in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer.

Option 2В¶

After the patch has been merged to Linus’ tree, send an email to stable @ vger . kernel . org containing the subject of the patch, the commit ID, why you think it should be applied, and what kernel version you wish it to be applied to.

Option 3В¶

Send the patch, after verifying that it follows the above rules, to stable @ vger . kernel . org. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish it to be applied to.

Option 1 is strongly preferred, is the easiest and most common. Option 2 and Option 3 are more useful if the patch isn’t deemed worthy at the time it is applied to a public git tree (for instance, because it deserves more regression testing first). Option 3 is especially useful if the patch needs some special handling to apply to an older kernel (e.g., if API’s have changed in the meantime).

Note that for Option 3 , if the patch deviates from the original upstream patch (for example because it had to be backported) this must be very clearly documented and justified in the patch description.

The upstream commit ID must be specified with a separate line above the commit text, like this:

Additionally, some patches submitted via Option 1 may have additional patch prerequisites which can be cherry-picked. This can be specified in the following format in the sign-off area:

The tag sequence has the meaning of:

Also, some patches may have kernel version prerequisites. This can be specified in the following format in the sign-off area:

The tag has the meaning of:

For each “-stable” tree starting with the specified version.

Following the submission:

The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer’s schedules.

If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer.

Review cycle¶

When the -stable maintainers decide for a review cycle, the patches will be sent to the review committee, and the maintainer of the affected area of the patch (unless the submitter is the maintainer of the area) and CC: to the linux-kernel mailing list.

The review committee has 48 hours in which to ACK or NAK the patch.

If the patch is rejected by a member of the committee, or linux-kernel members object to the patch, bringing up issues that the maintainers and members did not realize, the patch will be dropped from the queue.

At the end of the review cycle, the ACKed patches will be added to the latest -stable release, and a new -stable release will happen.

Security patches will be accepted into the -stable tree directly from the security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure.

Trees¶

The queues of patches, for both completed versions and in progress versions can be found at:

The finalized and tagged releases of all stable kernels can be found in separate branches per version at:

Review committee¶

This is made up of a number of kernel developers who have volunteered for this task, and a few that haven’t.

© Copyright The kernel development community.

Источник

The Linux Kernel Archives

If you have questions, comments or concerns about the F.A.Q. please contact us at webmaster@kernel.org.

Is Linux Kernel Free Software?

Linux kernel is released under GNU GPL version 2 and is therefore Free Software as defined by the Free Software Foundation. You may read the entire copy of the license in the COPYING file distributed with each release of the Linux kernel.

What does «stable/EOL» and «longterm» mean?

As kernels move from the «mainline» into the «stable» category, two things can happen:

1. They can reach «End of Life» after a few bugfix revisions, which means that kernel maintainers will release no more bugfixes for this kernel version, or
2. They can be put into «longterm» maintenance, which means that maintainers will provide bugfixes for this kernel revision for a much longer period of time.

If the kernel version you are using is marked «EOL,» you should consider upgrading to the next major version as there will be no more bugfixes provided for the kernel version you are using.

Please check the Releases page for more info.

Why is an LTS kernel marked as «stable» on the front page?

Long-term support («LTS») kernels announced on the Releases page will be marked as «stable» on the front page if there are no other current stable kernel releases. This is done to avoid breaking automated parsers monitoring kernel.org with an expectation that there will always be a kernel release marked as «stable.»

Linus has tagged a new release, but it’s not listed on the front page!

Linus Torvalds PGP-signs git repository tags for all new mainline kernel releases, however a separate set of PGP signatures needs to be generated by the stable release team in order to create downloadable tarballs. Due to timezone differences between Linus and the members of the stable team, there is usually a delay of several hours between when the new mainline release is tagged and when PGP-signed tarballs become available. The front page is updated once that process is completed.

Is there an RSS feed for the latest kernel version?

We also publish a .json file with the latest release information, which you can pull from here: https://www.kernel.org/releases.json.

Why are there files that are dated tomorrow?

All timestamps on kernel.org are in UTC (Coordinated Universal Time). If you live in the western hemisphere your local time lags behind UTC. Under Linux/Unix, type date -u to get the current time in UTC.

Can I get an account on kernel.org?

Kernel.org accounts are usually reserved for subsystem maintainers or high-profile developers. It is absolutely not necessary to have an account on kernel.org to contribute to the development of the Linux kernel, unless you submit pull requests directly to Linus.

If you are listed in the MAINTAINERS file or have reasons to believe you should have an account on kernel.org because of the amount of your contributions, please refer to the accounts wiki page for the procedure to follow.

I have cool project X, can you guys mirror it for me?

Probably not. Kernel.org deals with the Linux kernel, various distributions of the kernel and larger repositories of packages. We do not mirror individual projects, software, etc as we feel there are better places providing mirrors for those kinds of repositories. If you feel that kernel.org should mirror your project, please contact ftpadmin@kernel.org with the following information:

• name
• project name
• project website
• detailed project description
• reason for wanting us to mirror

The Kernel.org admin team will then review your request and talk to you about it. As with any kind of account on kernel.org it’s up to the discretion of the admin team.

How does kernel.org provide its users access to the git trees?

We are using an access control system called gitolite, originally written and maintained by Sitaram Chamarty. We chose gitolite for a number of reasons:

• Limiting of ssh access to the system
• Fine grained control over repository access
• Well maintained and supported code base
• Responsive development
• Broad and diverse install base

As well at the time of deployment the code had undergone an external code review.

How do I create an -rc kernel? I get «Reversed patch detected!»

-rc kernel patches are generated from the base stable release.

For example: to create the 2.6.14-rc5 kernel, you must:

• download 2.6.13 (not 2.6.13.4)
• and then apply the 2.6.14-rc5 patch.

Yes, you want 2.6.13, not 2.6.14. Remember, that’s an -rc kernel, as in, 2.6.14 doesn’t exist yet. 🙂

Where can I find kernel 2.4.20-3.16?

Kernel version numbers of this form are distribution kernels, meaning they are modified kernels produced by distributions. Please contact the relevant distributor; or check out https://mirrors.kernel.org/.

See the Releases page for more info on distribution kernels.

I need help building/patching/fixing Linux kernel/modules/drivers!

Please see the Kernel Newbies website.

There is also a wealth of knowledge on many topics involving Linux at The Linux Documentation Project (http://www.tldp.org)

For finding or reporting bugs, look through the archives for the various Linux mailing lists, and if no specific list seems appropriate, try the browsing the Linux Kernel Mailing List.

What happened to ftp.kernel.org?

FTP service was terminated on March 1, 2017. All content that used to be available via ftp.kernel.org can be accessed by browsing https://www.kernel.org/pub/. If you would like to use a command-line tool for accessing these files, you can do so with lftp:

When will the next kernel be released?

The next kernel will be released when it is ready. There is no strict timeline for making releases, but if you really need an educated guess, visit the Linux kernel PHB Crystal Ball — it tries to provide a ballpark guess based on previous kernel release schedule.

What will go into the next release?

It is hard to predict with certainty, but you can either take a peek at linux-next or read the Linux Weather Forecast, where Jonathan Corbet provides a broad forecast of what will likely be included into the next mainline release.

Other resources

Social

This site is operated by the Linux Kernel Organization, Inc., a 501(c)3 nonprofit corporation, with support from the following sponsors.

Источник