Audit & remove Intel x86_64 binaries migrated to michael-air

Status Closed — not planned
Maintainer reply None cached
Activity 1 comment · opened Aug 15, 2026 · closed Aug 18, 2026

Problem

Apple's Migration Assistant blindly copied Intel (x86_64) binaries to the ARM MacBook Air (M3) without warning or info. These binaries are incompatible and cause failures — but only when you try to use them.

Related issue: #6 (michael-pro water damage / michael-air recovery)

What We've Found So Far

1. Intel Homebrew tree (/usr/local/Homebrew)

  • Location: /usr/local/Cellar, /usr/local/Caskroom, /usr/local/Homebrew
  • Symptom: brew command fails with Bad CPU type in executable
  • Problem: Contains Intel-only bundled Ruby; entire tree unusable
  • Solution: Inventory, remove, reinstall native ARM packages under /opt/homebrew

2. Intel login shell (/usr/local/bin/bash)

  • Location: Set in chsh as login shell
  • Symptom: Terminal.app fails to launch; clean shells work fine
  • Problem: Shell is Intel executable; Rosetta unavailable during early boot
  • Solution: chsh -s /bin/zsh (immediate); link to /opt/homebrew/bin/bash post-Homebrew rebuild

Strategies to Find More

Strategy 1: Find all non-ARM binaries

# Find x86_64 executables in common locations
find /usr/local -type f -executable 2>/dev/null | xargs file | grep x86_64
find /opt -type f -executable 2>/dev/null | xargs file | grep x86_64
find ~/.local -type f -executable 2>/dev/null | xargs file | grep x86_64
find ~/bin -type f -executable 2>/dev/null | xargs file | grep x86_64

# Check installed binaries
file /usr/local/bin/* 2>/dev/null | grep x86_64
file /usr/local/opt/*/bin/* 2>/dev/null | grep x86_64

Strategy 2: Check PATH directories for architecture mismatches

# For each directory in PATH, check what's there
echo $PATH | tr ':' '\n' | while read dir; do
  [ -d "$dir" ] && echo "=== $dir ===" && file "$dir"/* 2>/dev/null | grep -v "ASCII\|directory" | grep -c x86_64
done

# Specifically check Python/Ruby/Node paths
which python3 && file $(which python3)
which ruby && file $(which ruby)
which node && file $(which node)

Strategy 3: Check package managers

# MacPorts (if it exists)
ls -la /opt/local/bin/* 2>/dev/null | head -5 && file /opt/local/bin/* | grep x86_64

# Ruby gems
gem list --local 2>/dev/null | head
# Then check specific gems for native extensions
ls ~/.gem/ruby/*/gems/*/lib/*/x86_64* 2>/dev/null

# Python site-packages
python3 -c "import site; print(site.getsitepackages())"
find ~/.local/lib/python*/site-packages -name "*.so" -o -name "*.pyd" 2>/dev/null | xargs file | grep x86_64

Strategy 4: Check cached build artifacts

# Xcode derived data (may contain Intel builds)
du -sh ~/Library/Developer/Xcode/DerivedData
find ~/Library/Developer/Xcode/DerivedData -type f -executable | xargs file 2>/dev/null | grep x86_64

# Cargo (Rust)
ls -la ~/.cargo/bin/* | file | grep x86_64

# Go binaries
file ~/go/bin/* 2>/dev/null | grep x86_64

Strategy 5: Check system-level locations (requires sudo)

# System package managers
sudo find /Library/Caches -name "*.o" -o -name "*.a" 2>/dev/null | xargs file | grep x86_64
sudo find /var/cache -type f -executable 2>/dev/null | xargs file | grep x86_64

# Old app plugins/extensions
sudo find /Library/ScriptingAdditions -type f 2>/dev/null | xargs file | grep x86_64
sudo find /Library/InputMethods -type f 2>/dev/null | xargs file | grep x86_64
sudo find /Library/LaunchAgents /Library/LaunchDaemons -type f 2>/dev/null | xargs file | grep x86_64

Strategy 6: Check ~/Library for app-specific Intel bits

# App support bundles
find ~/Library/Application\ Support -type f -executable 2>/dev/null | xargs file | grep x86_64

# Application Scripts
find ~/Library/Application\ Scripts -type f -executable 2>/dev/null | xargs file | grep x86_64

# Caches (may contain old compiled extensions)
find ~/Library/Caches -type f -executable 2>/dev/null | xargs file | grep x86_64

Strategy 7: Check third-party app bundles

# Inside .app bundles
find /Applications -type f -executable 2>/dev/null | xargs file 2>/dev/null | grep x86_64 | head -20

Exploration Playbook

  1. Run Strategy 1 first — Get full inventory of x86_64 binaries
  2. Categorize by location/usr/local (Homebrew), ~/.local (user), /opt (optional), system dirs
  3. Identify by owner — Which package manager/app installed each?
  4. Record before deleting — Document what was found + location
  5. Test each removal — Remove one category, verify system still works
  6. Automate post-rebuild — Once native Homebrew/Python/Node installed, generate exclusion rules for future Time Machine backups

What Should NOT Be Deleted Without Investigation

  • /Library/Caches — May contain compiled indexes (system-critical)
  • /Library/Extensions — Kernel extensions (probably none on modern macOS, but check)
  • /System/Library/* — System binaries (should never be x86_64 if Migration worked)
  • Third-party app bundles in /Applications — May be universal; check before deleting

Open Questions

  • How many x86_64 binaries did Apple migrate?
  • Are there directories we haven't thought of?
  • Should we generate a whitelist of "known-safe-to-delete" categories?
  • Can we automate this detection as part of post-migration setup?

Next Steps

  • [ ] Run full x86_64 audit (all strategies)
  • [ ] Categorize findings by impact/regeneration cost
  • [ ] Test removal of low-risk categories (Homebrew bottles cache, pip cache)
  • [ ] Document safe removal order
  • [ ] Add x86_64 binary search to michael-air setup checklist
  • [ ] Consider automation for future ARM Mac migrations

---

This issue should stay OPEN — it's a tracking issue for the entire cleanup cycle, not a single fix.

Relates to: #6

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗