Purism could beta test updates with a group of users who are game to go along. Specify the functions to run, and let those who want run a few pet functions of their own. Even a one-day test could save a lot of people a lot of time. (Maybe they do already.)
Most wouldn’t volunteer but surely some diehards would.
You can implement that yourself by not installing updates on the first day they appear
I actually do this, not purely with that intention, but sometimes also due to laziness
I’d suggest looking at the logs around the area of the “failed” and “disconnected” entries to see if they relate to the card and hopefully they’ll give some more detail as why it’s failed and been disconnected.
You can dump the whole lot to a text file then use a text editor to search through it. That is probably the easiest way as unfortunately the pager/more on the phone is either a little broken or not yet fully implemented as it only goes forward and search doesn’t work.
To dump the whole lot to a file…
sudo journalctl -xb > nowifi.log
That will produce a nowifi.log file in the current directory (the ‘x’ option just adds a little more detail to each entry where available), you can then open that in a text editor and search for terms like “redpine”, “failed”, “disconnected” etc…
You can do the same with dmesg but but you’re more likely to get more detail out of journalctl. To dump dmesg to a file…
All updates go through an incubation period in amber-phone-staging repository, which usually is 7 days long. Rest assured that this has been tested by several people on multiple devices (and I’m using 5.11 kernels myself since December).
It doesn’t look related to the update then. Have you tried turning the phone off to cool down? Some users reported that WiFi doesn’t always show up for them after toggling a killswitch or rebooting when the phone is warm.
I must tell that I usually have my phone off (to save battery time) so it is pretty cool. Usually I have WiFi up and connected within 30 seconds after switching the phone on. That is fairly stable now. The C7 router is about three meters away behind a wooden wall and the signal strength is Good (all this with 5.11). I have very few apps installed.
Even after sitting overnight with power off, the WiFi hasn’t come back. I’ll see what happens with the ethernet adapter that is arriving today. Maybe there are some updates waiting that will affect WiFi.
P.S. The saved backup I restored to was from a week ago, before the WiFi issue started, just for info.
There seems to be some regression in 5.11 at least, I just experienced something similar. (Wifi not being available on boot that is, not performance degradation - though I haven’t tested wifi performance yet.)
Happened after upgrading the kernel package from 5.9 to 5.11; that was the only package with upgrades available when I checked this morning. Rebooted several times, and each time I had to flip the hardware kill switch off and on before the wifi card would become available. Switched back to the 5.9 kernel and rebooted, wifi came up immediately on boot.
In the last couple days I haven’t been able to get Wifi to turn on at all. 5.9 vs 5.11 doesn’t seem to matter. Rebooting and toggling the switch doesn’t matter. The UI acts like the wifi switch is off reguardless of where it is, although looking at the logs seems to indicate that it’s seeing the wifi hardware.
I would think that if the logs detail the presence of the WiFi card, then the logs probably also have some details and results of the system attempting to bring the card up, loading firmware, initialiing etc,?