Achhina's Digital Garden

2026-08-08 Dead Intel Kexts and Flash Remnants

5 min read

2026-08-08 Dead Intel Kexts and Flash Remnants

What I set out to do

Having finished the CloudStorage cleanup in 2026-08-08 The Dead Mounts Were Never Mounted, asked whether other cleanups of the same species were sitting around. Not “what is big” but “what is orphaned”.

What I actually did

Audited the categories that could plausibly hold orphans: File Provider domains, ~/Library/CloudStorage, LaunchAgents pointing at missing binaries, Login Items via sfltool dumpbtm, iCloud containers, and Application Support.

Most came back clean. All File Provider domains resolve to live roots, CloudStorage has a single active entry, and no user LaunchAgent points at a missing binary. The find came from Login Items, which listed haxm_start.sh and fpsaud.

Both traced to genuinely dead software. Every third-party kext in /Library/Extensions turned out to be x86_64-only and unloaded on an arm64 machine: intelhaxm (Intel’s VT-x accelerator, meaningless on Apple Silicon), HighPointRR, HighPointIOP, and SoftRAID. Alongside them, com.intel.haxm.plist and com.adobe.fpsaud.plist in LaunchDaemons, the latter being Adobe’s Flash updater for software EOL since 2020-12-31 and already marked disallowed by macOS. Plus an empty Library/Application Support/Macromedia.

Removed all nine paths under a backup-first script: refuse if any kext is loaded, tar to ~/Downloads, verify the archive with gzip -t before deleting anything, boot out the daemons, remove, verify. /Library/Extensions is now empty. Total space was about 4MB, so the point was removing stale boot-time entries and kext attack surface, not disk.

Ran it via TouchID sudo. sudo -n failed, but /etc/pam.d/sudo has pam_tid.so (plus Homebrew’s pam_reattach for tmux), so a foreground sudo prompted for a fingerprint instead of a password and went through.

What was striking

The audit’s most useful output was a non-finding I nearly got wrong in the opposite direction. ~/Library/Mobile Documents holds containers for apps not installed on this Mac: Notability (129M), Procreate brushes (44M), Daylio, MindNode. They pattern-match perfectly to the orphans just cleaned, and they are the one thing here that must not be touched, because they are live iCloud containers and deleting locally propagates to the iPhone and iPad. “Looks exactly like the thing you just deleted” is not evidence, and this session had already produced one near-miss on unique Notability data.

The tail repeated the session’s motif a fourth time. Files gone, launchctl print reporting both labels unregistered, and yet sfltool dumpbtm still listing both with Executable Path values that no longer exist. BTM caches records past the deletion of what they describe, exactly as Drive’s metadata DB cached a trashed folder. Clears on reboot. The tempting fix, sfltool resetbtm, wipes every background-item approval on the machine, which is far more damage than a stale row in a settings pane.

Also worth noting the sfltool dumpbtm output had been the worked example in my own notes on why Login Items shows sh for Home Manager agents, citing haxm_start.sh specifically. Deleting the example meant updating that note so it does not read as broken later.

Postscript: these were leftovers from a migration marked complete

Traced back to MacBook M4 2025 Migration, closed 2026-04-27 claiming “0 Intel-only apps” and “100% native arm64 applications”. Its verification was find /usr/local -name "*x86_64*", scoped to the Intel Homebrew prefix, so /Library/Extensions and /Library/LaunchDaemons were never examined. Nothing caught it at runtime either, because a wrong-architecture kext does not error, it just never loads. Added a follow-up section to that project note correcting the scope of the claim.

The transferable rule: verify an architecture migration by enumerating architecture across the filesystem (file on the real binaries), not by proving absence inside one package manager’s prefix. A clean result from a search that could not have covered the target is the same null-without-a-control failure that ran through the whole day.

Second batch, and I committed the same error myself

Widening past kexts turned up six more, about 63M: PepperFlashPlayer (50M), LogiGamingAudio.driver (11M, x86_64), Flash Player.prefPane, OSXFUSE.framework, MSTeamsAudioDevice.driver (Teams not installed), and an orphaned Office licensing helper. OSXFUSE.framework still carried ppc7400 and ppc64 slices, so it predated the Intel machine, and Phase 7 of the migration note claims osxfuse was removed.

The uncomfortable part is how the first five were missed an hour earlier. My Flash check had been:

ls -d /Library/PreferencePanes/Flash*.prefPane /Library/Internet\ Plug-Ins/Flash* 2>/dev/null

zsh nomatch on the second glob aborted the whole command, 2>/dev/null ate the error, and I read the empty output as “no Flash remnants”. Fifty megabytes of Flash was sitting there the entire time, under a directory I had named in the command. The plugin is called PepperFlashPlayer, so the Flash* prefix would have missed it regardless.

Then I did it a second time in the same session, with ls -d /Applications/*eams*.app ... aborting on nomatch and printing “none matched”, which I nearly reported as “Teams is not installed”. Only re-running through find with a control (45 bundles present) made the answer trustworthy — and the answer happened to be the same, which is precisely why the near-miss is worth recording. Being right by luck after a broken check is indistinguishable from being right, until it isn’t.

Four separate instances in one day of a null result treated as a finding: the mistyped-space find, the Drive API “not found”, the WAL-blind sqlite reads, and these two globs. The pattern is not carelessness about any single command. It is that a quiet command reads as a negative one, and shell tooling is full of ways to be quiet for reasons unrelated to the question asked.

Graph View

Backlinks