Post not yet marked as solved
Yes that warning is standard practice for HomeBrew during a macOS βeta. Shortly before or when Sonoma is released it will be supported.
Post not yet marked as solved
If you are using any network content filters like Little Snitch, LuLu, etc. this is a known issue. Disabling the content filter is the only solution to restore normal network connectivity at the moment until Apple resolves the issue.
Post not yet marked as solved
Same here. Successfully updated from Beta 4 to Beta 6.
Post not yet marked as solved
Same upgrade from ßeta 4 to ßeta 5 issue here on a M1 Mac mini external TB SSD drive. Even trying to update the external TB SSD using the full ßeta 5 installer from my internal SSD ended in failure. I guess unless Apple releases an updated ßeta 5 installer we can only hope the issue is fixed in ßeta 6. I did submit a Feedback report.
Post not yet marked as solved
You can enable it using the menubar control center.
Post not yet marked as solved
Unfortunately the installers are protected by the System Integrity Protection (SIP ) system. To delete the installers boot your Mac into Recovery mode (CMD-R) and open the terminal application from the menubar and execute the following command to disable SIP.
csrutil disable
Restart your Mac. You should be able to delete the installers. After you delete the installers boot back into Recovery mode (CMD-R), open the terminal application again and execute the following command to re-enable SIP.
csrutil enable
Restart your Mac and enjoy.
Post not yet marked as solved
Your machine probably shipped with a "newer" variant of macOS Catalina due to newer hardware which Big Sur updater does not yet recognize. Wait until the Big Sur beta catches up.. probably in the next beta release.
Post not yet marked as solved
The solution by user "esaruoho" is correct except step 3 should be "csrutil disable" and step 12 should be "csrutil enable". I fortunately had made a clone of my Mojave boot disk 4 days before some update screwed up my MobileDevice framework. Fortunately I had not yet updated the clone version on that disk.
Post not yet marked as solved
That folder tree was probably moved to "/Users/Shared/Relocated Items" as part of the migration process. A "Relocated Items" folder alias to that location should have been created on your Desktop during migration. A PDF in that folder explaining the contents resides inside that folder along with items that were relocated. The recloated items folder exists in part to the changes which came with macOS 10.15 Catalina with the introduction of a read-only root volume for the OS.There is a process you can use to restore that directory tree to the 10.15 root folder by creating a symbolic link in root directory using the synthetic command (see man synthetic.conf). For a better explaination and how to see Creating root-level directories and symbolic links on macOS Catalina
Post not yet marked as solved
If you reinstall your 16" using the Recovery Mode, Option-Command-R, option at boot you will install a different build of the current released version of Catinlina that was factory installed which is compatible with the 16" HW. See https://eclecticlight.co/2019/09/27/which-recovery-mode/ for additional info.The forked version includes support for the 16" differences in HW as well as the 10.15.1 supplemental update. See https://mrmacintosh.com/2019-16-macbook-pro-catalina-10-15-1-supplemental-update-19b2106/
Post not yet marked as solved
Not unusal for new released HW. Apple will need to release an updated beta to include 16" support. I suspect a new beta will be released sometime this coming week with 16" support.
Post not yet marked as solved
The 19A536g update apparently did not contain an updated com.apple.photolibraryd.plist file. Move back the com.apple.photolibraryd.plist file from the "move to" folder. The files "diif" to be the same. Again, the move back will need to be performed while booted in Recovery mode, e.g. CMD-R. Ensure the file owner and group is "root:wheel" and the ownership permissions are 0644, e.g. -rw-r--r--.19A536g resolves the original freeze issue.
Post not yet marked as solved
Not sure I understand. Did you implement the workaround as stated? I've logged 2 days, 20:42 so far using my workaround without one freeze. I'm able to type my password in the lock screen from either after the screensaver kicks in or if the computer is sleeping to unlock my account.
Post not yet marked as solved
MaksPlus based on my experimental diagnosis I believe you are correct in that the photoslibraryd daemon appears to cause some interaction with the system after a period of user inactivity. I've been able to stop the freezing from occuring by moving aside the com.apple.photolibraryd.plist located the the /System/Library/LaunchAgents folder located on the boot volume. The moving aside of the plist file needs to be done under Recovery Mode using the terminal app. To accomplish the move I created a new folder called "LaunchAgents (Disabled)" and used the "mv" command to move the plist file from the LaunchAgents folder to my "LaunchAgents (Disabled)" folder. I then rebooted, logged in and observed the system did not freeze while runnning the screensaver for more than one hours time. To verify my conclusion and repeatability I moved back the plist file to the LaunchAgents folder once again using Recovery Mode and rebooted to allow the daemon to start again at boot. After logging in and letting my screensaver start I observed a hard system freeze once again on my MacBook Pro 2015 after a few minutes. I'm not interesting in using the photos app at this time so disabling the daemon is of no consequence for me. I would rather have a stable system I can do my testing on. This seems to be a weird issue to say the lease ... Let's hope it's resolved in the next beta!Created feedback FB6917382 documenting the findings and workaround.
Post not yet marked as solved
Same here on my Macbook Pro 2015 (12,1) 13".
