Cassie

The firewall is the other half and it is invisible if you only compare versions, because it fails silently in one direction.

Question 3 is the interesting one: nothing complained because at install time nothing was wrong.

A package manager downloading an Intel build onto a machine that can run Intel builds has no reason to object. Rosetta means Intel binaries do work. The failure only appears at the moment two things of different architectures have to occupy the same process, which can be weeks later and in a completely unrelated command.

The usual origins, in rough order:

• A migrated environment. Migration Assistant copies the Intel binaries across faithfully. They ran fine on the old machine and they still run - until something native tries to load one.
• A virtual environment carried over in a project folder, or restored from a lock file that pins built wheels.
• A terminal running under Rosetta, as above.
• Two Homebrews, which is its own thread.

The cleanest fix for a migrated setup is unsentimental: delete and rebuild the environment on the new machine rather than repairing it. It is faster than it sounds and it ends the whole category.

Question 3 is usually one of two things, and both are invisible if you only compare versions.

The Windows firewall. A service listening on Windows is subject to the firewall, and the virtual adapter is frequently classified as a Public network. Plenty of database installers add an allow rule for Private only. Same software, same version, different network profile - and the laptop is more likely to have been on a coffee shop network and had its profile changed.

What the service is bound to. Something listening on 127.0.0.1 is reachable only from Windows itself, and no amount of addressing from the distro will reach it, because it is refusing connections from anything that is not local. Something listening on 0.0.0.0 accepts them.

Check the second one first, on Windows, netstat -ano | findstr <port> shows the bind address. If it says 127.0.0.1, that is your laptop's difference and it is a one-line config change.

One more candidate for "something else has the extensions", since it is invisible and increasingly common: Memory Integrity, under Core Isolation in Windows Security.

It uses virtualisation-based security, which means the hypervisor is running whether you asked for it or not. On a machine where somebody disabled Hyper-V to make VirtualBox work and it still failed, this is usually why.

Worth knowing before disabling it: it is a genuine security feature and turning it off to speed up a VM is a real trade, not a free win. Check whether VirtualBox on top of the hypervisor is fast enough first.

There is no application to look for because it is a system component, but it does leave something on disk. The check most people use:

/usr/bin/pgrep -q oahd && echo "installed" || echo "not installed"

oahd is the translation daemon, and it runs when Rosetta is present. The other common check is whether /Library/Apple/usr/share/rosetta exists.

To install it deliberately rather than through a prompt:

softwareupdate --install-rosetta --agree-to-license

Worth knowing that the click-through prompt and that command install exactly the same thing, so if you clicked the prompt, you have it. There is no partial state to worry about, which is the reassuring answer to what state your machine is in.

The Command Line Tools are a separate package with its own version, tied to the SDK it shipped with. A macOS update does not update them, because they are not part of the OS: they sit alongside it. So after a major update you have new system headers and an old toolchain that was built against the previous ones, and Homebrew, which compiles things, is the first thing to notice.

It keeps coming back because that is the shape of the problem, not a bug you can fix once.

The reliable repair is a clean reinstall rather than an update:

sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install

Removing first matters. Running the install over the top of a mismatched copy frequently reports success and leaves the old headers in place, which is why the fix sometimes appears not to work.

After that:

xcode-select -p
brew doctor