rfkill kills Wifi and bluetooth after having upgraded to Bullseye

[coldspark29]

When I boot the Pi, the Wifi symbol is greyed out and when I click on it, it says Wifi is disabled. I enable it and it works fine.

I can unblock everything with rfkill and everything is fine, but this is not a permanent solution.

What I've tried:

- Add unblock rfkill all to /etc/rc.local, ~/.xinitrc.
- Make a script unblock.sh with the same content and add it to /etc/init.d
- Purge rfkill (it is still active afterwards plus I can't unblock anymore

Any ideas how this could happen? I have to say that I not upgraded via dist-upgrade because of this error

Code: Select all

The following packages have unmet dependencies:
 libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6+rpi1 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

Maybe it is related

[pcmanbob]

Have you set your location and wifi location in raspi-config ?

until it been set wifi and possibly bluetooth will be blocked.

[coldspark29]

Yes, everything is set. I set both again to make sure.

[dajhorn]

I can confirm this bug on a Raspberry Pi 3 Model B Revision 1.2. The rfkill in bullseye is broken and doesn't automatically unblock the bluetooth and wifi interfaces, even if the country code is properly set by raspi-config.

[pingu2311]

I had the same problem. Removing of connman fixed it for me.

Code: Select all

apt purge connman

[mahjongg]

bullseye is not yet released for the RPI, and updating to it is risky, and for your own risk,
have the patience to wait for the official release!

[dz3jar]

Hi guys!

It doesn't seem to be fixed in the released Bullseye version. Still the same - wifi blocked after reboot and working fine just after manually unblocking wireless interfaces.

Or is there something I do not know?

Best Regards,
Jan

Code: Select all

pi@Zero:~ $ cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=CZ

network={
        ssid="yyyyyyyyyyyyyyyy"
        psk="xxxxxxxxxxxxxxxx"
}

pi@Zero:~ $ cat /sys/module/rfkill/parameters/default_state
1

pi@Zero:~ $ rfkill
ID TYPE      DEVICE    SOFT      HARD
 0 wlan      phy0   blocked unblocked
 1 bluetooth hci0   blocked unblocked
 
pi@Zero:~ $ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 23  bytes 2396 (2.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 23  bytes 2396 (2.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@Zero:~ $ rfkill unblock all

pi@Zero:~ $ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        ...

wlan0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500
        inet 10.10.10.10  netmask 255.255.0.0  broadcast 10.0.255.255
        inet6 fe80::2acc:5255:750b:41e1  prefixlen 64  scopeid 0x20<link>
        ...

[klricks]

It doesn't seem to be fixed in the released Bullseye version. Still the same - wifi blocked after reboot and working fine just after manually unblocking wireless interfaces.

Or is there something I do not know?

....

There is not yet an officially released version of 'Bullseye' for the RPi......

For some reason WIFI gets disabled each boot. Very annoying when I mostly use VNC to connect.
As a temporary workaround add the command below to the autostart file: /etc/xdg/lxsession/LXDE-pi/autostart

Code: Select all

rfkill unblock 0

This will auto enable WIFI each boot.

[rpdom]

I don't run a desktop, but have two Pi Zero Ws running Bullseye on WiFi with no problems. Both fully updated.

[crashtest]

This worked for me:

I added the following 2 statements, in the following order, to the end of the line of /boot/cmdline.txt

systemd.restore_state=0 rfkill.default_state=1

reboot

[m4p5]

The only trick that work in my case for bluetooth and wifi is the command :
sudo apt purge connman

[derekk19]

I had the same problem. I installed bullseye on a RPi 3 which was working happily running buster. I've already installed bullseye on a number of RPI 4s with no issues. I run all my Pis headless, using ssh to access them. They are also all wireless and connect to the same SSID. The difference with the Pi 3 is that I had installed a full desktop OS (even though I run this Pi headless), but on my Pi 4s I had installed the OS Lite version (also the others are Pi 4s and this is a Pi 3 Model b Rev 1.2).

I did not run apt dist-upgrade and did not run rpi-update on any of my Pis when upgrading to busllseye. I don't know how relevant that is.

When the Pi 3 booted it would not haver a wireless connection so I would don't be able to access it. I had to connect a screen and keyboard then login and rfkill unblock wlan0, then the wireless network came up. Just running ifconfig wlan0 up was not enough - I would get a message that the wireless was disabled. I also checked I had the country code - which I did. If I ran raspi-config and set the country code to its current value then the wireless network would come up when I exited raspi-config (as long as I didn't reboot after leaving raspy-config). Someone elsewhere suggested changing the position of the country code line in the wpa-supplicant config file, but I didn't find that made any difference.

Like a previous commenter, I have just removed connman (apt purge connman) and now my Pi3 is happy. I can reboot and the wireless network comes up correctly. I get messages about no bluetooth, but I ignore these since I am not worried about bluetooth on this Pi.

I'm thinking the issue is with the desktop OS, and maybe if I run a Lite OS then I won't have problems. I'll get another SD card in the coming few days and try that. I'd also thought of junking my Pi 3 and replacing with a Pi 4, but that's a bit extreme. Alternatively there is a difference between rfkill on the Pi 4 and Pi 3. I don't know enough about the OS differences to figure that out.

PS. After typing this message out, I checked another of my Pis (yes, I have 9 or ten in total). It is also a Pi3 and I updated that to Bullseye a few days earlier. No problems at all. It is running a Lite OS, so it's looking like the desktop OS is the thing I need two focus on.

Maybe this will help others with the same problem
Derek

[klricks]

....

Like a previous commenter, I have just removed connman (apt purge connman) and now my Pi3 is happy. I can reboot and the wireless network comes up correctly. I get messages about no bluetooth, but I ignore these since I am not worried about bluetooth on this Pi.

.....

Did you download and install an official 'Bullseye' RPi OS release or did you upgrade from an existing 'Buster' install?
I installed official recommended desktop (not full) and connman was not installed by default.

[ScotsDon]

For the record really, I used ConnMan to turn on my wifi, which fixed the issue.

After installing Bullseye from Buster (on a pi-3), my problem was similar to the above comments in that on booting, wifi was disabled.

I tried turning it on using rfkill, but this only worked until a reboot, when wifi became off again.

I found ConnMan Settings under the Start Menu / Preferences / Connman Settings. Under the Wireless setting, I switched wifi on, which then stayed on after reboots or restarts. Problem hopefully solved.

One issue I note is that ConnMan says my wifi is "not connected" even though it is. The Wired tab however says "Connected" when an ethernet cable is plugged in, and also shows IP addresses etc. The Wireless tab does not.

[Schorschi]

Not sure if I have the same issue, but have Pi 3 fresh install of Bullseye, setup wifi correctly via wpa_supplicant configuration, and I see the wlan0 interface, but not associated. Configured that SSID and passphrase in raspi-config setup, wpa_supplicant conf correct.

And rfkill shows no blocking...
# cat /sys/module/rfkill/parameters/default_state
1
# rfkill
ID TYPE DEVICE SOFT HARD
0 wlan phy0 unblocked unblocked
1 bluetooth hci0 unblocked unblocked

# dhcpcd
wlan0 waiting for carrier
<>
timeout

# iwconfig
wlan0 IEEE 802.11 ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on

Any ideas?

[pettefar]

I've upgraded three RPi 4s to Bullseye so far and each one had the NumLock forced on at boot and RFkill stopped WiFi working despite anything I did. This is really disappointing. So is the appalling Raspbian distribution upgrade malarkey we're forced to go through each time. The Raspbian crowd should be ashamed of themselves for putting their users through this awful experience. No wonder Linux is the least used desktop OS! The suggestion of backing up and doing a clean install each time is such a cop-out and pathetic.

To get around the NumLock problem I have had to apt install numlockx and put a "/usr/bin/numlockx off" line in .profile. Terrible!

To get around the rfKill problem had to apt purge connman. Also terrible.

Come on Raspbian people, get your act together and mature this OS.

Nick

[pcmanbob]

Come on Raspbian people, get your act together and mature this OS.

Nick

It has never been recommended to do an up from one release of the the OS to another, because they have no way on knowing what is installed on your OS and how configured.

The recommendation has always been to do a fresh install.

With a major upgrade, we recommend downloading a new image, reinstalling any applications, and moving your data across from your current image. Debian major version upgrades contain a lot of changes, and it is very easy for some small tweak made somewhere in the system to be incompatible with some change you have made, and you can end up with a broken system and a Raspberry Pi that won’t boot. The easiest way to create a new SD card is with the Raspberry Pi Imager tool available here, or you can download the new image from here and use a tool like Etcher to flash it to a new SD card.

If you really want to try upgrading an existing image, there are some instructions on the forums here – but we don’t support or recommend this, so be warned: you are on your own if anything breaks

ref...https://www.raspberrypi.com/news/raspbe ... -bullseye/

[bjtheone]

I've upgraded three RPi 4s to Bullseye so far and each one had the NumLock forced on at boot and RFkill stopped WiFi working despite anything I did. This is really disappointing. So is the appalling Raspbian distribution upgrade malarkey we're forced to go through each time. The Raspbian crowd should be ashamed of themselves for putting their users through this awful experience. No wonder Linux is the least used desktop OS! The suggestion of backing up and doing a clean install each time is such a cop-out and pathetic.

Microsoft cannot even roll out monthly/quarterly updates without borking systems, let alone full version updates, but somehow Debian and RPT is supposed to rollout major release upgrades that apply seamlessly to your tweaked install?

Methinks your expectations are slightly unrealistic.

Options are:

* deal with it, lots of folks have successfully upgraded and there is an update process that seems fairly successful (the closer you are to a default install, the more likely it will just work)
* stay on Buster until things settle out
* go down the recommended path, build a fresh SD card with Bullseye, and copy your user data across

As I am (mostly) past the "oh new/shiney" stage, I am happily staying on Buster until the Calibre/qt issues get sorted on Bullseye.

[miladloveboth]

hello guys that is a very simple solution for "disabled wifi by rfkill at boot in raspberry pi"
based on my search i figure it
when connmanctl are used so "rfkill unblock all" didnt work anymore for perment and wifi disabled after reboot so
to fix it this problem and turn wifi at boot do it at terminal:

Code: Select all

sudo connmanctl enable wifi

enjoy!

[JuliaClement]

I was also having this problem, now resolved.

rfkill would enable my wifi but then forget it across reboots.

After a little exploring, I discovered that /var/lib/systemd/rfkill had two files named platform-[...].mmcnr:wlan, one with a zero & one with a 1. I deleted them & re-ran rfkill. One file reappeared with a zero in it & wifi worked on boot up.

I hope this is of use to others