You don’t have a USB stick to use as a live OS?
Asked another way, @just-some-fern, does your WiFi have some sort of hardware switch, which you might have accidentally flicked off?
I believe it’s an internal card since it’s PCIe. And a hardware switch that allows the device to listen to the traffic but not allow it to connect to a network sounds a bit weird to me.
But it appears that it can’t actually listen, since it can’t find any networks. Could this be related to Windows fast boot or whatever the name? I’m thinking that shutting down Windows with that mode still enabled might have “primed” the WiFi to come back up quickly at the next start; but only the same Windows can actually get it out of that state; or a UEFI reset and disablement of said mode.
I just found an old thread from 2018 from a guy that had a similar issue back then.
The issue was kernel / driver related and he solved it with a fresh install.
https://forum.ubuntu-fr.org/viewtopic.php?id=2032896 (it’s in french tho)
I use windows but i’m not that familiar with that type of issue. But from what I heard, i’m not sure it can be that deep. Have you heard about issues like that?
At the beginning, OP said:
I assumed from that sentence that it could find networks. Isn’t that the case @just-some-fern ?
I’ve just remembered that I had this weird issue that after a reboot my WiFi wouldn’t come back up when it was soft blocked on shutdown. Let’s see if I can still piece together what I did.
I found that I had to do something like:
nmcli radio wifi on
rfkill and nmcli radio don’t always seem to agree.
It was related to some quirk, how TLP saves that state. There are also some kernel command line parameters for that, rfkill.master_switch_mode=2 and rfkill.default_state=1. I don’t know which, but one of the two was required until I eventually understood the issue. I think master_switch_mode=1 could be the issue here, because if the “last state” was “off”, then what? ![]()
Oh, and then there is systemctl status rfkill.service which seems to be the default way of saving the state of the soft switches.
Kind of, it seems for about a minute after I reboot the system it can find my home network, and it appears like it’s connected sometimes (despite not being a functional connection, I’ve tested), but soon it reverts to the state of the screenshot above: Wifi marked unavailable and no networks can be found.
I’m still a linux beginner in many ways so I’m not too sure what to do with most of that information
sorry, but here are the outputs from those commands:
nmcli radio
WIFI-HW WIFI WWAN-HW WWAN
enabled enabled missing enabled
nmcli radio wifi
enabled
Looks like some power management interference, perhaps. Does it help to reload the module?
sudo modprobe -r rt2800pci && sudo modprobe rt2800pci
In that case, rebooting would have solved the issue right?
Yes, as it seems to do, for a certain period of time at least.
Does not seem to make any difference
Ok, let’s see what the log says right after reloading the module:
journalctl -kb --tail
and
journalctl -b -u NetworkManager --tail
Oh, and let’s try turning it off and on again:
nmcli radio wifi off && sleep 5 && nmcli radio wifi on
journalctl -kb --tail
journalctl: unrecognized option ‘–tail’
Got the same for journalctl -b -u NetworkManager --tail
Try -f instead of --tail (It will keep scrolling on new content)
Or -r to just reverse it and show the recent ones first
Alright for journalctl -kb -f:
journalctl -kb -f
May 18 19:29:26 pingus kernel: ieee80211 phy2: rt2800pci_set_device_state: Error - Device failed to enter state 4 (-5)
May 18 19:29:28 pingus kernel: ieee80211 phy2: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0x0000006a]
May 18 19:29:29 pingus kernel: ieee80211 phy2: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0x0000006a]
May 18 19:29:29 pingus kernel: ieee80211 phy2: rt2800pci_set_device_state: Error - Device failed to enter state 4 (-5)
May 18 19:29:54 pingus kernel: ieee80211 phy2: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0x0000006a]
May 18 19:29:55 pingus kernel: ieee80211 phy2: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0x0000006a]
May 18 19:29:55 pingus kernel: ieee80211 phy2: rt2800pci_set_device_state: Error - Device failed to enter state 4 (-5)
May 18 19:29:56 pingus kernel: ieee80211 phy2: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0x0000006a]
May 18 19:29:57 pingus kernel: ieee80211 phy2: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0x0000006a]
May 18 19:29:57 pingus kernel: ieee80211 phy2: rt2800pci_set_device_state: Error - Device failed to enter state 4 (-5)
^C
and for journalctl -b -u NetworkManager -f:
journalctl -b -u NetworkManager -f
May 18 19:29:26 pingus NetworkManager[1558]: [1779157766.9649] manager: rfkill: Wi-Fi now enabled by radio killswitch
May 18 19:29:29 pingus NetworkManager[1558]: [1779157769.1786] platform-linux: do-change-link[5]: failure 5 (Input/output error)
May 18 19:29:52 pingus NetworkManager[1558]: [1779157792.2074] manager: rfkill: Wi-Fi hardware radio set disabled
May 18 19:29:52 pingus NetworkManager[1558]: [1779157792.2079] audit: op=“radio-control” arg=“wireless-enabled:off” pid=3771 uid=1000 result=“success”
May 18 19:29:52 pingus NetworkManager[1558]: [1779157792.2193] manager: rfkill: Wi-Fi now disabled by radio killswitch
May 18 19:29:53 pingus NetworkManager[1558]: [1779157793.3742] manager: rfkill: Wi-Fi hardware radio set enabled
May 18 19:29:55 pingus NetworkManager[1558]: [1779157795.5815] platform-linux: do-change-link[5]: failure 5 (Input/output error)
May 18 19:29:55 pingus NetworkManager[1558]: [1779157795.5819] audit: op=“radio-control” arg=“wireless-enabled:on” pid=3771 uid=1000 result=“success”
May 18 19:29:55 pingus NetworkManager[1558]: [1779157795.5830] manager: rfkill: Wi-Fi now enabled by radio killswitch
May 18 19:29:57 pingus NetworkManager[1558]: [1779157797.8025] platform-linux: do-change-link[5]: failure 5 (Input/output error)
That’s only one or the wrong “dash” -; --tail is a “long name” option, which require a double-dash. This could be Discourse being a tad too clever again.