If your Broadcom wireless card stopped working after an Ubuntu upgrade and lshw -C network reports it as UNCLAIMED, the most likely cause is that the bcmwl driver package has blacklisted the kernel modules (bcma and friends) that the card needs. The fix is to edit the generated blacklist file /etc/modprobe.d/blacklist-bcm43.conf and comment out the offending lines — despite the warning inside the file, your edits survive reboots.
What the upgrade actually broke
Older Mac minis and similar machines commonly ship with a Broadcom BCM4331 wireless controller. Linux supports this chip through the in-kernel b43 driver working together with the bcma bus module. However, Ubuntu also ships the proprietary Broadcom STA driver (the bcmwl-kernel-source package), which cannot coexist with those open drivers. To prevent conflicts, the bcmwl package installs a file, /etc/modprobe.d/blacklist-bcm43.conf, that blocks bcma, b43, and several related modules from loading.
During a release upgrade, the driver situation can change: the STA driver may fail to build against the new kernel, or the upgrade may leave the blacklist file in place while no longer providing a working replacement driver. The result is a wireless card that the kernel can see but cannot claim — no driver is bound to the PCI device, so no wlan0/wlp2s0 interface ever appears.
Confirming the diagnosis
Two commands tell you almost everything you need:
sudo lshw -C network
Look for the Network controller entry. If it says UNCLAIMED and shows no driver= in its configuration line, the kernel has no driver bound to the card. Wired Ethernet entries that show a driver (for example driver=tg3) are fine.
lspci -nnk | grep -A3 -i net
For your wireless device, check two lines:
- Kernel driver in use: if this line is missing entirely, no driver claimed the device.
- Kernel modules: this lists modules that could handle the device. Seeing
bcmahere means support exists in the kernel — it is simply being prevented from loading.
If bcma appears as an available module but no driver is in use, check the modprobe blacklist rules:
grep -r bcma /etc/modprobe.d/
Finding blacklist bcma in blacklist-bcm43.conf confirms the cause.
Fix one: re-enable the open-source driver
The blacklist file carries a warning that it is regenerated automatically and that manual edits are pointless. In practice, that regeneration does not reliably wipe manual changes, so editing the file works. Open it:
sudo nano /etc/modprobe.d/blacklist-bcm43.conf
Comment out the lines blocking the modules you need, typically:
# blacklist bcma
# blacklist b43
Then rebuild the module dependency list and reload the driver:
sudo update-initramfs -u
sudo modprobe -r wl 2>/dev/null
sudo modprobe bcma
sudo modprobe b43
The b43 driver needs firmware, which Ubuntu provides in the firmware-b43-installer package. If the card still does not come up after the modules load, install it:
sudo apt install firmware-b43-installer
Then reboot. NetworkManager should detect the wireless interface once the driver and firmware are both present.
Fix two: make the proprietary driver work instead
If you prefer the STA driver that created the blacklist in the first place, make sure it is actually installed and built for the current kernel:
sudo apt install bcmwl-kernel-source
sudo modprobe wl
This path makes sense when the package was lost or broken during the upgrade. Be aware of the trade-offs: the STA driver is proprietary, is not always built promptly for brand-new kernels, and requires the blacklist file to keep the open drivers out of the way. If the package installs cleanly and modprobe wl succeeds, your card will work — but on very new kernels the build sometimes fails, which pushes you back to the open-source route.
Preventing this on future upgrades
Before starting a release upgrade, note which driver your Wi-Fi uses:
lspci -nnk | grep -A3 -i net
Save that output. After the upgrade, compare it: if the "Kernel driver in use" line has disappeared for the wireless device, you know immediately that a driver-binding problem occurred, and you can check /etc/modprobe.d/ before troubleshooting anything else. Keeping a wired connection (or a USB Wi-Fi dongle) available during upgrades also makes recovery far easier, since you can install firmware and driver packages without any network.
Frequently Asked Questions
The blacklist file says my edits will be overwritten. Is that true?
Not reliably. The file is generated when the bcmwl package is installed or reconfigured, but routine reboots do not restore it from a template. Users have verified that commenting out lines in the file persists across reboots. The safe approach is to test after editing and, if the file is ever regenerated, reapply your change.
Why does the kernel list bcma as a module but not use it?
lspci -nnk shows all modules that declare support for the device's PCI ID. A blacklist rule in /etc/modprobe.d/ tells the kernel never to auto-load that module, so support exists but is deliberately suppressed. Removing the blacklist lets the module load and claim the device.
Should I just delete blacklist-bcm43.conf?
You can, but commenting out the specific lines is safer. If you later reinstall or reconfigure the bcmwl package, it will recreate the file anyway, and keeping the file makes it obvious where the rules live if the problem ever returns.
How do I tell whether I need b43 or the STA driver for my card?
Check your chip's PCI ID with lspci -nn. Chips like the BCM4331 (14e4:4331) work with the open-source b43 driver plus firmware. The STA driver supports a partially overlapping set of chips, so if one route fails, check the other's supported-device list before assuming the hardware is dead.
My card works after loading the modules but shows no networks. What now?
That usually means the driver loaded but its firmware is missing. Install the matching firmware package (firmware-b43-installer for b43), reboot, and check dmesg | grep -i firmware for messages about failed firmware loads.
Will this problem recur with every Ubuntu upgrade?
It can, whenever the upgrade reconfigures the bcmwl package or changes which driver stack is active. Keeping a note of your working driver configuration — and checking lspci -nnk after each upgrade — turns a multi-hour mystery into a two-minute fix.