Be Social


Hot Products

Shopping cart


Cart empty

Linux Kernel

Linux Kernel News Feed

  1. Active kernel releases

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

    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 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.
    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.
    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.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 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, you are running a distribution kernel. To find out the version of your kernel, run uname -r:

    # 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.

  2. Git mirror available in Beijing

    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 mirror kindly provided by Code Aurora Forum at This is a full mirror that is updated just as frequently as other nodes (in fact, it is managed by the same team as the rest of 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://
    git fetch beijing master

    You may also use http:// and https:// protocols if that makes it easier behind corporate firewalls.

  3. Code of Conduct

    The Linux kernel community operates a Code of Conduct based on the Contributor Covenant Code of Conduct.

    Code of Conduct Committee

    The Linux kernel Code of Conduct Committee is currently made up of the following people:

    Committee members can be reached all at once by writing to <>.

    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 <>.

    December 2019

    Archival copy:

    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:

    In the period of August 1, 2019 through November 31, 2019, the Committee received no reports.

    September 2018 to July 2019

    Archival copy:

    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
  4. Frequently asked questions

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

    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 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

    We also publish a .json file with the latest release information, which you can pull from here:

    Why are there files that are dated tomorrow?

    All timestamps on 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 accounts are usually reserved for subsystem maintainers or high-profile developers. It is absolutely not necessary to have an account on 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 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. 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 should mirror your project, please contact with the following information:

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

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

    How does 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
    • 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

    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 (

    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 service was terminated on March 1, 2017. All content that used to be available via can be accessed by browsing 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.

  5. Get notifications for your patches

    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 (
    • One of the cc's must be (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.

  6. List archives on

    You may access the archives of many Linux development mailing lists on Most of them include a full archive of messages going back several decades.

    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:

    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, you may also access these repositories on


    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:

    site =
    manifest =
    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:

    That should display the message regardless in which mailing list archive it's stored.

  7. Minor changes to kernel tarball releases

    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 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 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.

  8. Best way to do linux clones for your CI

    If you are in charge of CI infrastructure that needs to perform frequent full clones of kernel trees from, 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 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:

    Thank you for helping us keep our systems fast and accessible to all.

  9. Nitrokey digital tokens for kernel developers

    The Linux Foundation IT team has been working to improve the code integrity of git repositories hosted at by promoting the use of PGP-signed git tags and commits. Doing so allows anyone to easily verify that git repositories have not been altered or tampered with no matter from which worldwide mirror they may have been cloned. If the digital signature on your cloned repository matches the PGP key belonging to Linus Torvalds or any other maintainer, then you can be assured that what you have on your computer is the exact replica of the kernel code without any omissions or additions.

    To help promote the use of PGP signatures in Linux kernel development, we now offer a detailed guide within the kernel documentation tree:

    Nitrokey logo

    Further, we are happy to announce a new special program sponsored by The Linux Foundation in partnership with Nitrokey -- the developer and manufacturer of smartcard-compatible digital tokens capable of storing private keys and performing PGP operations on-chip. Under this program, any developer who is listed as a maintainer in the MAINTAINERS file, or who has a account can qualify for a free digital token to help improve the security of their PGP keys. The cost of the device, including any taxes, shipping and handling will be covered by The Linux Foundation.

    To participate in this program, please access the special store front on the Nitrokey website:

    Who qualifies for this program?

    To qualify for the program, you need to have an account at or have your email address listed in the MAINTAINERS file (following the "M:" heading). If you do not currently qualify but think you should, the easiest course of action is to get yourself added to the MAINTAINERS file or to apply for an account at

    Which devices are available under this program?

    The program is limited to Nitrokey Start devices. There are several reasons why we picked this particular device among several available options.

    First of all, many Linux kernel developers have a strong preference not just for open-source software, but for open hardware as well. Nitrokey is one of the few companies selling GnuPG-compatible smartcard devices that provide both, since Nitrokey Start is based on Gnuk cryptographic token firmware developed by Free Software Initiative of Japan. It is also one of the few commercially available devices that offer native support for ECC keys, which are both faster computationally than large RSA keys and generate smaller digital signatures. With our push to use more code signing of git objects themselves, both the open nature of the device and its support for fast modern cryptography were key points in our evaluation.

    Additionally, Nitrokey devices (both Start and Pro models) are already used by open-source developers for cryptographic purposes and they are known to work well with Linux workstations.

    What is the benefit of digital smartcard tokens?

    With usual GnuPG operations, the private keys are stored in the home directory where they can be stolen by malware or exposed via other means, such as poorly secured backups. Furthermore, each time a GnuPG operation is performed, the keys are loaded into system memory and can be stolen from there using sufficiently advanced techniques (the likes of Meltdown and Spectre).

    A digital smartcard token like Nitrokey Start contains a cryptographic chip that is capable of storing private keys and performing crypto operations directly on the token itself. Because the key contents never leave the device, the operating system of the computer into which the token is plugged in is not able to retrieve the private keys themselves, therefore significantly limiting the ways in which the keys can be leaked or stolen.

    Questions or problems?

    If you qualify for the program, but encounter any difficulties purchasing the device, please contact Nitrokey at

    For any questions about the program itself or with any other comments, please reach out to

  10. Linux kernel releases PGP signatures

    All kernel releases are cryptographically signed using OpenPGP-compliant signatures. Everyone is strongly encouraged to verify the integrity of downloaded kernel releases by verifying the corresponding signatures.

    Basic concepts

    Every kernel release comes with a cryptographic signature from the person making the release. This cryptographic signature allows anyone to verify whether the files have been modified or otherwise tampered with after the developer created and signed them. The signing and verification process uses public-key cryptography and it is next to impossible to forge a PGP signature without first gaining access to the developer's private key. If this does happen, the developers will revoke the compromised key and will re-sign all their previously signed releases with the new key.

    To learn more about the way PGP works, please consult Wikipedia. web of trust

    PGP keys used by members of are cross-signed by other members of the Linux kernel development community (and, frequently, by many other people). If you wanted to verify the validity of any key belonging to a member of, you could review the list of signatures on their public key and then make a decision whether you trust that key or not. See the Wikipedia article on the subject of the Web of Trust.

    Using the Web Key Directory

    If the task of maintaining your own web of trust is too daunting to you, you can opt to shortcut this process by using the "Trust on First Use" (TOFU) approach and rely on the Web Key Directory (WKD).

    To import keys belonging to many kernel developers, you can use the following command:

    $ gpg2 --locate-keys [username]

    For example, to import keys belonging to Linus Torvalds and Greg Kroah-Hartman, you would use:

    $ gpg2 --locate-keys

    This command will verify the TLS certificate presented by before importing these keys into your keyring.

    Using GnuPG to verify kernel signatures

    All software released via has detached PGP signatures you can use to verify the integrity of your downloads.

    To illustrate the verification process, let's use Linux 4.6.6 release as a walk-through example. First, use "curl" to download the release and the corresponding signature:

    $ curl -OL
    $ curl -OL

    You will notice that the signature is made against the uncompressed version of the archive. This is done so there is only one signature required for .gz and .xz compressed versions of the release. Start by uncompressing the archive, using unxz in our case:

    $ unxz linux-4.6.6.tar.xz

    Now verify the .tar archive against the signature:

    $ gpg2 --verify linux-4.6.6.tar.sign

    You can combine these steps into a one-liner:

    $ xz -cd linux-4.6.6.tar.xz | gpg2 --verify linux-4.6.6.tar.sign -

    It's possible that you get a "No public key error":

    gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT using RSA key ID 38DBBDC86092693E
    gpg: Can't check signature: No public key

    Please use the "gpg2 --locate-keys" command listed above to download the key for Greg Kroah-Hartman and Linus Torvalds and then try again:

    $ gpg2 --locate-keys
    $ gpg2 --verify linux-4.6.6.tar.sign
    gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT
    gpg:                using RSA key 38DBBDC86092693E
    gpg: Good signature from "Greg Kroah-Hartman <>" [unknown]
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E

    To make the "WARNING" message go away you can indicate that you choose to trust that key using TOFU:

    $ gpg2 --tofu-policy good 38DBBDC86092693E
    $ gpg2 --trust-model tofu --verify linux-4.6.6.tar.sign
    gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT
    gpg:                using RSA key 38DBBDC86092693E
    gpg: Good signature from "Greg Kroah-Hartman <>" [full]
    gpg: Verified 1 signature in the past 53 seconds.  Encrypted
         0 messages.

    Note that you may have to pass "--trust-model tofu" the first time you run the verify command, but it should not be necessary after that.

    The scripted version

    If you need to perform this task in an automated environment or simply prefer a more convenient tool, you can use the following helper script to properly download and verify Linux kernel tarballs:

    Please review the script before adopting it for your needs.

    Important fingerprints

    Here are key fingerprints for Linus Torvalds, Greg Kroah-Hartman, Sasha Levin, and Ben Hutchings, who are most likely to be releasing kernels:

    Developer Fingerprint
    Linus Torvalds ABAF 11C6 5A29 70B1 30AB  E3C4 79BE 3E43 0041 1886
    Greg Kroah-Hartman 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E
    Sasha Levin E27E 5D8A 3403 A2EF 6687  3BBC DEA6 6FF7 9777 2CDC
    Ben Hutchings AC2B 29BD 34A6 AFDD B3F6  8F35 E7BF C8EC 9586 1109

    Please verify the TLS certificate for this site in your browser before trusting the above information.

    If you get "BAD signature"

    If at any time you see "BAD signature" output from "gpg2 --verify", please first check the following first:

    1. Make sure that you are verifying the signature against the .tar version of the archive, not the compressed (.tar.xz) version.
    2. Make sure the the downloaded file is correct and not truncated or otherwise corrupted.

    If you repeatedly get the same "BAD signature" output, please email, so we can investigate the problem. checksum autosigner and sha256sums.asc

    We have a dedicated off-the-network system that connects directly to our central attached storage and calculates checksums for all uploaded software releases. The generated sha256sums.asc file is then signed with a PGP key generated for this purpose and that doesn't exist outside of that system.

    These checksums are NOT intended to replace developer signatures. It is merely a way for someone to quickly verify whether contents on one of the many mirrors match the contents on the master mirror. While you may use them to quickly verify whether what you have downloaded matches what we have on our central storage system, you should continue to use developer signatures for best assurance.

    Kernel releases prior to September, 2011

    Prior to September, 2011 all kernel releases were signed automatically by the same PGP key:

    pub   1024D/517D0F0E 2000-10-10 [revoked: 2011-12-11]
          Key fingerprint = C75D C40A 11D7 AF88 9981  ED5B C86B A06A 517D 0F0E
    uid                  Linux Kernel Archives Verification Key <>

    Due to the systems compromise, this key has been retired and revoked. It will no longer be used to sign future releases and you should NOT use this key to verify the integrity of any archives. It is almost certain that this key has fallen into malicious hands.

    All kernel releases that were previously signed with this key were cross-checked and signed with another key, created specifically for this purpose:

    pub   3072R/C4790F9D 2013-08-08
          Key fingerprint = BFA7 DD3E 0D42 1C9D B6AB  6527 0D3B 3537 C479 0F9D
    uid   Linux Kernel Archives Verification Key
          (One-off resigning of old releases) <>

    The private key used for this purpose has been destroyed and cannot be used to sign any releases produced after 2011.

  11. RC tarballs and patches starting with 4.12-rc1

    As you may be aware, starting with 4.12-rc1 Linus will no longer provide signed tarballs and patches for pre-release ("-rc") kernels. Reasons for this are multiple, but largely this is because people who are most interested in pre-release tags -- kernel developers -- do not rely on patches and tarballs to do their work.

    Obtaining tarballs on your own

    Here is how you can generate the tarball from a pre-release tag using the "git archive" command (we'll use 4.12-rc1 in these examples):

    git clone git://
    cd linux
    git verify-tag v4.12-rc1
    git archive --format=tar.gz --prefix=linux-4.12-rc1/ \
      -o linux-4.12-rc1.tar.gz v4.12-rc1

    The upside of this method is that during the "git verify-tag" step you will check the PGP signature on the tag to make sure that what you cloned is exactly the same tree as on Linus Torvalds's computer.

    The downside of this method is that you will need to download about 1 GiB of data -- the entire git history of the Linux kernel -- just to get the latest tag. Notably, when -rc2 is tagged, all you'll need to do is run a quick "git pull" to get the latest objects and it will be dramatically less data to download, so cloning the whole tree may be worth it to you in the long run if you plan to do this again in the future.

    If you do not want to download the whole git repository and just want to get the latest tarball, you can download the version automatically generated by cgit at the following (or similar URL):


    Please note that you will not be able to cryptographically verify the integrity of this archive, but the download will be about 10 times less in size than the full git tree.

    Obtaining patches to the previous mainline

    If you would like to get just the patch to the previous mainline release, you can get it from cgit as well:

    wget -O patch-4.12-rc1

    Unfortunately, cgit does not currently offer an easy way to get gzip-compressed patches, but if you would like to reduce the amount of data you download, you can use http-level gzip compression:

    wget -O patch-4.12-rc1.gz --header="accept-encoding: gzip" \

    The links to these patches are available on the front page of

    Why not provide these at their old locations?

    We intentionally did not provide these automatically generated tarballs and patches in locations previously used by Linus (/pub/linux/kernel/v4.x/testing), even if this meant potentially breaking automated scripts relying on contents published there. Anything placed in the /pub tree is signed and curated directly by developers and all patches and software archives published there invariably come with a PGP signature provided directly by the developer of that software (or one of the developers).

    Patches and tarballs automatically generated by are NOT a replacement for this stringent process, but merely a convenience service that comes with very different trust implications. By providing these at different URLs we wanted all users of these services to make a conscious decision on whether they want to trust these automatically generated tarballs and patches, or whether they want to change their process to continue to use PGP-verifiable tags directly from the git tree.

  12. If you got "BAD Signature" this morning

    The XZ tarballs for the following kernel releases did not initially pass signature verification due to benign changes to the tarball structure done by the pixz compression tool:

    • 4.11.1
    • 4.10.16
    • 4.9.28
    • 4.4.68

    These changes would have resulted in GPG returning "Bad Signature" if you tried to verify their integrity. Once we identified the problem, we generated new XZ tarballs without tar header modifications and now they should all pass PGP signature verification.

    We preserved the original .xz tarballs as -badsig files in the archives in case you wanted to verify that there was nothing malicious in them, merely tar header changes. You can find them in the same v4.x directory:

    Our apologies for this problem and thanks to Brad Spengler and everyone else who alerted us about this issue.

  13. The Linux Kernel Organization

    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.

    The Linux Kernel Organization is managed by The Linux Foundation, which provides full technical, financial and staffing support for running and maintaining the infrastructure.

  14. About Linux Kernel

    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

    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 Please read the FAQ before subscribing.

    Although there is no official archive site, unofficial archives of the list can be found at:

  15. Contacts

    Email is the only reliable way of contacting administrators.

    General contacts
    General requests and comments about infrastructure.
    Questions or comments about mirrors.
    Account requests (see FAQ)

    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:

    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.

    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
  16. Fast new frontends with Packet

    Packet logo

    We are extremely happy to announce that Packet has graciously donated the new hardware systems providing read-only public access to the git repositories and the public website ( and, respectively). We have avoided using cloud providers in the past due to security implications of sharing hypervisor memory with external parties, but Packet's hardware-based single-tenant approach satisfies our security requirements while taking over the burden of setting up and managing the physical hardware in multiple worldwide datacenters.

    As of March 11, 2017, the four new public frontends are located in the following geographical locations:

    • San Jose, California, USA
    • Parsippany, New Jersey, USA
    • Amsterdam, Netherlands
    • Tokyo, Japan

    We have changed our DNS configuration to support GeoDNS, so your requests should be routed to the frontend nearest to you.

    Each Packet-hosted system is significantly more powerful than our previous generation frontends and have triple the amount of available RAM, so they should be a lot more responsive even when a lot of people are cloning linux.git simultaneously.

    Our special thanks to the following organizations who have graciously donated hosting for the previous incarnation of frontends:

    If you notice any problems with the new systems, please email

  17. Shutting down FTP services

    Those of you who have been around for a while may remember a time when you used to be able to mount directly as a partition on your system using NFS (or even SMB/CIFS). The Wayback Machine shows that this was still advertised some time in January 1998, but was removed by the time the December 1998 copy was made.

    Let's face it -- while kinda neat and convenient, offering a public NFS/CIFS server was a Pretty Bad Idea, not only because both these protocols are pretty terrible over high latency connections, but also because of important security implications.

    Well, 19 years later we're thinking it's time to terminate another service that has important protocol and security implications -- our FTP servers. Our decision is driven by the following considerations:

    • The protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons
    • FTP servers have no support for caching or accelerators, which has significant performance impacts
    • Most software implementations have stagnated and see infrequent updates

    All FTP services will be shut down by the end of this year. In hopes to minimise the potential disruption, we will be doing it in two stages:

    1. service will be terminated on March 1, 2017
    2. service will be terminated on December 1, 2017

    If you have any concerns, please feel free to contact (ah, the irony).

  18. TLS certificates

    Gandi logo

    If your browser alerted you that the site certificates have changed, that would be because we replaced our StartCOM, Ltd certificates with those offered by our DNS registrar, Gandi. We are very thankful to Gandi for this opportunity.

    A common question is why we aren't using the certificates offered by the Let's Encrypt project, and the answer is that there are several technical hurdles (on our end) that currently make it complicated. Once we resolve them, we will most likely switch to using certificates issued by our fellow Linux Foundation project.

  19. Cloning Linux from a bundle

    If you find yourself on an unreliable Internet connection and need to perform a fresh clone of Linux.git, you may find it tricky to do so if your connection resets before you are able to complete the clone. There is currently no way to resume a git clone using git, but there is a neat trick you can use instead of cloning directly -- using git bundle files.

    Here is how you would do it.

    1. Start with "wget -c", which tells wget to continue interrupted downloads. If your connection resets, just rerun the same command while in the same directory, and it will pick up where it left off:

      wget -c
    2. Once the download is completed, verify that the bundle has downloaded correctly:

      git bundle verify clone.bundle
      clone.bundle is okay
    3. Next, clone from the bundle:

      git clone clone.bundle linux
    4. Now, point the origin to the live git repository and get the latest changes:

      cd linux
      git remote remove origin
      git remote add origin
      git pull origin master

    Once this is done, you can delete the "clone.bundle" file, unless you think you will need to perform a fresh clone again in the future.

    The "clone.bundle" files are generated weekly on Sunday, so they should contain most objects you need, even during kernel merge windows when there are lots of changes committed daily.

  20. Introducing Fastly CDN

    Fastly logo

    We are happy to announce that Fastly has offered their worldwide CDN network to provide fast download services for Linux kernel releases, which should improve download speeds for those of you located outside North America. We have modified the front page to offer CDN-powered download links, but all the existing URLs should continue to work.

    If you would like to avoid using Fastly, you can simply change the URL to have "" instead of "". As always, please use PGP Signature Verification for all downloaded files regardless of where you got them.

  21. Hurr, Durr Im'a Sheep

    Linus named the upcoming 4.0 release of the kernel "Hurr Durr I'ma Sheep" (see his git commit), so we are celebrating this April Fool's day with a minor prank. If you've been redirected to, do not panic. It's all part of the joke.

    We've also restored all FTP and Rsync access to the servers, as we seem to have resolved our SSD and dm_cache problems. If you're still using FTP, however, please consider switching to HTTP. FTP is a protocol designed for a different era -- these days everyone should be avoiding it for multiple reasons.

  22. FTP limited on

    We've had to temporarily limit FTP access to due to high IO load.

    We have recently upgraded our hardware in order to increase capacity -- 16TB was no longer nearly sufficient enough to host all the distro mirrors and archives. We chose larger but slower disks and offset the loss of performance by heavily utilizing SSD IO caching using dm-cache.

    While it was performing very well, we have unfortunately run across an FS data corruption bug somewhere along this stack:

    megaraid_sas + dm_cache + libvirt/virtio + xfs

    We've temporarily removed dm-cache from the picture and switched to Varnish on top of SSD for http object caching. Unfortunately, as Varnish does not support FTP, we had to restrict FTP protocol to a limited number of concurrent sessions in order to reduce disk IO. If you are affected by this, simply switch to HTTP protocol that does not have such restrictions.

    This is a temporary measure until we identify the dm-cache problem that was causing data corruption, at which point we will restore unrestricted FTP access.

  23. Heartbleed statement

    Since we rely on the OpenSSL library for serving most of our websites, we, together with most of the rest of the open-source world, were vulnerable to the HeartBleed vulnerability. We have switched to the patched version of OpenSSL within hours of it becoming available, plus have performed the following steps to mitigate any sensitive information leaked via malicious SSL heartbeat requests:

    • Replaced all SSL keys across all sites.
    • Expired all active sessions on Bugzilla, Patchwork, and Mediawiki sites, requiring everyone to re-login.
    • Changed all passwords used for admin-level access to the above sites.

    As developers do not rely on SSL to access git repositories, there is no need to replace any SSH or PGP keys used for developer authentication.

    If you have any questions or concerns, please email us at for more information.

  24. Happy new year and good-bye bzip2

    Good-bye bzip2

    We started listing xz-compressed versions of kernel archives in all our announcements back in March 2013, and the time has come to complete the switch. Effective immediately, we will no longer be providing bzip2-compressed versions for new releases of the Linux kernel and other software. Any previously released .tar.bz2 archives will continue to be available without change, and we will also continue to provide gzip-compressed versions of all new releases for the foreseeable future.

    So, from now on, all releases will be offered as both .tar.gz and .tar.xz, but not as .tar.bz2. We apologize if this interferes with any automated tools.

    Happy new year!

    Happy new year to all users and visitors. The Linux Foundation and Linux Kernel Archives teams extend their warmest wishes to you all, and we hope that 2014 proves to be just as awesome (or awesomer) for the Linux kernel.

  25. New frontend and

    Montreal frontend

    We have added another official frontend for serving the kernel content, courtesy of Vexxhost, Inc. There is now a total of three frontends, one in Palo Alto, California, one in Portland, Oregon, and one in Montreal, Quebec. This should allow for better geographic dispersion of official mirrors, as well as better fault tolerance.

    We are happy to announce that is now relying on grokmirror manifest data to efficiently mirror, which means that if accessing is too high latency for you due to your geographical location (EMEA, APAC), should provide you with a fast local mirror that is at most 5 minutes behind official sources.

    We extend our thanks to Google for making this available to all kernel hackers and enthusiasts worldwide.

    TLS 1.2 and PFS

    With the latest round of upgrades, we are now serving TLS 1.2 with PFS across all sites, offering higher protection against eavesdropping.

  26. Mirroring repositories

    If you would like to mirror all or a subset of git repositories, please use a tool we wrote for this purpose, called grokmirror. Grokmirror is git-aware and will create a complete mirror of repositories and keep them automatically updated with no further involvement on your part.

    Grokmirror works by keeping track of repositories being updated by downloading and comparing the master manifest file. This file is only downloaded if it's newer on the server, and only the repositories that have changed will be updated via "git remote update".

    You can read more about grokmirror by reading the README file.

    Obtaining grokmirror

    If grokmirror is not yet packaged for your distribution, you can obtain it from a git repository:

    git clone git://

    In additon to git, you will need to install the following python dependencies on your mirror server:

    Setting up a mirror

    It is recommended that you create a dedicated "mirror" user that will own all the content and run all the cron jobs. It is generally discouraged to run this as user "root".

    The default repos.conf already comes pre-configured for We reproduce the minimal configuration here:

    site = git://
    manifest =
    default_owner = Grokmirror User
    # Where are we going to put the mirror on our disk?
    toplevel = /var/lib/git/mirror
    # Where do we store our own manifest? Usually in the toplevel.
    mymanifest = /var/lib/git/mirror/manifest.js.gz
    # Where do we put the logs?
    log = /var/log/mirror/kernelorg.log
    # Log level can be "info" or "debug"
    loglevel = info
    # To prevent multiple grok-pull instances from running at the same
    # time, we first obtain an exclusive lock.
    lock = /var/lock/mirror/kernelorg.lock
    # Use shell-globbing to list the repositories you would like to mirror.
    # If you want to mirror everything, just say "*". Separate multiple entries
    # with newline plus tab. Examples:
    # mirror everything:
    #include = *
    # mirror just the main kernel sources:
    #include = /pub/scm/linux/kernel/git/torvalds/linux.git
    #          /pub/scm/linux/kernel/git/stable/linux-stable.git
    #          /pub/scm/linux/kernel/git/next/linux-next.git
    # mirror just git:
    #include = /pub/scm/git/*
    include = *
    # This is processed after the include. If you want to exclude some specific
    # entries from an all-inclusive globbing above. E.g., to exclude all
    # linux-2.4 git sources:
    #exclude = */linux-2.4*
    exclude =

    Install this configuration file anywhere that makes sense in your environment. You'll need to make sure that the following directories (or whatever you changed them to) are writable by the "mirror" user:

    • /var/lib/git/mirror
    • /var/log/mirror
    • /var/lock/mirror

    Mirroring git repositories

    Now all you need to do is to add a cronjob that will check the mirror for updates. The following entry in /etc/cron.d/grokmirror.cron will check the mirror every 5 minutes:

    # Run grok-pull every 5 minutes as "mirror" user
    */5 * * * * mirror /usr/bin/grok-pull -p -c /etc/grokmirror/repos.conf

    (You will need to adjust the paths to the grok-pull command and to repos.conf accordingly to reflect your environment.)

    The initial run will take many hours to complete, as it will need to download about 50 GB of data.

    Mirroring a subset of repositories

    If you are only interested in carrying a subset of git repositories instead of all of them, you are welcome to tweak the include and exclude parameters.

  27. Fifty shades of Tux

    Special thanks to Benoît Monin for donating a MIT-licensed CSS theme to the project to replace the one we hastily put together. Though the Pelican authors have since obtained a free-license commitment from the copyright owners of the CSS files shipping with Pelican, we wanted to have something that looked a bit less like the default theme anyway.

    If anyone else wants to participate, full sources of the website are available from the git repository.

  28. XZ by default and JSON

    We've implemented two oft-requested features today:

    1. The download links now default to .tar.xz versions of archives
    2. There is now a JSON file with the release information located in If you've been screen-scraping the front page, please use this instead.

    If you have any other feature suggestions, please send them to

  29. /pub tree resync-ing

    Due to a failure in one of the rsync scripts during the maintenance window, the mirrors of /pub hierarchy on got erased. We are resyncing them now from the master storage, but in the meantime you will probably get an occasional "Forbidden". The entirety of the archive should be rsync'ed in a few hours.

    We apologize profusely for the problem and will fix the script to make sure this doesn't happen again.

    Contents of are unaffected.

  30. Cleanroom styles

    You are probably wondering what happened to the site's look. Unfortunately, we've been alerted that the default theme shipped by Pelican (which we largely adapted) has an unclear license. Until this is cleared up, we've put together a quick-and-dirty cleanroom CSS reimplementation that preserves the functional aspects of the site, but sacrifices a lot of the bells and whistles.

    If you are a CSS designer and would like to donate your own cleanroom style, please let us know at

    Our apologies, and we promise to keep a keener eye on licensing details of various templates distributed with open-source products.

  31. Pelican

    Welcome to the reworked website. We have switched to using Pelican in order to statically render our site content, which simplifies mirroring and distribution. You can view the sources used to build this website in its own git repository.

    Additionally, we have switched from using gitweb-caching to using cgit for browsing git repositories. There are rewrite rules in place to forward old gitweb URLs to the pages serviced by cgit, so there shouldn't be any broken links, hopefully. If you notice that something that used to work with gitweb no longer works for you with cgit, please drop us a note at

  32. Legal disclaimers and copyright


    Linux is a Registered Trademark of Linus Torvalds. All trademarks are property of their respective owners.