On 28.08.21 15:38, Charlie wrote:
From my keyboard:
Hello all,
Since Bullseye went stable, updated on my 12 month old HP
laptop. When attempting to bring up the wireless interface with
ifup.
The message on the screen tells me the "network is down", which is
incorrect. Because on another Bullseye machine it works perfectly. as
it did on this one before it went stable.
It gives the message:
RTNETLINK answers: Operation not possible due to RF-kill
Then tries to connect for about 12 or so tries.
I have not installed rfkill, and can't find it to uninstall it.
On the web there is a reference to this "RTNETLINK answers: Operation
not possible due to RF-kill" on Archlinux where it was solved by
bringing the BIOS back to default. I tried that, but temporarily locked
myself out of the system. Then asking me to install an operating system
on the hard drive. I brought that back buy returning the BIOS to when
it booted the system.
I can use the Ethernet port and cable to connect to the internet with
that machine, however, did connect wirelessly when Bullseye was testing.
Any pointers would be appreciated.
TIA,
Charlie
East Gippsland Wildlife Rehabilitators Inc..
http://www.egwildlife.com.au/
Temporary workaround:When I have had such problem in the past and also no rfkill installed, I simply installed rfkill (and for my use case created an alias for the CLI and shortcut for the GUI for reactivating WiFi and Bluetooth easily, if they would be blocked again). This does not explain where the problem comes from, but installing and using rfkill is not a big thing and quickly gets you out of trouble and up and working again. In my case, if I remember at least a little bit the case, it was the graphical desktop environment which deactivated the wireless devices upon shutdown, but then was not able to reactivate them at system start, letting the devices stay blocked, obviously having used some rfkill alike implementation in the GUI code itself. Since I installed the rfkill package and reactivated the devices manually at the CLI the problem disappeared somehow. I do not remember anymore if the problem disappeared instantely or after some few rounds of shutdown and reboot with manual rfkill intervention, or simply because maybe around that time also a GUI update arrived. I still assume that it was a bug in the GUI code, using maybe some internal rfkill alike code, but being buggy, having the feature to deactivate those devices working correctly but failing to reactivate them. As I quickly couldn't reproduce the problem no more, I could not provide a bug report. I did not even test what would happen if I now would remove the rfkill package again. Installation and usage of that package solved my problem first hand as a workaround, and then the problem anyway disappeared shortly after, and eventually I decided to simply keep rfkill installed.
--- Good Luck! Marco.