Wi-Fi gone or dropping after a kernel update (iwlwifi, mt7921, brcmfmac)

Your machine updated, rebooted, and now there is no Wi-Fi at all, or it connects and falls over every few minutes. This page covers the case where a kernel or firmware change is the trigger. It was checked against 4.0.4 (2026-09-15), with notes where 3.x behaves differently.

The fix

1. Find out what broke. Run these before changing anything:

uname -r
nmcli device status
rfkill list wifi
lspci -nnk | grep -A3 -i 'network\|wireless'
journalctl -k -b | grep -iE 'iwlwifi|mt7921|brcmfmac|rtw89|firmware'

Three outcomes matter. No wifi row in nmcli device status and no Kernel driver in use line from lspci means the driver never loaded. A driver line plus failed with error -2 in the log means the firmware blob is missing. A device that appears and then drops means the driver loaded but cannot hold the link.

2. Get a network back first. Everything below needs packages. At the Limine menu, stop the countdown and arrow down to your previous kernel entry, usually linux. Since 4.0.4, migration 1789325478.sh installs linux-omarchy and puts it first in BOOT_ORDER, but it does not remove the kernel you were running, so that entry is still in the menu. If no entry boots with Wi-Fi, use a pre-update snapshot entry, plug in Ethernet, or tether a phone over USB.

3. If the driver is out of tree, fix the headers and rebuild. This is the common one on Broadcom Macs and on any machine that carried broadcom-wl, rtl8821ce, nvidia or similar. List what is installed, then install headers to match:

dkms status
pacman -Qoq /usr/lib/modules/*/vmlinuz
sudo pacman -S --needed dkms linux-headers linux-omarchy-headers
sudo dkms autoinstall

Trim that pacman -S line to the -headers packages matching kernels the previous command actually printed. The dkms autoinstall at the end is not optional: the DKMS pacman hook only fires while a package is being installed or upgraded, and a build it skipped for lack of headers is never picked up again. Installing the headers afterwards, on its own, leaves the module missing.

On 4.0.2 and earlier, install/hardware/fix-bcm43xx.sh asked for broadcom-wl, which Arch stopped building for Linux 7.2. Release 4.0.3 switched that to broadcom-wl-dkms. If you are still holding the old package:

sudo pacman -R broadcom-wl
sudo pacman -S broadcom-wl-dkms
sudo dkms autoinstall

4. If the log shows a firmware load error, update firmware, not the driver. An error -2 is a missing file:

sudo pacman -S --needed linux-firmware linux-firmware-intel

Substitute your vendor’s split package, for example linux-firmware-mediatek or linux-firmware-marvell. Reboot and read the log again. If the machine has no network at all, copy the package files over on a USB stick from another machine and install them offline with sudo pacman -U ./<file>.pkg.tar.zst, which is what issue #6551 did on a Dell XPS 13 with an Intel BE213.

5. If new firmware broke a card that used to work, downgrade only that package. In issue #1829 an Asus Vivobook with an MT7921 lost Wi-Fi after an update. The reporter recovered by downgrading both the kernel and linux-firmware-mediatek; a later comment traced it to an upstream firmware bug and narrowed the downgrade to linux-firmware-mediatek alone, and the 20251011-1 build was reported working. Add the pinned package to IgnorePkg in /etc/pacman.conf while you wait, then remove the pin.

6. If the new kernel itself is the regression, stay on the old one. Edit /etc/default/limine, put your working kernel first in BOOT_ORDER, and run sudo limine-mkinitcpio. The steps and the exact syntax are in kernel panic after update. This is the shape of discussion #3053 on 3.x, where iwlwifi stopped working on 6.17.2 and later and the reporter went back to 6.17.1.

7. If the radio is simply blocked, run Update > Hardware > Wi-Fi from the Omarchy menu. That is omarchy-restart-wifi, which does rfkill unblock wifi, turns NetworkManager’s radio back on, and rescans.

Verify it worked

uname -r
dkms status
nmcli device status
journalctl -k -b | grep -i 'loaded firmware version'

dkms status should list your module as installed against the running kernel, not only an older one. nmcli device status should show a wifi device in state connected. For an out-of-tree Broadcom module, modinfo wl | grep filename should point into /lib/modules/$(uname -r)/updates/dkms/. Then reboot once more and check again, because the first boot after a rebuild is the one that proves the module survives.

Why it happens

Kernel modules live under /usr/lib/modules/<version>, so every kernel update needs its own copy of anything out of tree. DKMS rebuilds those during the package transaction, and only if headers for that exact kernel are present. omarchy-update calls pacman -Syu --noconfirm, and the DKMS hook’s Missing kernel headers for module line is not fatal to the transaction, so the update finishes green with a module that was never built. You find out at the next boot when there is no Wi-Fi. That is the sequence in issue #10975 on 4.0.3 and, with a kernel-specific broadcom-wl instead of a skipped DKMS build, in issue #9386 on a BCM4360 MacBook Air.

Firmware is separate again. It ships in linux-firmware and its per-vendor split packages, versioned on their own schedule. A newer driver can ask for a ucode revision your firmware package does not carry yet, which is the no suitable firmware found! case, and newer firmware can break a driver that was fine, which is the MediaTek case.

Two things changed in 4.x. Quattro replaced iwd with NetworkManager and wpa_supplicant, so a post-upgrade outage may be lost profiles rather than a dead radio. And 4.0.4 installs linux-omarchy and makes it the first boot entry on every x86_64 machine that is not a T2 Mac, so an update can hand you a different kernel even when the stock linux package did not move.

If that did not work

If Wi-Fi only dies after sleep, this is not your page. Issue #8461 describes iwlwifi failing to reinitialize after wake with repeated -110 timeouts; see suspend will not resume and Bluetooth stops after resume.

If the link is up but unusable, with high jitter rather than low throughput, check roaming. Issue #7311 traced constant reassociation on an MT7922 to wpa_supplicant electing a 6 GHz radio it could not hold, fixed by pinning the band. Omarchy has a command for that, documented in the manual’s Networking chapter:

omarchy network band
omarchy network band 5

Intel BE200 and BE211 cards get an EHT workaround from Omarchy at install time, written to /etc/modprobe.d/iwlwifi-disable-eht.conf. If you have one of those cards and the file is missing, rerunning hardware detection with sudo omarchy-apply-hardware --install-user $USER reapplies the quirks.

If the machine upgraded from 3.x and every saved network vanished, the profiles are still in /var/lib/iwd as root, one file per SSID.

Evidence on the Omarchy kernel specifically is still thin. It reached everyone on 2026-09-15, one day before this page was checked, so treat reports about it as early.

Related

• Kernel panic after an update
• Suspend will not resume
• Wi-Fi hardware notes
• Before you update checklist
• Rollback with Snapper and Limine
• Releases and channels