Dear Purism Community,
Thank you so much for taking the time to read my post.
I recently received a beautiful Librem 11 from Purism.
However, I missed the operating system that runs on my older machine and therefore decided to switch it to the Trisquel operating system.
However, the WiFi connect widget does not offer any available networks.
Is this a common error with Trisquel GNU/Linux on the Librem 11? Have you seen a similar issue and would have any useful feedback?
Thank you so much and I look forward to reading all of your responses.
For those unaware of the Trisquel GNU/Linux project, here is their Wikipedia page:
Edit: I just wanted to clarify that this post regards the L11V1; the newest edition.
Strictly speaking neither Trisquel nor PureOS are purely Gnu System but Fedora Enterprise’'Redhat". However Trisquel it is NOT friendly with LinuxBLOBs than PureOS so that is the reason why WLAN does not working on Trisquel.
I haven’t used it personally, but it looks like Trisquel uses a kernel similar to linux-libre, which removes the ability to load device firmware when no free firmware exists for that device. To solve that, you’ll need to use a different kernel or a different distribution. PureBoot provides the device firmware for OSes that don’t have it, but the OS still has to allow you to load it.
That’s the blob @carlosgonz is referring to - the device firmware for the Intel Wi-Fi card. Wi-Fi won’t work without it.
While I wish there were modern cards with free firmware, unfortunately there aren’t any. (The ath9k didn’t either, but the proprietary firmware was stored in a chip on the card, so the OS didn’t have to know about it.)
I use it ath9k-htc which is a GNU FRYF(Fully Respect your Freedom) Hardware. However Freescale is Coooking a modern WLAN/WPAN Controller which will be FRYF or RYF.
Basically Purism is moving towards “playing games to respect your freedom” mode instead of “exactly what the FSF probably had in mind to respect your freedom” mode, because although Purism probably has good intentions or whatever, the evil governments and corporations don’t actually want users to be able to control their wifi hardware fundamentally.
If you could control your wifi hardware or write your own firmware for it, then you would probably be able to know about what’s really going on in the information war, and that’s just outside the scope of what the powers that be want to give you.
So for a long time, like in my Librem 14, in order to count as RYF-certified Purism was shipping wifi chips that use proprietary firmware burned onto the wifi chip. So the OS doesn’t know about it, the OS can’t change it, and accordingly from an FSF standpoint of “respecting your freedom” whatever is on that wifi card is not software by their definition since it could have been wiring and circuitry for all we know.
But, as I understand it the Librem 5 pioneered the idea of “the firmware jail,” which is to say that the immutable burned memory of the wifi chip firmware was no longer included with the chip. So, Purism shipped these devices with some read only memory that contained a copy of the nonfree firmware, included on their Purism hardware, but in a place that the PureOS can pass it from the read only memory hardware into the wifi chip, thus using a proprietary and nonfree wifi firmware on a nonfree chip but inside of a “freedom respecting” device that can continue to claim to be “freedom respecting” because the OS cannot change the contents of the read only memory that moves into the wifi chip on startup.
This concept that they call “firmware jail” worked on the Librem 5s and people kept buying them and feeling free and not thinking about it – since who among us actually tries to replace our wifi drivers – and so they started shipping firmware jails on the Purism laptops and tablets now as well. Their article also suggested that PureOS has some way to overwrite which nonfree firmware is sent to the wifi chip instead of only sending the one from immutable memory, which their folks described as adding to your freedom since it puts you in control of which binary blob to choose.
I’m not sure if I believe that’s improved freedom in the FSF sense, since now we’re literally saying I’m free to choose which nonfree binary blob to run as though this were software freedom. You know, I’m also free to choose whether I want to use Windows 10 instead of Windows 11, but for some reason the FSF doesn’t endorse that kind of freedom as solving the problem of malicious software.
So, this is my understanding, but I’m just a user. I don’t write my own wifi firmware. Lately I was using a Librem 14 from before the days of the firmware jail. And, accordingly, last time I used it in a public place with wifi enabled – without me even joining any wifi network – the whole screen started to flicker like crazy. Updates to the screen would be interspersed with black gobblety gook, and when I switched off the wifi kill switch to disable networking and rebooted the machine everything went back to normal.
So, one possibility if we think about government contractors using Purism hardware, is that the government folks probably have the wifi firmware source code and benefit from being able to compile their own fork that patches vulnerabilities. And when I use my pre-firmware-jail Librem, there might be unpatched vulnerabilities in the firmware embedded in the wifi chip that can never be patched since the chip does not expose its firmware to the OS. And thus we end up in a world where everyone is equally able to replace the software on their computer, but some of us are more equal than others if they are government employees and have wifi firmware source code. And if those are the Purism customers, they prefer the freedom to replace their wifi blobs and the freedom to have firmware jail.
Long story short, lookup how to load from firmware jail on Trisquel.
Is it possible to install a different kernel on Trisquel GNU/Linux or is the generalized thought process that I would have to stop running Trisquel on the Librem 11?
Thanks for the well thought out post @Dlonk, I appreciate your perspective. I’d like to share my own perspective about why the firmware jail is about providing the best options available today to all users, not catering to the needs of those with insider access.
This, in my opinion, is where the “game” starts. Linking the definition of “software” exclusively to where the program is stored doesn’t make sense any more.
I think the intent is clear - if the proprietary firmware is perfect, so that we never need to care whether it’s a program executed by a processor or a bunch of NAND gates with the same effect, then it doesn’t count as software.
Maybe that’s true for some things, like a mouse. The mouse probably has firmware that knows how to read the optical sensor, infer movements from the image observed, and report those movements over USB. The mouse firmware shouldn’t count as software. But again, the fact that it’s stored in ROM is at most only part of this determination.
I don’t think these things have been true for wireless hardware for some time now, regardless of where we store the firmware. Wi-Fi devices perform complex tasks and are exposed to data potentially controlled by an attacker.
Remote code execution vulnerabilities have affected Wi-Fi device firmware, allowing code execution on the card itself. Wi-Fi firmware has bugs (just take a look at the history of linux-firmware for firmware updates, though unfortunately most of the updates give minimal details).
And back to the mouse - if your mouse is wireless, then suddenly it is exposed to attacker controlled data and may be exploitable. You do have to care about its firmware now, it should count as software, even though it is burned into a flash ROM chip. (This is technically about the receiver, but the mouse is of course part of this system too.)
I’m not necessarily saying that Wi-Fi cards with firmware provided by the OS should count as RYF. I am saying that Wi-Fi cards with firmware burned into a ROM are worse in today’s environment. Calling them better is harmful.
The best situation of course would be cards with free firmware, there’s an entirely different discussion about why that doesn’t exist today. But without that option, we offer the best we can - put the blob somewhere you can see, inspect, and control, and offer no Wi-Fi as an option when possible if that meets your needs or you prefer a different card. If we keep pushing the limit in every way we can, we will make progress toward the ultimate goal.
It’s certainly possible. However I could not find a great guide if you do not have experience in this sort of thing.
You might consider installing Debian instead. This is easier if you are not experienced with customizing kernels. You would not need Debian’s non-free-firmware repository, since the PureBoot blob jail has the needed Wi-Fi firmware. Debian’s live image installers are easiest to use and most similar to Ubuntu. PureBoot requires an unencrypted /boot partition, be sure it is partitioned that way when you install.
Trisquel is probably more similar to Ubuntu than Debian, but Ubuntu contains other non free software besides device firmware, so I would probably suggest Debian.
If you still want to experiment with Trisquel, some options to consider could be:
Install an Ubuntu or Debian kernel. I wonder if you could enable Debian’s bookworm-backports repository and install the Linux kernel from there.
Compile a kernel yourself. There are some guides to do this for Debian, though none that I’ve reviewed are perfect and still require some know-how (some details change over time, guides haven’t always been updated). Please be aware that there is a kernel bug affecting 6.6+, so stick to 6.5 for now, I just bisected that bug and I’m working on it.
If a Hardware is FRYF the FSF is permit to load the firmware on OS, if it is a RYF Hardware Of Course NOT.
Example from a FRYF HARD: AWUS036NHA – ALFA Network Inc.
That is just your own opinion that,s it, and of course you make me nervous for the future of Purism.
I guess on the security front, I’m willing to admit that allowing the OS to load new blobs onto the Wi-Fi card may be better in some cases, but it is harmful to software freedom.
But people who care about software freedom must be willing to forego some utilitarian benefits to themselves for the furtherance of freedom, not just for themselves, but freedom for others too. For example,
One could just as truthfully say, “Librem 11’s are worse in today’s environment than iPads. Calling them better is harmful.”
I would say neither of the above statements, because of my value of software freedom. Hopefully sometime soon Trisquel will be able to use Wi-Fi out of the box on Purism devices without loading any firmware blobs.
Thanks, let me clarify. What I meant was that it is clear to me which of these strategies offers more user control - firmware in a file offers more control than the same firmware burned into a ROM chip. But since RYF currently prefers the latter, and treats it as equivalent to a card with totally free firmware, it’s not clear to me how to best change RYF to describe this situation. So I did not intend to take a stance there on which things RYF should approve, since that’s an additional debate and the post was already pretty long And of course as we get more into opinions, remember that these are my individual opinions.
Consider this scenario - what if we were to make a variant Intel ax200 card, where we took the same firmware file and burned it onto a ROM chip on the card? RYF prefers that, treating it as equivalent to a card with free firmware. But as I described above, it’s no more free and has less owner control than leaving the firmware in a file; it does not make sense that RYF prefers this.
How could RYF prioritize these differently? There are plenty of ideas. Should it have “grades” instead of totally true/false? Should it depend on some qualitative assessment of whether we can really assume the firmware is “perfect”? Something else? I’m not sure, which is why I said “not necessarily” meaning I am not sure how RYF should compare the cards. I do feel that it should not prefer the ROM chip version as it does today.
Not sure what you mean here, do you mean both statements are true or both statements are false?
Disagreements about what is “better” usually come down to priorities - and, in this particular case, what your realistic threat model is.
Let’s say that an RCE vulnerability is a given for a device that receives attacker-chosen packets wirelessly … it is certainly an interesting question as to whether the exploit could persist itself (and that obviously depends on where and how the firmware is stored and whether any additional security measures are in place). However that may not be a realistic threat for some of us.
I find it difficult to look at the matter from this perspective. If a device prevents me from running a FSF-endorsed distribution of my choice, doesn’t it limit some of my software freedoms? Also, from an ordinary user perspective, when the firmware binary is available, the advantage of newer technology is likely to become obsolete by the time it is freed if ever.
To be honest this just add more control and benefits for the company(Purism,Intel,SparkLan) THAN for user. We dont have to trust on blackboxes even if it has a humble changelog, evenworse that this happening on FSF Verified Operating System as Gnu Pure OS does.
The main Approach for Gnu System it to give an absolute FREEDOM OS over FEATURES OS.
If PureOS it not on the Free Software Foundation’s list then i would keep my mouth shut and not say anything about blobs or freedom.
Unless you can find a WiFi card where the firmware is in ROM, it’s an academic question.
Purism doesn’t manufacture WiFi cards, therefore is limited by what the market provides. I am not aware of any current technology WiFi cards where the firmware is in ROM - but if you can find one, then you can swap it out and nothing about the software side of things will prevent you using that card or prevent you running a FSF-endorsed distro.
In other words, “firmware in a file” is not the problem. The WiFi card is the problem (for needing the firmware in the first place).
Unfortunately the Librem 11 is the wrong platform to be contemplating this because it doesn’t appear to be designed to make it easy or even possible(?) to swap out the WiFi card c.f. Librem 5 or Librem 14.
It is a practical consideration for a customer shopping for a device with an option to run a FSF-endorsed distribution other than PureOS or a customer who already purchased a Purism device with such intention in mind, which perfectly fits the situation that the topic starter found themselves in. Should the blame for such expectations be entirely on the customer? The product page for Librem 11 states as follows.
Shipping with PureBoot and PureOS, you make sure that the Librem 11 is fully yours and is respecting your Privacy, Security and Freedom by default.
However, it does not clarify that the firmware jail technology is being used for the device. This technology is not an industry standard. The prospect customers should be informed about the trade-offs that it entails. They are significant enough for me to be the only reason to not buy a Librem 11. They may or may not be significant for other customers. For comparison, I would still buy and recommend Librem 5 considering how unique it is, even though I fail to see the benefit from the firmware jail instead of a file.
Please consider the impression from the following passage, which comes from a Purism’s blog post returned by web searches for “firmware jail Librem 11” and “firmware jail Purism”.
PureBoot’s Firmware Blob Jail feature provides device firmware for operating systems that do not include any non-free components, like PureOS. Using the Linux configurable firmware search path, it does not require a special kernel or any special operating system support.
Trisquel falls into the category of “operating systems that do not include any non-free components”. I understand that @jonathon.hall did not mean that Trisquel would be able to utilize a firmware jail, but the phrasing makes it appear that there could be other operating systems besides PureOS that could fit the description, so that other FSF-endorsed free GNU/Linux distributions reasonably come to mind.
The communication from Purism on the matter is confusing and may build wrong expectations with the customers, potentially resulting in a bad image due to dissatisfied buyers and turning off some prospect customers and members of the free software community even for the products which could run Linux-libre or for the relevant free software projects.
I don’t think this is a fair way to frame this situation. We’ve done everything we can to make it possible to run the distribution of your choice, including properly integrating fixes into the device’s firmware instead of quirking and overriding in the OS. It is the FSF that chooses to ship a kernel denying you the choice to load device firmware. And other than Wi-Fi, reports indicate that Trisquel does work. You could use a USB Wi-Fi adapter with it.
In my opinion (I’d be interested in other opinions as well), freedom/liberty should mean that my computer allows me to run the software of my choice, even if I choose to run a piece of proprietary software. While it certainly should not recommend that path, I should be allowed to do so if I choose. Adding engineering to make the computer deny my request is an anti-feature.
It’s true that community-freed devices tend to be far behind the cutting edge. However I don’t think admitting defeat is a useful approach, we should still try to push the boundary in whatever small way we can.
If shipping outdated devices is unaccepatble, and shipping devices with firmware loaded by the OS is unacceptable, then what option remains? While I would love to engineer our own wireless cards with fully free firmware, we are not at a scale to do so. There is immense engineering effort needed, as well as regulatory issues likely requiring legal work, and we need to be able to produce and sell these devices in very high volume to achieve economies of scale that make it feasible.
That’s the grand vision. I believe we can get there in the long run, but we are not there today. To get there, we have to push the envelope as far as we can, show that there is demand for free software because of its inherent advantages, and gain enough momentum to pressure these vendors or build it ourselves.
This is objectively untrue.
If proprietary firmware is burned into a ROM, the vendor and system integrator have far more control. The devices could have malware injected on an individual basis, and you have no way to know. You have no way to replace or inspect that firmware. You place complete trust in it.
If the same proprietary firmware is stored on your system and uploaded at runtime, then you can compare it against others. You can also analyze it. If a security analyst identifies a version with issues (accidental or intentional), you can check whether you are running that version and choose a different one.
Definitely true. I still believe that moving firmware out of hidden ROMs is the first step toward user freedom. Wireless is the highest-value target IMO, so we start there.
Yes, this is also true, the Wi-Fi card in the Librem 11 is soldered to the board and not replaceable. We know this is a compromise. As I’ve said before, taking incremental steps is the only way to reach the grand vision. We can’t wait for perfection to produce anything. Despite the soldered Wi-Fi card, I believe the Librem 11 makes many steps in the right direction promoting user freedom, and there are few other devices doing this in this segment.
Thank you for clarifying this. I understand your point and I think this is fair that we can improve communication in this regard.
I believe you could use Trisquel if you installed a standard Linux kernel (still not including any nonfree components, but without the antifeatures to disable firmware loading).
We can’t possibly control every kernel customization in every OS distribution. While the blob jail is nonstandard, the Linux features to load device firmware using the configurable firmware search path are standard Linux features. Trisquel unfortunately disables one of these features. The only distributions I am aware of that do this are Trisquel and GNU Guix.
However I do see your point that a reader could interpret “operating systems that do not include any non-free components” could suggest Trisquel and GNU Guix, because there are few such operating systems. Readers probably are not aware that they disable a related standard kernel feature in their kernels. Actually, the OS I had in mind was an OS in use by a partner organization, but readers are less likely to be aware of this. I appreciate your clarification that the post may suggest a specific meaning I had not intended.
I am sorry but you are completely wrong @jonathon.hall and you will never convince me unless Gnu PureOS is removed from the FSF approved list of systems. Stop to use FSF as a Honey Spot for user.
Your answer is from an original opensource programmer which makes me nervous. So the future of Purism will not be promising for Gnuine Libre Software in this way.
The most important thing right now is to SAVE Purism from the very bad reputation it has earned, but opensourcing will not help anything…i.m.h.o.
@carlosgonz , I would appreciate it if you can provide specific reasons why you believe I am wrong. (For example, is there a reason that you believe firmware in a file empowers the device vendor? Or, is there a change you would request to our products that is feasible at our current scale, and could you explain why you believe it is better?) We can only have a constructive discussion if I can understand why you feel this way.
Fair point. For those customers where this is important, that information should be available to them.
In my opinion, a customer is unlikely to want to use this particular device without WiFi, and if the WiFi can’t be swapped out, the customer should either run PureOS or should run a distro that is less free than PureOS. (That’s still vastly superior to a duopoly device. My actual beef with the Librem 11 is the lack of a WiFi kill switch.)
… with care. Some WiFi dongles also require loadable firmware, which ultimately must either come from the firmware jail or from the operating system disk.
Perhaps Trisquel can utilize a firmware jail. Not out of the box of course. But surely if you are dead set on using Trisquel as a distro, it can be made to use a firmware jail? After all, you own the device - and that would be a freedom.
As a result you may lose your own personal FSF endorsement (and you wouldn’t want to make a commercial supply of such a configuration i.e. personal use only).
It raises the somewhat theoretical possibility that the firmware could be reverse engineered and freed. If the firmware is in a ROM inside the card then there may be no interface to access the firmware at all.
I suspect that sheer complexity has forced manufacturers to make the firmware available as a file but that now means that the firmware is available for inspection or even potentially alteration. Yes, manufacturers could go down the Intel route of encrypting (and signing) the firmware but …
And of course as we get more into opinions, remember that these are my individual opinions.