Trisquel Librem 11 Wifi Troubleshooting

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.

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

I greatly appreciate you taking the time to respond to my post.

Trisquel does utilize Linux-libre1.

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?

Thank you so much.

1 Like

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.

1 Like

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.

1 Like

Which is it? You seem of two minds here.

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.

1 Like

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 :slightly_smiling_face: 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?

1 Like

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.