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 9-10 weeks. 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 6.6 Greg Kroah-Hartman & Sasha Levin 2023-10-29 Dec, 2026 6.1 Greg Kroah-Hartman & Sasha Levin 2022-12-11 Dec, 2026 5.15 Greg Kroah-Hartman & Sasha Levin 2021-10-31 Dec, 2026 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 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: # uname -r 5.6.19-300.fc32.x86_64 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. Releases FAQ Here are some questions we routinely receive about kernel release versions. See also the main "FAQ" section for some other topics. When is the next mainline kernel version going to be released? Linux kernel follows a simple release cadence: after each mainline release, there is a 2-week "merge window" period during which new major features are introduced into the kernel after the merge window closes, there is a 7-week bugfix and stabilization period with weekly "release candidate" snapshots rc7 is usually the last release candidate, though occasionally there may be additional rc8+ releases if that is deemed necessary So, to find the approximate date of the next mainline kernel release, take the date of the previous mainline release and add 9-10 weeks. What is the next longterm release going to be? Longterm kernels are picked based on various factors -- major new features, popular commercial distribution needs, device manufacturer demand, maintainer workload and availability, etc. You can roughly estimate when the new longterm version will become available based on how much time has elapsed since the last longterm version was chosen. Why are some longterm versions supported longer than others? The "projected EOL" dates are not set in stone. Each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time. Does the major version number (4.x vs 5.x) mean anything? No. The major version number is incremented when the number after the dot starts looking "too big." There is literally no other reason. Does the odd-even number still mean anything? A long time ago Linux used a system where odd numbers after the first dot indicated pre-release, development kernels (e.g. 2.1, 2.3, 2.5). This scheme was abandoned after the release of kernel 2.6 and these days pre-release kernels are indicated with "-rc"...
The Linux Kernel Organization is a California Public Benefit Corporation established in 2002 to distribute the Linux kernel and other Open Source software to the public without charge. We are recognized by the IRS as a 501(c)3 private operating foundation. IRS determination letter California determination letter The Linux Kernel Organization is managed by The Linux Foundation, which provides full technical, financial and staffing support for running and maintaining the kernel.org infrastructure. Legal information Due to U.S. Exports Regulations, all cryptographic software on this site is subject to the following legal notice: This site includes publicly available encryption source code which, together with object code resulting from the compiling of publicly available source code, may be exported from the United States under License Exception "TSU" pursuant to 15 C.F.R. Section 740.13(e). This legal notice applies to cryptographic software only. Please see the Bureau of Industry and Security for more information about current U.S. regulations. Our servers are located in Corvallis, Oregon, USA; Palo Alto and San Francisco, California, USA; Portland, Oregon, USA; and Montréal, Québec, Canada. Use in violation of any applicable laws is prohibited. Linux is a Registered Trademark of Linus Torvalds. All trademarks are property of their respective owners...
What is Linux? Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specification compliance. It has all the features you would expect in a modern fully-fledged Unix, including true multitasking, virtual memory, shared libraries, demand loading, shared copy-on-write executables, proper memory management, and multistack networking including IPv4 and IPv6. Although originally developed first for 32-bit x86-based PCs (386 or higher), today Linux also runs on a multitude of other processor architectures, in both 32- and 64-bit variants. New to Linux? If you're new to Linux, you don't want to download the kernel, which is just a component in a working Linux system. Instead, you want what is called a distribution of Linux, which is a complete Linux system. There are numerous distributions available for download on the Internet as well as for purchase from various vendors; some are general-purpose, and some are optimized for specific uses. We currently have mirrors of several distributions available at https://mirrors.kernel.org/. Note, however, that most distributions are very large (several gigabytes), so unless you have a fast Internet link you may want to save yourself some hassle and purchase a CD-ROM with a distribution; such CD-ROMs are available from a number of vendors. Mailing lists The Linux kernel is discussed on the linux-kernel mailing list at vger.kernel.org. Please read the FAQ before subscribing. Although there is no official archive site, unofficial archives of the list can be found at: https://lkml.org/ https://marc.info/?l=linux-kernel...
If you have questions, comments or concerns about the F.A.Q. please contact us at helpdesk@kernel.org. Is Linux Kernel Free Software? Linux kernel is released under the terms of GNU GPL version 2 and is therefore Free Software as defined by the Free Software Foundation. For more information, please consult the documentation: Linux kernel licensing rules I heard that Linux ships with non-free "blobs" Before many devices are able to communicate with the OS, they must first be initialized with the "firmware" provided by the device manufacturer. This firmware is not part of Linux and isn't "executed" by the kernel -- it is merely uploaded to the device during the driver initialization stage. While some firmware images are built from free software, a large subset of it is only available for redistribution in binary-only form. To avoid any licensing confusion, firmware blobs were moved from the main Linux tree into a separate repository called linux-firmware. It is possible to use Linux without any non-free firmware binaries, but usually at the cost of rendering a lot of hardware inoperable. Furthermore, many devices that do not require a firmware blob during driver initialization simply already come with non-free firmware preinstalled on them. If your goal is to run a 100% free-as-in-freedom setup, you will often need to go a lot further than just avoiding loadable binary-only firmware blobs. Can I use the word "Linux" or the Tux logo? Linux is a registered trademark of Linus Torvalds and its use is governed by the Linux Trademark Institute. Please consult the following page for further information: Trademark Usage The Tux penguin logo was created by Larry Ewing using Gimp software. It is free to use, including commercially, as long as you give Larry Ewing proper credit ("if someone asks"). For any other permissions, please reach out to Mr. Larry Ewing directly. What does "stable/EOL" and "longterm" mean? As kernels move from the "mainline" into the "stable" category, two things can happen: 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 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? Yes, and you can find it at https://www.kernel.org/feeds/kdist.xml. We also publish a .json file with the latest release information, which you can pull from here: https://www.kernel.org/releases.json. Where can I find kernel 3.10.0-1160.45.1.foo? Kernel versions that have a dash in them are packaged by distributions and are often extensively modified. Please contact the relevant distribution to obtain the exact kernel source. See the Releases page for more info on distribution kernels. How do I report a problem with the kernel? If you are running a kernel that came with your Linux distribution, then the right place to start is by reporting the problem through your distribution support channels. Here are a few popular choices: Ubuntu Fedora Project Arch Linux Linux Mint Debian GNU/Linux Red Hat OpenSUSE SUSE If you are sure that the problem is with the upstream kernel, please refer to the following document that describes how to report bugs and regressions to the developers: Reporting issues How do I get involved with Linux Kernel development? A good place to start is the Kernel Newbies website. 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 Torvalds. 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 page for the procedure to follow...
Email is the only reliable way of contacting Kernel.org administrators. General contacts helpdesk@kernel.org: All questions about kernel.org infrastructure. Please do not send general Linux questions or bug reports to these addresses. We do not have the resources to reply to them. Please try the following sites for general Linux help: https://superuser.com/ - for computer enthusiasts and power users https://serverfault.com/ - for systems administrators https://askubuntu.com/ - for users of Ubuntu Linux Linux Foundation also offers training opportunities if you are interested in learning more about Linux, want to become a more proficient Linux systems administrator, or want to know more about how Linux can help your company succeed. https://training.linuxfoundation.org/ Mailing address Please send any mail correspondence to the Linux Foundation: The Linux Foundation 1 Letterman Drive Building D, Suite D4700 San Francisco, CA 94129 Phone/Fax: +1 415 723 9709...
We are pleased to announce the availability of a new mailing list service running under the new lists.linux.dev domain. The goal of this deployment is to offer a subscription service that: prioritizes mail delivery to public-inbox archives available via lore.kernel.org conforms to DMARC requirements to ensure subscriber delivery makes minimal changes to email headers and no changes to the message body content for the purposes of preserving patch attestation If you would like to host a Linux development mailing list on this platform, please see further details on the subspace.kernel.org site. Why another mailing list service? Linux development started in 1991 and has been ongoing for the past 30 years at an ever-increasing pace. Many popular code collaboration platforms have risen throughout these three decades -- and while some of them are still around, many others have shut down and disappeared without offering any way to preserve the history of the projects they used to host. Development via mailed-in patches remains the only widely used mechanism for code collaboration that does not rely on centralized infrastructure maintained by any single entity. The Linux developer community sees transparency, independence and decentralization as core guiding principles behind Linux development, so it has deliberately chosen to continue using email for all its past and ongoing collaboration efforts. What about vger.kernel.org? The infrastructure behind lists.linux.dev supports multiple domains, so all mailing lists hosted on vger.kernel.org will be carefully migrated to the same platform while preserving current addresses, subscribers, and list ids. The only thing that will noticeably change is the procedure to subscribe and unsubscribe from individual lists. As majordomo is no longer maintained, we will instead switch to using separate subscribe/unsusbscribe addresses per each list. There are no firm ETAs for this migration, but if you are currently subscribed to any mailing list hosted on vger.kernel.org, you will receive a message when the migration date is approaching...
If you are a developer located around Beijing, or if your connection to Beijing is faster and more reliable than to locations outside of China, then you may benefit from the new git.kernel.org mirror kindly provided by Code Aurora Forum at https://kernel.source.codeaurora.cn/. This is a full mirror that is updated just as frequently as other git.kernel.org nodes (in fact, it is managed by the same team as the rest of kernel.org infrastructure, since CAF is part of Linux Foundation IT projects). To start using the Beijing mirror, simply clone from that location or add a separate remote to your existing checkouts, e.g.: git remote add beijing git://kernel.source.codeaurora.cn/pub/scm/.../linux.git git fetch beijing master You may also use http:// and https:// protocols if that makes it easier behind corporate firewalls...
The Linux kernel community operates a Code of Conduct based on the Contributor Covenant Code of Conduct with a Linux Kernel Contributor Covenant Code of Conduct Interpretation. Code of Conduct Committee The Linux kernel Code of Conduct Committee is currently made up of the following people: Kristen Accardi <kristen.c.accardi@intel.com> Shuah Khan <skhan@linuxfoundation.org> Greg Kroah-Hartman <gregkh@linuxfoundation.org> Joanna Lee <jlee@linuxfoundation.org> Committee members can be reached all at once by writing to <conduct@kernel.org>. Committee Reports We would like to thank the Linux kernel community members who have supported the adoption of the Code of Conduct and who continue to uphold the professional standards of our community. If you have any questions about these reports, please write to <conduct@kernel.org>. March 2024 Archival copy: https://lore.kernel.org/r/355aee5f-13ce-4e20-9ce8-e5bcddd14bc2@linuxfoundation.org In the period of October 1, 2023 through March 31, 2024, the Code of Conduct Committee received the following reports: Unprofessional behavior or comments in email: 2 The result of the investigation: Education and coaching clarifying the role of Code of Conduct conduct on conversations that don't go against the CoC. Education and coaching the individuals on the impact of making unprofessional comments which could be misunderstood leading to negative impressions about the community. The reports were about the offhand comments made while rejecting the code which are not violations of the Code of Conduct Unacceptable behavior or comments on a private invitee only chat channel: 1 Education and coaching clarifying the role of Code of Conduct conduct on conversations that occur on a private chat channel. We would like to thank the Linux kernel community members who have supported the adoption of the Code of Conduct and who continue to uphold the professional standards of our community. If you have questions about this report, please write to <conduct@kernel.org>. September 2023 Archival copy: https://lore.kernel.org/r/3351be6b-854e-479d-832c-83cb8829c010@linuxfoundation.org In the period of April 1, 2023 through September 30, 2023, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 4 The result of the investigation: Education and coaching clarifying the Code of Conduct conduct related to normal review and patch acceptance process: 3 Clarification on the Code of Conduct conduct related to maintainer rights and responsibility to reject code: 1 The reports were about the discussion during the patch review and decisions made in rejecting code and these actions are not viewed as violations of the Code of Conduct. Please see the excerpt from the Responsibilities section in the Linux Kernel Contributor Covenant Code of Conduct Interpretation document: setting expertise expectations, making decisions and rejecting unsuitable contributions are not viewed as a violation of the Code of Conduct. March 2023 Archival copy: https://lore.kernel.org/r/557ef895-ad2d-eff9-7cb8-70dbcf41adea@linuxfoundation.org In the period of October 1, 2022 through March 31, 2023, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 6 The result of the investigation: Education and coaching clarifying the Code of Conduct conduct related to normal review and patch acceptance process: 1 Clarification on the Code of Conduct conduct related to maintainer rights and responsibility to reject code: 5 The reports were about the decisions made in rejecting code and these actions are not viewed as violations of the Code of Conduct. Please see the excerpt from the Responsibilities section in the Linux Kernel Contributor Covenant Code of Conduct Interpretation document: setting expertise expectations, making decisions and rejecting unsuitable contributions are not viewed as a violation of the Code of Conduct. September 2022 Archival copy: https://lore.kernel.org/r/57a492fb-928b-9e0a-5f0e-dc95ef599309@linuxfoundation.org In the period of April 1, 2022 through September 30, 2022, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 1 The result of the investigation: Resolved with a public apology from the violator with a commitment from them to abide by the Code of Conduct in the future. March 2022 Archival copy: https://lore.kernel.org/r/4401af50-083d-0239-6b7f-3454c8d69fec@linuxfoundation.org In the period of October 1, 2021 through March 31, 2022, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 2 The result of the investigation: Education and coaching clarifying the Code of Conduct conduct related to normal review process: 2 September 2021 Archival copy: https://lore.kernel.org/r/e81f0726-5f8f-f10f-d926-a9126941d38e@linuxfoundation.org In the period of May 1, 2021 through September 30, 2021, the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email: 1 The result of the investigation: Education and coaching clarifying the Code of Conduct conduct related to normal review process: 1 April 2021 Archival copy: https://lore.kernel.org/r/448b06e4-41fc-26df-a862-c3ba2f70b6b3@linuxfoundation.org In the period of November 1, 2020 through April 30, 2021 the Code of Conduct Committee received the following reports: Unacceptable behavior or comments in email (3rd party): 4 The result of the investigation: Education and coaching: 1 Public response to call attention to the behavior and request correction with consequence of ban if behavior persists: 1 Public response to attention to the behavior and request correction: 1 Clarification on the Code of Conduct conduct related to maintainer rights and responsibility to reject code: 1 October 2020 Archival copy: https://lore.kernel.org/lkml/20201105083002.GA3429143@kroah.com/ In the period of January 1, 2020 through October 31, 2020 the Committee received the following reports: Unacceptable behavior or comments in email: 1 Unacceptable comments in github repo by non-community members: 1 Unacceptable comments toward a company: 1 The result of the investigation: Education and coaching: 1 Locking of github repo for any comments: 1 Clarification that the Code of Conduct covers conduct related to individual developers only: 1 December 2019 Archival copy: https://lore.kernel.org/lkml/20200103105614.GC1047442@kroah.com/ In the period of December 1, 2019 through December 30, 2019 the Committee received the following report: Insulting behavior in email: 1 The result of the investigation: Education and coaching: 1 August to November 2019 Archival copy: https://lore.kernel.org/lkml/20191218090054.GA5120@kroah.com/ In the period of August 1, 2019 through November 31, 2019, the Committee received no reports. September 2018 to July 2019 Archival copy: https://lore.kernel.org/lkml/20190810120700.GA7360@kroah.com/ In the period of September 15, 2018 through July 31, 2019, the Committee received the following reports: Inappropriate language in the kernel source: 1 Insulting behavior in email: 3 The result of the investigations: Education and coaching: 4...
We are trialing out a new feature that can send you a notification when the patches you send to the LKML are applied to linux-next or to the mainline git trees. If you are interested in trying it out, here are the details: The patches must be sent to the LKML (linux-kernel@vger.kernel.org). One of the cc's must be notify@kernel.org (Bcc will not work). Alternatively, there should be a "X-Patchwork-Bot: notify" email header. The patches must not have been modified by the maintainer(s). All patches in the series must have been applied, not just some of them. The last two points are important, because if there are changes between the content of the patch as it was first sent to the mailing list, and how it looks like by the time it is applied to linux-next or mainline, the bot will not be able to recognize it as the same patch. Similarly, for series of multiple patches, the bot must be able to successfully match all patches in the series in order for the notification to go out. If you are using git-format-patch, it is best to add the special header instead of using the Cc notification address, so as to avoid any unnecessary email traffic: --add-header="X-Patchwork-Bot: notify" You should receive one notification email per each patch series, so if you send a series of 20 patches, you will get a single email in the form of a reply to the cover letter, or to the first patch in the series. The notification will be sent directly to you, ignoring any other addresses in the Cc field. The bot uses our LKML patchwork instance to perform matching and tracking, and the source code for the bot is also available if you would like to suggest improvements...
You may access the archives of many Linux development mailing lists on lore.kernel.org. Most of them include a full archive of messages going back several decades. listing of currently hosted archives If you would like to suggest another kernel development mailing list to be included in this list, please follow the instructions on the following wiki page: Adding list archives to lore.kernel.org Archiving software The software managing the archive is called Public Inbox and offers the following features: Fast, searchable web archives Atom feeds per list or per individual thread Downloadable mbox archives to make replying easy Git-backed archival mechanism you can clone and pull Read-only nntp gateway We collected many list archives going as far back as 1998, and they are now all available to anyone via a simple git clone. We would like to extend our thanks to everyone who helped in this effort by donating their personal archives. Obtaining full list archives Git clone URLs are provided at the bottom of each page. Note, that due mailing list volume, list archives are sharded into multiple repositories, each roughly 1GB in size. In addition to cloning from lore.kernel.org, you may also access these repositories on erol.kernel.org. Mirroring You can continuously mirror the entire mailing list archive collection by using the grokmirror tool. The following repos.conf file should get you all you need: [lore.kernel.org] site = https://lore.kernel.org manifest = https://lore.kernel.org/manifest.js.gz toplevel = /path/to/your/local/folder mymanifest = /path/to/your/local/folder/manifest.js.gz pull_threads = 4 Please note, that you will require at least 20+ GB of local storage. The mirroring process only replicates the git repositories themselves -- if you want to use public-inbox with them, you will need to run "public-inbox-init" and "public-inbox-index" to create the database files required for public-inbox operation. Linking to list discussions from commits If you need to reference a mailing list discussion inside code comments or in a git commit message, please use the "permalink" URL provided by public-inbox. It is available in the headers of each displayed message or thread discussion. Alternatively, you can use a generic message-id redirector in the form: https://lore.kernel.org/r/message@id That should display the message regardless in which mailing list archive it's stored...
We'd like to announce several small changes to the way Linux tarballs are produced. Mainline release tarball signatures Starting with the 4.18 final release, all mainline tarball PGP signatures will be made by Greg Kroah-Hartman instead of Linus Torvalds. The main goal behind this change is to simplify the verification process and make all kernel tarball releases available for download on kernel.org be signed by the same developer. Linus Torvalds will continue to PGP-sign all tags in the mainline git repository. They can be verified using the git verify-tag command. Sunsetting .gz tarball generation We stopped creating .bz2 copies of tarball releases 5 years ago, and the time has come to stop producing .gz duplicate copies of all our content as well, as XZ tools and libraries are now available on all major platforms. Starting September 1st, 2018, all tarball releases available via /pub download locations will only be available in XZ-compressed format. If you absolutely must have .gz compressed tarballs, you may obtain them from git.kernel.org by following snapshot download links in the appropriate repository view. No future PGP signatures on patches and changelogs For legacy purposes, we will continue to provide pre-generated changelogs and patches (both to the previous mainline and incremental patches to previous stable). However, from now on they will be generated by automated processes and will no longer carry detached PGP signatures. If you require cryptographically verified patches, please generate them directly from the stable git repository after verifying the PGP signatures on the tags using git verify-tag...
If you are in charge of CI infrastructure that needs to perform frequent full clones of kernel trees from git.kernel.org, we strongly recommend that you use the git bundles we provide instead of performing a full clone directly from git repositories. It is better for you, because downloading the bundle from CDN is probably going to be much faster for you than cloning from our frontends due to the CDN being more local. You can even copy the bundle to a fileserver on your local infrastructure and save a lot of repeated external traffic. It is better for us, because if you first clone from the bundle, you only need to fetch a handful of newer objects directly from git.kernel.org frontends. This not only uses an order of magnitude less bandwidth, but also results in a much smaller memory footprint on our systems -- git daemon needs a lot of RAM when serving full clones of linux repositories. Here is a simple script that will help you automate the process of first downloading the git bundle and then fetching the newer objects: linux-bundle-clone Thank you for helping us keep our systems fast and accessible to all...