Member Avatar for Stephen_46

Recently I installed Arch Linux on a laptop with a dead battery. It must be plugged in at all times for it to work. My plan was to keep it plugged in.

I did not realize that rfkill exists to prevent the wifi from using the last bit of battery power in the event it runs very low on a laptop.

I can't prove it here, but I have got the WPA2-PSK to work. The system sees it, but there is a hard block from rfkill on it. Again, probably because it sees that the battery is out of power.

Using "lsmod": iwldvm -> iwlwifi -> cfg80211 -> rfkill.

Is there a way to stop iwlwifi from calling rfkill? Or can I fool the system into ignoring that it is a laptop or that the battery is dead?

  • 2 Contributors
  • 5 Replies
  • 299 Views
  • 4 Hours Discussion Span
  • Latest Post Latest Post by rproffitt

Dani AI

Generated

Short diagnosis and a practical path forward based on ’s notes (Wi‑Fi worked from the installer but is hard‑blocked at boot) and ’s fallback idea (USB/Wired): a hard block is normally asserted by a platform/ACPI/WMI kernel driver (acer_wmi, ideapad_laptop, hp_wmi, asus_nb_wmi, etc.), not by the Intel wireless firmware itself. That means the wireless firmware/driver will be present but the hardware rfkill bit is held by the platform driver because the EC/ACPI reports a missing/empty battery.

Identify the producer of the hard block and relevant kernel driver:

for r in /sys/class/rfkill/*; do
  echo "== $r =="
  cat "$r"/name
  readlink -f "$r"/device
done

udevadm info -a -p /sys/class/rfkill/rfkill0 | egrep 'DRIVERS|SUBSYSTEM'
dmesg | grep -iE 'rfkill|wmi|acer|ideapad|hp_wmi|asus|thinkpad'

If the offending module is a removable kernel module, test by unloading it (temporary):

sudo modprobe -r <suspect_module>

If that clears the hard block, prevent it loading at boot by blacklisting (example):

# /etc/modprobe.d/blacklist-platform-rfkill.conf
blacklist acer_wmi

On Arch, regenerate initramfs if the module was baked into the initramfs:

sudo mkinitcpio -P

Notes and cautions: blacklisting platform drivers can disable hotkeys, special buttons or other power features. If the driver is built into the kernel (not modular) the blacklist won’t work without rebuilding the kernel. When in doubt, the simplest safe fallbacks are a USB network adapter or wired ethernet (as suggested). Checking the steps above will narrow the true cause so a minimal, targeted change can be made instead of guessing at firmware behavior.

Recommended Answers

All 5 Replies

Member Avatar for Stephen_46

Ok, I should at least tell you that I am using iwd. The passphrase and PSK are in the /var/lib/iwd/*.psk. They are being used at boot up.

Soft block is off, only hard block is on. RF- Kill can't revoke a hard block, it must be fixed by recharging the battery. Normally a good precaution, but in this case I would like to use the laptop without a battery.

Edited by Stephen_46
Member Avatar for rproffitt

I'm reading https://bbs.archlinux.org/viewtopic.php?id=236715 which appears to be the solution. Remember that I'm not able to duplicate your issue because I chose to fix broken things.

For specific Arch Linux issues my choice would be to ask in Arch Linux forums but hopefully this prior discussion will fix it for you. Yes, it's not simple enough a fix for many but hey, Linux.

Member Avatar for Stephen_46 
rfkill unblock all

will not work.

I have been so focused on getting wifi to work, I forgot about the ethernet cable option. I accept that I got wifi working except for the module that won't let it work with a dead battery. The reason I know the wifi does work besides the commands that I used that I forgot that revealed that it is working, is that I could connect with wifi only with the installation media using the recommended iwctl. The module iwlwifi turns it off at boot via rfkill.

Member Avatar for rproffitt

Then my fix is to plug in some USB WiFi. We get such for 10ish USD here. Or we tell the user to try other distros.

Be sure to ask in this Distro's own forum.

Member Avatar for rproffitt

PS. I want to write about how much control we have at startup in Linux via the usual startup scripts located in the /etc/rc.

For most, that's a no-go since few want to tinker there. I can't tell you what to change since I'm just a long time Linux user, coder and such. For the office we fix bad laptops since such workarounds are too costly in terms of time. We can make more money doing almost anything else. I feel for you but to fix this you get to ask and hope in the Arch forums or dive into the scripts that run at startup in /etc/rc.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.