Language Selection

English French German Italian Portuguese Spanish

GNU Linux-Libre 5.14 Kernel Arrives for Those Seeking 100% Freedom for Their PCs

Filed under

Based on the recently released Linux 5.14 kernel series, the GNU Linux-libre 5.14 kernel is here to clean up the i915 Intel OpenGL graphics driver, clean and move the drivers for sp8870 and other av7110 cards in the upstream tree, adjusts the cleaning up script of the Renesas xHCI driver, and removes a r8188eu file.

It also adjust the cleaning up of the btqca driver since it was renamed upstream, cleans up a dts file that contained a blob-loading feature for a new Qualcomm ARM64 variant, disables another blog-loading feature from a new Emulex Fibre Channel Target driver, and cleans up new blob names from the adreno, amdgpu, and btrtl drivers.

Read more

"GNU Linux-libre 5.14-gnu was released today..."

  • GNU Linux-libre Was Mistakenly Including Non-Free Code, So Releases Now Re-Spun + 5.14

    GNU Linux-libre 5.14-gnu was released today as the project's re-base on the recently released Linux 5.14 upstream kernel. But prior supported GNU Linux-libre releases also had to be re-spun as it turned out this "100% free software" kernel was mistakenly leaving in some non-free kernel bits.

    As for the new changes with GNU Linux-libre 5.14, the Intel "i915" kernel graphics driver needed various alterations for its de-blobbing, the new Emulex Fibre Channel Target (eftc) driver needed to remove support for loading binary blobs, and various blob name changes were needed across various drivers from AMDGPU to others.

    So now the GNU Linux-libre 5.14 kernel is all dandy and out there for use on systems that can run without depending upon any of these stripped out binary firmware/microcode blobs and other non-free software components.

  • GNU Linux-libre 5.14-gnu, and earlier -gnu1 respins
    Apologies for the delay in getting this announcement out.  It's been a
    very busy couple of days, and this announcement had a lot of ground to
    cover.  Thanks for your patience.
    GNU Linux-libre 5.14-gnu cleaning-up scripts, cleaned-up sources, and
    cleaning-up logs (including tarball signatures) are now available from
    our git-based release archive git://
    tags {scripts,sources,logs}/v5.14-gnu.
    Tarballs and incremental patches will shortly be available at
    Freesh .debs are probably ready by now, and Freed-ora rpms are yet to be
    built.  BTW, Freed-ora still needs new maintainers.  Please let me know
    in case you're interested, and whether you'd like to share that task
    with others.
    The cleaning up scripts have been changed in very significant ways since
    the last -rc.  But first, the regular stuff.
    Cleaning up of i915 was adjusted on account of a renamed file; drivers
    for sp8870 and for other av7110 cards got moved in the upstream tree and
    cleaning up had to be adjusted.  An r8188eu file we used to clean up was
    removed, and documentation for the btqca driver got renamed upstream and
    cleaning up needed adjusting.  Upstream added a dts file specifying
    blobs to load for a new Qualcomm arm64 variant, and we've cleaned them
    Emulex Fibre Channel Target, eftc, is a new driver that seems to have
    inherited a blob-loading feature from its sibling lpfc.  Both build blob
    names from data read from the device, and then attempt to load them.
    That attempt is disabled in our distribution.
    New blob names were also found in btrtl, amdgpu, and adreno, and they
    have been cleaned up.
    Between rc7 and final, the Renesas xHCI driver got a change in the API
    used to load blobs, and our cleaning up scripts had to be adjusted to
    On to the unusual stuff.  A little over a week ago, Legimet raised flags
    on some potential nonfree code in GNU Linux-libre.
    Though some of the issues were about different standards (we don't
    generally regard poorly documented code or pure data as object code over
    speculation about the existence of an alternate, preferrable source
    form), but a couple of the issues turned out to be sourceless object
    code, and so we started the process of cleaning them up, and of
    respinning earlier releases that contained them.
    So now we clean up a firmware patch for vs6624 sensors, and several
    microcode relocation patches for powerpc 8xx.  Both are encoded as
    arrays of numbers in upstream Linux releases.  The latter had long
    seemed suspicious to me, but I had assumed those who started cleaning up
    Linux before I inherited Linux-libre had good reasons to leave it in.
    The former was entirely my own mistake.  I was likely fooled by
    apparently discontiguous address ranges, a pattern that suggests
    register initialization, but the multiple small fragments are actually
    larger contiguous ranges (thanks, Juca!), shuffled for reasons unknown.
    Thanks, Legimet, for reporting the issues.
    Back in the old days, when our releases were identified by -libre rather
    than by -gnu, it was not uncommon to respin older releases.  Sometimes
    we changed the cleaning up machinery and wanted to use it in earier
    active branches, for uniformity; sometimes Free firmware became
    available and drivers no longer needed to be cleaned up; other times we
    found or were told of errors as above.
    For such respins, we'd increment the -libre release counter, first to
    -libre1, then -libre2, and so on.  We hadn't had reason to do so since
    we became a GNU subproject, but the day was bound to come.  We now have
    -gnu1 releases for all of the active stable and longterm upstream
    branches: 5.13, 5.10, 5.4, 4.19, 4.14, 4.9, and 4.4.
    I've used the same deblob-check (our "database" of patterns to accept,
    flag or clean up) that went in 5.14-gnu, and backported various
    cleaning-up improvements that had been introduced over the years since
    4.4 first came up.  This took some back-and-forth testing and verifying
    and adjusting until I thought all of them had got cleaned up properly.
    While making the adjustments and hitting some differences in earlier
    versions, I've improved the cleaning up of x86 microcode documentation,
    and split various cleanup directions that used to be grouped under
    MICROCODE or similar.  These cleaned-up files are now listed under the
    actual configuration keys that enable them, even though the cleanups are
    conceptually related with microcode updates.
    After nearly 22 hours non-stop of cleaning up and backporting and
    adjusting and respinning and fixing and repeating, I had all of the base
    releases ready, so I pushed them to the git repo, and went for some
    sleep.  As I woke up, 5.14-gnu, 5.13-gnu1, 5.10-gnu1, 5.4-gnu1,
    4.19-gnu1, 4.14-gnu1, 4.9-gnu1, and 4.4-gnu1 tarballs had finished
    compressing, and I started respinning the latest patch release of each
    Alas, I did not catch a cleaning up error in 4.4-gnu1's b43 and
    b43legacy drivers, caused by my failure to backport some long forgotten
    custom cleaning up directions from the deblob-4.9 script to deblob-4.4,
    that still carried a more limited form of cleaning up.  Without those
    directions, deblob-check dropped quotes along with b43's blob names, and
    syntax errors ensued when attempting to build those modules.  Jason Self
    hit and reported the build error, and so we got b43 fixed in
    This was very important: b43 is one of the few WiFi drivers that works
    with Free firmware on some cards, and it was the need for retaining the
    code to load the Free firmware available for some variants, while
    disabling the code that loads the non-Free firmware that other variants
    require, that made its cleaning-up code so unusual, and deserving of a
    major rewrite with custom code between 4.4-gnu and 4.9-gnu.
    As soon as the respins were done, I pushed 5.13.13-gnu1, 5.10.61-gnu1,
    5.4.143-gnu1, 4.19.205-gnu1, 4.14.245-gnu1, 4.9.281-gnu1, 4.4.282-gnu1
    to the git repository.
    I also prepared erratum patches for 4.4-gnu1 scripts and sources; I've
    dubbed that 4.4-gnu1a.  It's not a release proper, just some patch files
    that will appear in releases/4.4-gnu1/errata-a/ in the download
    repository.  I figured I should get them in git too, even though they
    didn't go through the release process, so I applied the patches onto
    scripts/4.4-gnu1 and sources/4.4-gnu1, and tagged them as 4.4-gnu1a.
    There's a logs/4.4-gnu1a as well, with an ERRATUM.txt instead of
    README.txt, and no logs nor tarball signatures, but rather the patches
    and their signatures.
    Alas, I didn't notice the same problem affected b43legacy, and shortly
    after I pushed 4.4.282-gnu1 out, Jason reported the b43legacy problem
    was still there.  Ugh.  Unlike b43, that works on some cards with Free
    firmware, b43legacy doesn't work on any freedom-compatible cards, so if
    you hit the issue and wish to work around it before a fix is out, you
    might as well disable that module.  I expect to put out 4.4-gnu1b and
    4.4.282-gnu1b errata along with 4.4.283-gnu1, shortly after 4.4.283
    comes out upstream.  Hopefully this will be the end of it.
    Or maybe not.  If you'd have use for a respin of any of the other major
    releases (and latest stable/longterm patch release), please let me know.
    If you ask politely :-) I can try and give it a respin too.
    It will be eventually take over by the Linux git history librewrite
    (short for libre rewrite :-) project I've finally got going, that will
    greatly simplify and speed up the release process (just progressively
    integrate commits from upstream, fixing any freedom issues at point of
    the commit that introduces it), but it's still going to be a while till
    it catches up with active branches.
    (Incidentally, respins will become even more laborious under this
    arrangement, so let's hope they remain rare events, or that they're
    justified by newly-available Free firmware)
    The -gnu tarballs of past releases, that contain the newly-removed
    non-Free Software bits, are going away in a not-too-distant future (say
    from a couple of weeks to a month, when our infinite hunger for disk
    space gets close to filling up again the storage kindly provided by the
    FSF (thanks! :-).  At that point, only scripts and patches are going to
    remain within releases/old/gen6.
    The git tags are also going away, probably at about the same time: they
    aren't anywhere as space-hungry as tarballs, but those that contain
    non-Free Software don't belong in our git repository.
    In yet another news, we've been hanging out in the #gnu-linux-libre
    channel on for a while now.  Unlike #linux-libre on
    freenode, that we'd used long before becoming a GNU subproject, the new
    channel is in the GNU namespace.
    I don't know whether there are still people on #linux-libre on freenode,
    but I haven't been hanging there any more, after being locked out by
    one-too-many server configuration changes.
    What I do know is that there are still people on #linux-libre on  We used that channel for a few days, but couldn't get it
    registered under that namespace, so it has a topic that follows the
    right pattern (I put it there myself, a while ago), but we lost ops and
    can't update it any longer.  I'm told this has got some people confused,
    so if you are one of the few people who are still keeping it alive,
    would you please vacate it, and join us on #gnu-linux-libre on instead?  Thanks, talk to you there, ;-)
    For up-to-the-minute news, join us on IRC, or follow me on P2P or
    federated social media.  Check the link in the signature for directions.
    Be Free! with GNU Linux-libre.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

digiKam 7.7.0 is released

After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release. Read more

Dilution and Misuse of the "Linux" Brand

Samsung, Red Hat to Work on Linux Drivers for Future Tech

The metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world. Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility. Read more

today's howtos

  • How to install go1.19beta on Ubuntu 22.04 – NextGenTips

    In this tutorial, we are going to explore how to install go on Ubuntu 22.04 Golang is an open-source programming language that is easy to learn and use. It is built-in concurrency and has a robust standard library. It is reliable, builds fast, and efficient software that scales fast. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel-type systems enable flexible and modular program constructions. Go compiles quickly to machine code and has the convenience of garbage collection and the power of run-time reflection. In this guide, we are going to learn how to install golang 1.19beta on Ubuntu 22.04. Go 1.19beta1 is not yet released. There is so much work in progress with all the documentation.

  • molecule test: failed to connect to bus in systemd container - openQA bites

    Ansible Molecule is a project to help you test your ansible roles. I’m using molecule for automatically testing the ansible roles of geekoops.

  • How To Install MongoDB on AlmaLinux 9 - idroot

    In this tutorial, we will show you how to install MongoDB on AlmaLinux 9. For those of you who didn’t know, MongoDB is a high-performance, highly scalable document-oriented NoSQL database. Unlike in SQL databases where data is stored in rows and columns inside tables, in MongoDB, data is structured in JSON-like format inside records which are referred to as documents. The open-source attribute of MongoDB as a database software makes it an ideal candidate for almost any database-related project. This article assumes you have at least basic knowledge of Linux, know how to use the shell, and most importantly, you host your site on your own VPS. The installation is quite simple and assumes you are running in the root account, if not you may need to add ‘sudo‘ to the commands to get root privileges. I will show you the step-by-step installation of the MongoDB NoSQL database on AlmaLinux 9. You can follow the same instructions for CentOS and Rocky Linux.

  • An introduction (and how-to) to Plugin Loader for the Steam Deck. - Invidious
  • Self-host a Ghost Blog With Traefik

    Ghost is a very popular open-source content management system. Started as an alternative to WordPress and it went on to become an alternative to Substack by focusing on membership and newsletter. The creators of Ghost offer managed Pro hosting but it may not fit everyone's budget. Alternatively, you can self-host it on your own cloud servers. On Linux handbook, we already have a guide on deploying Ghost with Docker in a reverse proxy setup. Instead of Ngnix reverse proxy, you can also use another software called Traefik with Docker. It is a popular open-source cloud-native application proxy, API Gateway, Edge-router, and more. I use Traefik to secure my websites using an SSL certificate obtained from Let's Encrypt. Once deployed, Traefik can automatically manage your certificates and their renewals. In this tutorial, I'll share the necessary steps for deploying a Ghost blog with Docker and Traefik.