No more WiFi after today OS update

Hardware Librem 5
2

I am seeing the same thing. For me, the WiFi card is not being seen during boot, once the phone has powered up I am seeing that the WiFi card can be brought up by switching the WiFi/BT hardware kill switch to off/disabled then back to the on/enabled position.

Unfortunately, I am also seeing a severe degradation in WiFi performance after this update, considering the performance was already in the realm of disappointing prior to the update it’s not good.

You can see the some details of the update by looking at /var/log/apt/history.log file

The update brought a newer kernel, the old kernel is still on the phone in the boot directory, on desktop systems you can choose the previous kernel at boot from the boot/grub menu, I have no idea how to achieve similar on the phone or if it’s possible. Maybe it’s enough to cp the old vmlinuz and initrd.img files over but there a few more files in the boot directory than I’m familiar with so there may be a little more to it than that to restore the old kernel version.

1 Like
3 
sudo flash-kernel --force 5.9.0-1-librem5
5 Likes
4

Thanks @dos, that info is much appreciated and saves me a lot of time, I was just digging my way through the scripts at /etc/kernel/postinst.d/ trying to work out what gets done during a kernel package update.

I can confirm that it does restore the kernel to previous version and that the WiFi card is now being recognised and brought up during boot.

Hopefully that also brings the previous WiFi performance back, I suspect it will, I’ll check it later. With the 5.11 kernel, It was quicker to transfer files from a server sat 4m away from me by going out to the net through wireguard over cellular than it was to simply go through internal network on WiFi.

4 Likes
5

I don’t have any problems with WiFi after the kernel upgrade.

Edit1: After a cold restart, I did see that the setting had disappeared, but flicking the kill switch off, then on, brought it back again, with “Excellent” signal strength.

Edit2: WiFi still returns as normal after restarts.

2 Likes
6

OK so there are two things:

  • WiFi not appearing right after boot is a known issue, although it seems to only affect some small amount of devices. See https://source.puri.sm/Librem5/linux-next/-/issues/264. Usually toggling the killswitch should bring it back.

  • the degradation of WiFi performance after upgrade is not expected. If you also experience it like @Loki above, please report it (and please check whether it’s actually consistently better on older kernel and worse on the newer one - see my post above on how to switch between kernel versions). Also check the status of power saving mode with sudo iw dev wlan0 get power_save - it should be off.

2 Likes
7

This must be related to forcing 20MHz:

Maybe some users had set their device or router to another frequency?

1 Like
8

I updated my evergreen today, now i having newer kernel 5.11, and i do not have any issues on WLAN, in fact my L5 work nice/fast now with the newer driver for BT/WLAN. I just reporting…

2 Likes
9

Potentially, users reporting failure, or success, should be giving an indication of their configuration e.g. band (2.4 GHz or 5 GHz or auto), channel width (20 MHz, 40 MHz, … or auto), make/model of wireless access point (router), any other pertinent WiFi settings (of which there are many).

However, if the WiFi card is not showing up at all then much of the above won’t be relevant.

1 Like
10

Issues like this make me a little concerned about the testing Purism does before releasing new software for PureOS.

This isn’t the first time I’ve read “X broke on update” here. Aside from wine, I haven’t had an issue with any of my systems from an update to linux in at least 5 years.

11

Assessing WiFi after switching back to the 5.9 kernel, it seems consistently better for both stability and general performance. I ended up going back to the 5.11 kernel to spend a little more time with it to be sure my previous observations were consistent and not down to some coincidental glitch. I also noticed that streaming audio via Bluetooth while simultaneously being connected via WiFi has also degraded a little.

Not sure how helpful or not this info is, however, I have a couple of different APs to work with (a MikroTik hAP ac^2 configured as a simple AP bridge serving 5Ghz and a Ubiquiti Nano HD serving 2.4Ghz) both of these along with a file server are connected to a switched bridge on a MikroTik RB4011 the topology is…

Librem5 <-> MikroTik hAP ac^2 <-> MikroTik RB4011 bridge <-> Intranet File Server
and…
Librem5 <-> Ubiquiti Nano HD <-> MikroTik RB4011 bridge <-> Intranet File Server

I tried various configurations and combinations of channel widths and available protocols on the hAP ac^2, there seemed to be no discernible difference. The Nano HD I just left as was which is 2.4Ghz b/g/n 20-40Mhz channel width, this AP drops to the lowest channel width of a single client so if there is one single client that can only operate on 20Mhz when all others can deal with 40Mhz, the AP will drop down to 20Mhz.

Pulling a batch of files (the same batch each time) of approximate 15-45MB in size I’m seeing the following…

Librem5 (5.9 kernel) via hAP ac^2 download 1.5~3.0MB/s
Librem5 (5.11 kernel) via hAP ac^2 download 500~650KB/s
Librem5 (5.9 kernel) via Nano HD download 300~400KB/s
Librem5 (5.11 kernel) via Nano HD download 120KB/s~timeout

Perhaps coincidental, while on the 5.11 kernel I experienced 2 phosh reboots and one unplanned/ungraceful shutdown, none of which were repeatable, I experience the same from time to time on 5.9 kernel but in such a short space of time. Touch/swipe to close apps from the application switcher seemed a little off too, on one occasion with the app thumbnail centered, swipe up was not recognised, I swiped right and was then able to swipe up on the left hand visible portion of the thumbnail to close the app, again, non repeatable.

I’ve decided to stay with the 5.9 kernel for the moment and my OCD also wanted to get APT back to being in the right state with regards tracking installed kernel packages as it was showing 5.11 installed but I was running the 5.9 kernel.

The rest of this post just details the steps I went through to put APT back to pre-upgrade state, you can skip the rest if it’s not something you want/need to do.

Although no longer available for straight forward install from the repos via apt-get, I found the kernel packages by browsing the repos online, so I first downloaded packages…

wget https://repo.pureos.net/pureos/pool/main/l/linux-librem5/linux-image-5.9.0-1-librem5_5.9.16+librem5.2_arm64.deb
wget https://repo.pureos.net/pureos/pool/main/l/linux-librem5/linux-image-librem5_5.9.16+librem5.2_arm64.deb

dpkg -I linux-image-librem5_5.9.16+librem5.2_arm64.deb showed I only needed the second deb file as it listed a single dependency “linux-image-5.9.0-1-librem5” which is the first package I downloaded and dpkg -l | grep linux showed it was already installed.

So I installed the file which in turn informs you that it will downgrade the linux-image-librem5 package…

sudo apt-get install ./linux-image-librem5_5.9.16+librem5.2_arm64.deb

…note the preceding “./” this is important and signals apt-get that it is installing from a local file.

After that I could remove the 5.11 kernel package…

sudo apt-get purge linux-image-5.11.0-1-librem5

…read the output of the above command very carefully before entering ‘Y’ to continue to make sure it is only removing the 5.11 kernel package, if there is any other package listed as to be removed you should probably enter ‘n’

After that, apt-cache policy linux-image-librem5 shows…

linux-image-librem5:
Installed: 5.9.16+librem5.2
Candidate: 5.11.4pureos1~amber1
Version table:
5.11.4pureos1~amber1 500
500 https://repo.pureos.net/pureos amber-phone main arm64 Packages
*** 5.9.16+librem5.2 100
100 /var/lib/dpkg/status

…which puts it back to pre-upgrade state, then all that remains is to hold it back so I don’t update inadvertently…

sudo apt-mark hold linux-image-librem5

5 Likes
12

This is a loaded statement. If it is in fact true, then you are a very rare exception. Or you never update your kernel.

But certainly, you’ve never before used an operating system being actively adapted for use on new, unfamiliar hardware. Everything pinephone is having similar growing pains.

Moral of the story, the statement you made ignores some very important context. It is unfair to disregard that context.

1 Like
13

At home 8 unique devices; hardware being quite different on each; 5 running Fedora, 3 Centos. Device age ranges from 2-12 years old. Last major issue I can recall was a kernel update breaking the network on one(which was at least 5 years ago, as that’s when that hardware was replaced). Systems update nightly and reboot if there’s a kernel update via cron. Upgrading to newer versions of the oses as needed (they’re all the latest at this time). Though not a huge sample size, I find it unlikely I am an exception.

It is true that I don’t have any hardware that is in active development. However, with a small number of devices being offered by purism; it shouldn’t be hard to validate the basics on each. It wouldn’t surprise me to see minor issues with functionality being introduced, but nothing critical path (like the wireless no longer working).

This doesn’t sound unreasonable to me, does this seem unreasonable for this device? Granted, I know purism is under a lot of pressure to deliver a lot at this time. So I guess I can give them some leeway. However, if this phone is truely intended to one day work for the average joe, updates really need to be solid.

1 Like
14

…and it’s being validated. So far we have just one report on degraded WiFi performance, which seems like some odd incompatibility and will have to be looked closer at. The other thing is a known regression that affects limited number of devices, but is easy to workaround (just toggle the killswitch after booting), so we decided to ship it anyway because there are significant stability improvements in other areas and lots of users had their problems fixed by the update. This discussion about testing isn’t very helpful.

4 Likes
15

Aaaaaannnnnd…now I also am having WiFi issues. After yesterday’s kernel upgrade, and after toggling the killswitch, everything was fine all day, even through a couple of power cycles. Now today, I don’t have WiFi, even with toggling the switch, multiple restarts, and the kernel forced downgrade.

I’ll see if WiFi returns at some point. In the meantime, I’m waiting for a USB-C-to-ethernet adapter to arrive so I can continue to get OS updates.

As an aside, is it unhelpful that WiFi (and Mobile) settings disappear from the menu under certain conditions? It seems to me that the settings should remain visible. Edit: And I do understand why it disappears.

nmcli general status
STATE: connecting
CONNECTIVITY: none
WIFI-HW: enabled
WIFI: enabled
WWAN-HW: enabled
WWAN: enabled

1 Like
16

I have seen that issue also, or at least I have seen an issue with the same symptoms, no amount of reboots or HKS toggling brought the card up.

To cut a long story short, removing the NetworkManger.state file then rebooting brought everything back to life in my case. The file gets recreated, I’m unsure if it’s during shutdown or boot up, either way it resolved my issue. It didn’t make much sense to me as the file had sensible values, the only thing I could think of is that perhaps recreating the file also triggers/resets something else.

To remove the file, from the terminal…
sudo rm /var/lib/NetworkManger/NetworkManger.state

If you want to view the file before removing (it’s only a few lines listing whether or not networking, wireless and mobile are enabled or not)…
sudo cat /var/lib/NetworkManger/NetworkManger.state

4 Likes
17

After the update to 5.11 my WiFi works better. Signal strength went from Poor to Good (not yet Excellent) so I am rather pleased. This is for 2.4 GHz from a TP-link C7 router with 20 MHz bandwidth.

1 Like
18

Thanks for that. I tried it, but it didn’t correct the issue for me (so far). Are you on 5.9 or 5.11 at the moment?

19

I just did a full restore in addition to reverting to 5.9, but it didn’t correct the problem. FYI.

20

I’m on the 5.9 kernel and it was when running the 5.9 kernel that I experienced the situation.

Are you leaving any amount of time when toggling the HKS? I have found, particularly with the WiFi/BT kill switch, that leaving it in the off/disabled position for at least 1 minute+ before re-enabling seems to give a better chance of the card coming up.

There are also a few outputs you can look at…

rfkill

If the card is seen it should produce some out similar to the following…

ID TYPE DEVICE SOFT HARD
0 bluetooth hci0 unblocked unblocked
1 wlan phy0 unblocked unblocked

You can also try check dmesg and journal for signs the card is being seen

sudo dmesg | grep redpine

and

sudo journalctl -b | grep redpine

If none of those produce any output then the card is just not being seen/recognised at all. If there is some output then you might need to dig through these logs to see if there are any clues as to why the card does not show up.

You can also check…

sudo journalctl -b | grep "state file"

Just to double check that the system thinks it should be enabled. You should something in the output along the lines of…

rfkill:wiFi enabled by radio killswitch; enabled by state file

That’s about as much as I can think of that’s worth checking.

2 Likes
21

Didn’t produce any output at all.

I see some “failed” and “disconnected” entries.

Same.

WiFI enabled by radio killswitch. WWAN enabled by radio killswitch. Networking enabled.

The indicator in the notifications tray shows disconnected. WiFI settings panel is still missing from general settings.