I thought running updates would be a good next move. I happened to have a USB-C network adapter and managed to run updates. There was a dependency issue and I had to remove pureos-security-hardening.
After rebooting, still no-go. ‘ip link show’ only shows loopback. Pull down menu shows Wi-Fi disabled. The button is black, not gray. Bluetooth appears to function.
lspci does appear to show the device:
00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 160MHz (rev 01)
I think I’ve identified the correct firmware: iwlwifi-QuZ-a0-jf-b0-72.ucode and I’ve loaded it into /lib/firmware. I also created /firmware and put it there. I noticed the firmware_class.path=‘/firmware/’ at boot. Neither seemed to work. Syslog has an entry from back in September of last year showing the firmware loading:
I don’t know why the kernel driver isn’t loading it yet. Udev? I’m beginning to wonder if it was removed/disabled at some point. I know Purism is trying to get to 100% non-proprietary firmware. It’s a noble pursuit, however, I kinda need WiFi to work. I’m liking the hardware so far! It’s a nice piece of tech. Maybe this was a returned unit? Condition is perfect and no signs of the package being re-sealed.
Having read more this weekend about the firmware jail and how it works, you are absolutely correct. Thank you for the suggestion.
I can confirm that the firmware jail has the same version firmware that I’ve been trying to load, right down to the checksum: iwlwifi-QuZ-a0-jf-b0-72.ucode.
It seems like iwlwifi is failing to identify the hardware, probe fails and it doesn’t know which firmware to load. The syslog entry showing it loading successfully (in September 2023) is the same version. My guess is a bug was introduced in a later kernel update which includes iwlwifi module. Odd that I’m the only one seeing this.
OK, so things to check would include: does the firmware jail exist? does it have anything in it? the right thing? (I think you have already verified these things so far) is it being accessed successfully during boot?
Again, not having a Librem 11, I can’t give you commands to investigate the above. You may have to contact Purism Support support@puri.sm
I’ve checked all of these. Successful access to firmware during boot is an unknown. Again, from the error it looks like it fails to probe the card and never gets as far as loading firmware. I’ll contact support. Thanks.
Just to close out this thread for the benefit of others, support asked that I cold boot (‘shutdown -h now’, and then power up). That worked. I had been soft rebooting throughout this process.
Glad this worked for you. I was considering recommending that based on the need for a full discharge, but because your system was new out of the box, I wanted Purism to give you that guidance after confirming no other hardware problem.
I have actually still found this can happen at times, especially if you somehow force a hard lock, so be sure to remember to power the device down and unplug any cables (including power) to enable that discharge in the future too. Channeling my own personal experience and tiny Jonathan voice.
Thanks for following up @molson , and I’m glad you were able to get the answer from support while I was away last week.
We have seen this issue a few times, and it appears to be an issue internal to the ax201 card itself, it’s getting stuck in some improper state. Cold boot is the right answer as it persists through a reboot. Disconnecting AC power for 10 seconds while off, then powering back up, is the most foolproof method as this shuts off the EC as well. (There’s no need to discharge the battery, system power is off when the EC is off.)
