### System details

- MacBook Air 13-inch Early 2015 (`MacBookAir7,2`)
- Broadcom BCM4360 802.11ac, PCI ID `14e4:43a0`, Apple subsystem `106b:0117`
- Omarchy Quattro `4.0.2`
- Update: `7.1.9-arch1-2` → `7.2.2-arch1-1`
- NetworkManager `1.58.1-1` using the iwd backend
- Before the update: `broadcom-wl 6.30.223.271-722`
- Current Arch DKMS package tested: `broadcom-wl-dkms 6.30.223.271-48`

### What's wrong?

After a normal Omarchy update and reboot, this MacBook came back with no Wi-Fi device and no network list. The native network panel still opened and showed its DNS controls, but there were no SSIDs to select. Since this is the machine's only physical network interface, it also became unreachable remotely.

The package transaction upgraded the kernel and headers, but did not upgrade or replace the kernel-specific Broadcom module:

```text
[2026-08-31T09:46:39-0300] upgraded linux (7.1.9.arch1-2 -> 7.2.2.arch1-1)
[2026-08-31T09:46:50-0300] upgraded linux-headers (7.1.9.arch1-2 -> 7.2.2.arch1-1)
[2026-08-31T09:46:56-0300] upgraded omarchy-settings (4.0.1-1 -> 4.0.2-1)
[2026-08-31T09:47:00-0300] upgraded omarchy (4.0.1-1 -> 4.0.2-1)
```

`broadcom-wl` remained at `6.30.223.271-722`, with its module only under the old kernel tree. After reboot:

```text
$ uname -r
7.2.2-arch1-1

$ sudo modprobe wl
modprobe: FATAL: Module wl not found in directory /lib/modules/7.2.2-arch1-1
```

At the time of diagnosis, `pacman -Si broadcom-wl` returned no repository package. Omarchy's current [`fix-bcm43xx.sh`](https://github.com/omacom/omarchy/blob/b686ed892d9c3020c3336203f6d34cc75b544e2b/install/hardware/fix-bcm43xx.sh) explicitly selects `broadcom-wl` for this PCI ID, while also installing `dkms` separately. The `broadcom-wl` package itself is kernel-specific and is not converted into a DKMS module merely by installing `dkms`.

#### Reproduction

1. Start with a working BCM4360 (`14e4:43a0`) system on kernel `7.1.9` and `broadcom-wl 6.30.223.271-722`.
2. Apply the normal update that installs kernel and headers `7.2.2`.
3. Reboot.
4. The `wl` module is absent for the running kernel, so NetworkManager has no usable Wi-Fi device.

#### Switching to DKMS currently fails too

I booted the pre-update Limine snapshot to regain connectivity, mounted the normal root, replaced `broadcom-wl` with the current `broadcom-wl-dkms`, and tried to build it for `7.2.2-arch1-1`. The unmodified package fails because Linux 7.2 removed `strncpy()` from the kernel API:

```text
DKMS make.log for broadcom-wl/6.30.223.271, kernel 7.2.2-arch1-1

src/shared/linux_osl.c:863:17: error: implicit declaration of function 'strncpy'
src/wl/sys/wl_linux.c:1542:9: error: implicit declaration of function 'strncpy'

make: *** [Makefile:248: __sub-make] Error 2
```

This is the same Linux 7.2 API break documented in [Debian bug #1144895](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1144895) and the accompanying [tested patch report](https://mail-archive.com/debian-bugs-dist%40lists.debian.org/msg2117381.html). The kernel-side removal is upstream commit [`079a028`](https://kernel.googlesource.com/pub/scm/linux/kernel/git/kees/linux/+/079a028d6327e68cfa5d38b36123637b321c19a7).

#### Verified recovery

I applied the conditional Linux 7.2 replacements from that patch (`strscpy`, `strscpy_pad`, and `memcpy`) to the DKMS source, then rebuilt:

```text
Building module(s)..... done.
Installing /usr/lib/modules/7.2.2-arch1-1/updates/dkms/wl.ko.zst
Running depmod...... done.

$ modinfo -k 7.2.2-arch1-1 wl
filename: /lib/modules/7.2.2-arch1-1/updates/dkms/wl.ko.zst
vermagic: 7.2.2-arch1-1 SMP preempt mod_unload
```

After rebooting the normal updated root:

```text
$ uname -r
7.2.2-arch1-1

$ lspci -nnk -s 03:00.0
03:00.0 Network controller: Broadcom BCM4360 [14e4:43a0]
        Subsystem: Apple Inc. Device [106b:0117]
        Kernel driver in use: wl

$ nmcli device status
DEVICE  TYPE  STATE      CONNECTION
wlan0   wifi  connected  <redacted>
```

Wi-Fi scanning, routing, public DNS, overlay-network DNS, and remote connectivity all remained healthy after the reboot. This confirms the missing/incompatible module was causal rather than a NetworkManager, iwd, DNS, or VPN configuration problem.

#### Expected behavior

An Omarchy update should not allow a reboot into a kernel for which a required, hardware-gated out-of-tree module is missing or failed to build.

For BCM4360 systems, a safe fix could combine:

- using a `broadcom-wl-dkms` source package carrying the Linux 7.2 compatibility patch;
- checking `modinfo -k "$new_kernel" wl` before offering/requiring a reboot;
- surfacing a clear blocking warning if the required DKMS build failed; and
- retaining the pre-update kernel or an LTS fallback until the module is verified.

This is related to, but different from, [#8810](https://github.com/omacom/omarchy/issues/8810): BCM4350 can use `brcmfmac`, whereas BCM4360 `14e4:43a0` is intentionally assigned to `wl` by Omarchy and has no equivalent in-kernel fallback. Existing BCM4360 reports [#5398](https://github.com/omacom/omarchy/issues/5398) and [discussion #6401](https://github.com/omacom/omarchy/discussions/6401) concern runtime instability after the module loads, not this Linux 7.2 build/upgrade failure.

The pre-update snapshot made recovery possible, consistent with Omarchy's [system snapshot documentation](https://github.com/omacom/omarchy/blob/quattro/manual/47-system-snapshots.md). I can test an update guard or packaged driver patch on this machine.

Suggested triage labels: `bug`, `mac`, `intel macs`, `device specific`.