Guide: Omarchy on the Dell XPS 13 9343 — Wi-Fi, Bluetooth, BIOS and TPM

[kinggs]

Guide: Omarchy on the Dell XPS 13 9343 — Wi-Fi, Bluetooth, BIOS and TPM

This records the hardware-specific work needed to get Omarchy running smoothly on one Dell XPS 13 9343. The exact PCI and USB IDs matter more than the marketing model because Dell sold this laptop with different wireless cards.

Tested machine

• Model: Dell XPS 13 9343
• BIOS: A20, dated 2019-06-06
• Wi-Fi: Broadcom BCM4352 802.11ac [14e4:43b1], Dell subsystem [1028:0019]
• Bluetooth: Broadcom BCM20702A1 USB device [0a5c:216f]
• Current Omarchy: 4.0.3
• Current kernel: 7.2.3-arch1-3

Wi-Fi: unavailable after the original installation

The in-kernel Broadcom drivers did not provide a usable interface for this BCM4352. The first working state was achieved offline by carrying the matching Arch broadcom-wl package in on removable media and installing it with pacman -U. Only after that could the laptop get online and complete a normal system update.

Arch has since replaced the prebuilt broadcom-wl package with broadcom-wl-dkms. A durable current installation needs both the DKMS driver and headers matching the installed kernel:

omarchy pkg add broadcom-wl-dkms linux-headers

Before rebooting after any kernel update, verify that the module was built for the new kernel. Do not assume that installing the DKMS package means its build succeeded:

pacman -Q linux linux-headers broadcom-wl-dkms
dkms status

The linux and linux-headers package versions should match, and dkms status should report the Broadcom module installed for that kernel.

We learned this the painful way: changing from broadcom-wl to broadcom-wl-dkms while updating the kernel, without installing matching headers, left the next boot without Wi-Fi. An attempted unattended rollback also failed because broadcom-wl conflicted with the installed DKMS package and pacman --noconfirm selected the safe default of not removing it. Offline recovery required explicitly removing broadcom-wl-dkms before reinstalling the known-good kernel and matching prebuilt driver.

Omarchy already has an offline Broadcom hardware setup and caches broadcom-wl-dkms plus linux-headers in the ISO, but its detector did not include this BCM4352 PCI ID. PR #11655 adds 14e4:43b1 with regression coverage. This should provision the installed target before first boot. It does not necessarily make the adapter work in the already-running live ISO; USB phone tethering or Ethernet remains a useful installer fallback.

Bluetooth: missing BCM20702A1 firmware

The Bluetooth half of the combo card appears as USB device [0a5c:216f]. BlueZ and btusb alone are insufficient when this firmware file is absent:

/usr/lib/firmware/brcm/BCM20702A1-0a5c-216f.hcd

The working machine has that 35,080-byte firmware file and loads the controller through btusb/btbcm. The ArchWiki's Dell XPS 13 (9343) page recommends installing the AUR broadcom-bt-firmware package, or extracting and converting the firmware from Dell's Windows driver. A packaged installation is preferable to an unmanaged file because ownership and future replacement remain traceable.

After installing the firmware, reboot and check:

lsusb | grep -i '0a5c:216f'
journalctl -b -k | grep -iE 'Bluetooth|BCM20702|firmware'
bluetoothctl show

BIOS: update to A20

The laptop started on BIOS A09. Dell's final BIOS release for this model is A20. Updating improved the firmware baseline but did not resolve every old ACPI or TPM quirk.

The Dell firmware updater could not initially browse the USB drive even though it was FAT32. The drive also needed an MBR partition type compatible with firmware browsing (0x0c, FAT32 LBA); it had retained type 0x07. With a FAT32 partition, type 0x0c, and Dell's 9343_A20.exe copied to it, the F12 BIOS Flash Update utility could select and apply the update.

Keep AC power connected, do not interrupt the flash, and verify the download against Dell's published checksum before using it. Preserve the existing AHCI and Secure Boot settings unless intentionally changing the installation's boot configuration.

TPM: firmware-owned state that could not be cleared

After the BIOS update, systemd's TPM provisioning services failed with TPM response 0x000009a2, an authorization failure. Inspection showed owner, endorsement, and lockout authorization set, with disableClear also set. This installation has no TPM token enrolled in LUKS and /etc/crypttab does not configure TPM unlocking, so the condition does not prevent booting or change the existing passphrase-based disk encryption.

The BIOS exposed no ordinary TPM-clear control. Both standards-based physical-presence requests were then tried with physical confirmation during reboot:

• PPI operation 5: Clear
• PPI operation 14: Clear, enable and activate

The firmware reported BIOS Failure for both and left the TPM state unchanged. Further authorization attempts were stopped rather than risking lockout or destructive experimentation. On this particular machine the practical result is four noisy systemd TPM service failures for features that are not configured or used.

Do not copy TPM-clear commands casually: clearing a TPM can destroy keys used by disk unlocking, measured boot, authentication, VPNs or other applications. First inventory every TPM-bound feature and keep independent recovery keys. The failure described here appears to be Dell firmware/TPM state, not an Omarchy defect.

What now works

• Omarchy boots normally on BIOS A20.
• Wi-Fi works with broadcom-wl-dkms built for the installed kernel.
• Bluetooth works once the exact BCM20702A1 firmware is present.
• Storage, Btrfs, memory and battery checks showed no critical faults.
• The old TPM state remains unresolved but is not used by this installation.

Reports from other XPS 13 9343 machines are welcome, especially machines with different wireless hardware or a TPM that successfully clears under A20.

[kinggs]

Update: automatic pre-reboot Wi-Fi verification

I added a reversible Omarchy post-update hook for machines that depend on broadcom-wl-dkms:

https://gist.github.com/kinggs/162992d60ff912b33c24fe3e5814abfd

After Omarchy updates the system packages and runs migrations—but before it offers to reboot—the hook checks:

• the installed linux and linux-headers package versions match;
• broadcom-wl-dkms is installed;
• DKMS reports broadcom-wl installed for the newly installed kernel;
• the new kernel's wl module file exists; and
• the module's vermagic matches that kernel.

It deliberately derives the target from the installed linux package rather than uname -r, because before reboot uname still reports the old running kernel.

Install it with:

gh gist clone 162992d60ff912b33c24fe3e5814abfd ~/wifi-update-safety
omarchy hook install post-update ~/wifi-update-safety/wifi-update-check.sh

Run it manually at any time with:

~/.config/omarchy/hooks/post-update.d/wifi-update-check.sh

The most recent report is written to:

~/.local/state/omarchy/wifi-update-check.txt

A healthy result says SAFE TO REBOOT. Any failed invariant produces a critical DO NOT REBOOT notification and a report naming the mismatch. Omarchy reports a failed hook but continues the already-completed update, leaving the current session available for repair.

Removal is intentionally simple and does not touch the driver, kernel, packages, or network configuration:

~/wifi-update-safety/remove-wifi-update-check.sh

This checker is intentionally specific to the stock Arch linux/linux-headers packages and broadcom-wl-dkms; users of linux-lts, Zen, or another kernel need to adapt the package names.

[kinggs]

Update: clean custom-ISO install succeeded on physical hardware

The custom ISO built from PR #11655 at commit 5264ca9b4c659a15be166f4712d9aa0a1bfe1fd1 was tested on the Dell XPS 13 9343 with BCM4352 [14e4:43b1].

Wi-Fi was available after the clean installation and is connected using wl. On the current installed kernel, linux and linux-headers match at 7.2.4.arch1-2; broadcom-wl-dkms 6.30.223.271-49 is installed; DKMS reports the module installed for 7.2.4-arch1-2; and lspci -nnk reports Kernel driver in use: wl.

This supplies the physical-hardware confirmation that the VM harness could not provide. After a later normal Omarchy update, the runtime package became omarchy-dev 4.0.0.r2128.gb679363-1, so its packaged hardware script is back to the current upstream version pending merge. The Wi-Fi packages installed by the custom ISO remain healthy and working.

Bluetooth still needs the separate BCM20702A1 firmware described in the guide: the expected BCM20702A1-0a5c-216f.hcd file is absent, and the kernel reports that it cannot find either matching firmware filename. I’ll handle that separately now that the clean Wi-Fi evidence has been preserved.