When trying to update from beta 2 to beta 3 and from beta 3 to the revised beta 3 build, softwareupdate failed at the personalization step. This was because a USB-C accessory passed through to a VM via Virtualization.framework was holding the USB-C controller. This blocked I²C access to the AppleTypeCRetimer chip during the preflight personalization phase. In the unified log, this appears as: AppleTypeCRetimerIICDeviceHandle readRegister: Read result 0xe00002d5 AppleHPMLibRT13Interface: HPM is NOT in ADFU, modeData=0x20505041 [SPI] MSUParsedToleratedFailureForStep | step:update_usbcretimer → FAILURE MSUPreflightUpdate | FAILURE → "failed to copy firmware identity" 0xe00002d5 = IOKit I²C device not responding 0x20505041 = "APP " — HPM stuck in application mode, can't enter ADFU (firmware update mode) Without retimer firmware identity, the SFR installer can't complete personalization I was able to work around this by physically unplugging the passed through device (which is suboptimal for a headless server in a rack). Feedback ID: FB23772773 Hardware: Mac16,9 (Apple Silicon) Update: macOS 27 Beta 3 (26A5378j → 26A5378n), full OTA via Software Update Failure: SUMacControllerErrorPreflightPersonalizeFailed (7723) → MSU_ERR_PERSONALIZATION_FAILURE (2) → "failed to copy firmware identity" (1259)

Hi, I wanted to develop a small tool to launch Home Assistant OS in a Virtualization.framework VM. Something lean (no UI, no daemons), zero-config, and Apple Silicon only. I got that running, but I wanted to also use bridge networking and USB device pass-through which require the com.apple.vm.networking and com.apple.developer.accessory-access.usb entitlements, respectively. I was unable to use those for local development using ad-hoc signing, so I guess it requires a paid Apple Developer account and official approval so that they can be enabled in provisioning profiles. I'm open to reactivating my developer subscription which I let expire years ago, but wanted to first assess the chances of getting approval (no point in renewing the subscription if I won't get the permission in the end). I could make this an open source project, if it helps.

I'm using a Mac Studio in a homelab context and use Homebrew to manage the installed services. The services include things that access the local network, for example Prometheus which monitors some other servers, a reverse proxy which fronts other web services on the network, and a DNS server which can use another as upstream. Local Network Access permissions make it impossible to reliably perform unattended updates of services because an updated binary requires a GUI login to grant local network permissions (again). I use brew services to manage the services as launchd agents, i.e. they run in a non-root GUI context. I know that I can also use sudo brew services which instead installs the services as launchd daemons, but running services as root has negative security implication and generally doesn't look like a good idea to me. If only there was a way to disable local network access checks altogether…