User Profile

At boot, a TCG-standard Opal self-encrypting drive can present a preboot program for authentication and then unlock itself and continue the boot sequence. By specification, for security it will automatically lock itself when reset, for instance whenever power is lost. This allows booting off a secure external USB drive. Unfortunately, starting with macOS Monterey, during the boot sequence, the OS is reseting the USB tree in such a way that the very drive being booted from is locked. Without connecting instruments and just looking at the LEDs, it appears that the USB tree power may perhaps be being cycled off and on, a pretty hard reset. One could consider performing a hard reset on the drive hosting the file system with the kernel etc during boot to be a probabilistic bug. Is there a way to tame this behavior? Anything from naming the particular USB device to be protected, to a flag setting for just not doing this to the USB tree all? Help?

I have a daemon and agent running at startup. The daemon broadcasts a Bonjour service, the client agent attaches to a localhost socket, all is good.Or at least it was until recently. Under High Sierra, all this happens before the WiFi network connection is complete, and when that finishes, it breaks the socket connection between the daemon and its client(s). I have coded a workaround to restart the Bonjour browser, which then re-finds the daemon, reconnects, etc. This in turn causes a bit of UI turmoil, which does settle down after the workaround, and is also just a transient on bootup. I point at WiFi startup because the timing is coincident and I do not see the behavior if I boot up with WiFi turned off. If I then turn it on, same problem -- the socket connection is blown away, and my workaround fixes it. The "UI turmoil" is a bit difficult to suppress since the client agent has no good way to distinguish this from a legitimate daemon-gone-away event such as can happen when connecting to a daemon on a different _tcp._local. server.I would like to know if it is possible to keep the WiFi processing from resetting the network stack.I consider it a bug that an innocent socket connection to localhost would get blown away by whatever is happening on the rest of the network.MacBook Pro, macOS High Sierra (10.13), MacBook Pro (13-inch, Early 2011)