Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
^^^ Yes, that’s true, of course: I just didn’t expect this to be visible at the user level (see the partially missing TCC prompts)…

Hence, the warning. Those options are meant for advance-level users (or, Hackintosh users). It would be quite redundant (and useless) if Dortania will make one just for newbies. If you've read his instructions, or the walkthroughs of Mr Macintosh for basic installation, you won't see them tinkering with those options even if they are there.
 
^^^ But I didn’t tinker at all with those options: I simply tried two different configurations, knowing that it is only the Kepler dGPU that requires root patching (for example, a MacBook Pro 11,1, which doesn’t have the dGPU, will have SIP fully enabled with OCLP); thus discovering that with the stock root patched - no tinkering! - Monterey on the MacBook Pro 11,3, TCC doesn’t fully work as expected (with missing prompts for accessing files and folders). So, my question was simply if it would be possible for the OCLP developers to “fix” this, or not…
 
  • Like
Reactions: TimothyR734
^^^ But I didn’t tinker at all with those options: I simply tried two different configurations, knowing that it is only the Kepler dGPU that requires root patching (for example, a MacBook Pro 11,1, which doesn’t have the dGPU, will have SIP fully enabled with OCLP); thus discovering that with the stock root patched - no tinkering! - Monterey on the MacBook Pro 11,3, TCC doesn’t fully work as expected (with missing prompts for accessing files and folders). So, my question was simply if it would be possible for the OCLP developers to “fix” this, or not…

Maybe you should address that to them instead of here but posting it in their Github, yes?
 
  • Like
Reactions: TimothyR734
New issues on their GitHub are temporarily closed. Anyway, there’s no hurry: just wondering why the unexpected TCC behaviour previously described happened (and there’s no mention of this in the OCLP documentation, IIRC); anyway, they know what is (not) doable: so, *if* it can be fixed, it probably will be fixed, sooner or later…
 
Last edited:
  • Like
Reactions: TimothyR734
New issues on their GitHub are temporarily closed. Anyway, there’s no hurry: just wondering why the unexpected TCC behaviour previously described happened (and there’s no mention of this in the OCLP documentation, IIRC); anyway, they know what is (not) doable: so, *if* it can be fixed, it probably will be fixed, sooner or later…
I doubt that's an issue either. If that's how OCLP treated the Machine, that's probably how it was set up. Maybe your machine has something else that is not in the registry, hence OCLP is ignoring it.

Try communicating with the author/s directly.
 
  • Like
Reactions: TimothyR734
^^^ But I didn’t tinker at all with those options: I simply tried two different configurations, knowing that it is only the Kepler dGPU that requires root patching (for example, a MacBook Pro 11,1, which doesn’t have the dGPU, will have SIP fully enabled with OCLP); thus discovering that with the stock root patched - no tinkering! - Monterey on the MacBook Pro 11,3, TCC doesn’t fully work as expected (with missing prompts for accessing files and folders). So, my question was simply if it would be possible for the OCLP developers to “fix” this, or not…
I'm afraid there is no way to fix it!
Once the Volume seal is broken by installing the driver for the dGPU, macOS can only boot if these parameters in the SIP are set up.
 
^^^ Thank you very much for your post, which made me search for the broken seal issue on Google; and I found this (very interesting):


… where it is suggested, in order to enable SIP as much as possible after root patching, to only disable the “autenticated root”, thus leaving SIP almost completely enabled - and, well… it worked! So, I reconfigured SIP in this way, on my already root patched MacBookPro11,3:

ED6C878D-A633-41C2-9B00-0DF224192072.jpeg


… and then rebooted without problems; now also with TCC fully working again, while csrutil status shows up as enabled in the Terminal (and SilentKnight, too, shows SIP as enabled and only SSV as disabled). So, it is indeed possible to boot a root patched MacBookPro11,3 with SIP almost completely turned on and thus also with a fully working TCC: very good, indeed! I’ll of course experiment a little more, still only from an external SSD, also to see if there are any other issues: sofar, everything seems to work well, with SIP enabled and SSV disabled… :cool::)
 
Last edited:
^^^ FileVault works fine on my machine, too (no problems at all); OTOH, it’s TCC that doesn’t fully work (with partially missing first-run security prompts for files and folders access), with the default root patch settings: but those default settings seem to be necessary only for the root patching itself, and afterwards SIP can be reenabled, thus leaving only the “no authenticated root” flag checked (= SSV disabled, or with broken seal: as SilentKnight correctly reports). Of course, still an “unofficial” solution: so, we’ll have to wait and see, if it will be implemented in future versions of OCLP…
 
Last edited:
^^^ FileVault works fine, on my machine (no problems at all); OTOH, it’s TCC that doesn’t fully work (with partially missing first-run security prompts for files and folders access), with the default root patch settings: but those default settings seem to be necessary only for the root patching itself, and afterwards SIP can be reenabled, thus leaving only the “no authenticated root” flag checked (= SSV disabled, or with broken seal: as SilentKnight correctly reports). Of course, still an “unofficial” solution: so, we’ll have to wait and see, if it will be implemented in future versions of OCLP…
I've joined your experiment with my MBP9,1. So far no problems. I'll return to default before trying to update and patch the system.
 
Updating from 12.1 Beta to 12.3 fails repeatedly on my iMac 13,1 with the error message "Storage system verify or repair failed". 12.3 installs and runs without problems on an external disk, which suggests that this error is probably due to a hardware error on the HDD. Running repair in Disk Utility did not correct the error. The failed macOS Installer is visible in Startup Manager and attempts to reinstall itself whenever the iMac is started.
I have not been able to find out where the macOS Installer is located. It's not visible in Finder, even when Hidden Files are enabled. Mounting the EFI partition did not reveal anything either. It would appear that there are two EFI partitions on the Fusion drive, one on the HDD and one on the NAND.
Does anybody know how to how to remove an unwanted macOS Installer?
 

Attachments

  • StorageSystemFailed.JPG
    StorageSystemFailed.JPG
    509.6 KB · Views: 109
  • StartupManager.JPG
    StartupManager.JPG
    338.4 KB · Views: 93
  • FusionDrivePartitions.png
    FusionDrivePartitions.png
    24.3 KB · Views: 86
  • Like
Reactions: TimothyR734
Updating from 12.1 Beta to 12.3 fails repeatedly on my iMac 13,1 with the error message "Storage system verify or repair failed". 12.3 installs and runs without problems on an external disk, which suggests that this error is probably due to a hardware error on the HDD. Running repair in Disk Utility did not correct the error. The failed macOS Installer is visible in Startup Manager and attempts to reinstall itself whenever the iMac is started.
I have not been able to find out where the macOS Installer is located. It's not visible in Finder, even when Hidden Files are enabled. Mounting the EFI partition did not reveal anything either. It would appear that there are two EFI partitions on the Fusion drive, one on the HDD and one on the NAND.
Does anybody know how to how to remove an unwanted macOS Installer?
Have you tried using ESP Mounter Pro app? I stumbled on it some time ago, and I found it easier to use to manage EFI partitions... It is free, too. https://www.olarila.com/topic/4975-esp-mounter-pro-v19/.
 
  • Like
Reactions: TimothyR734
For those with older MacBooks Pro (10,1), check SilentNight report on whether you need to update the EFI firmware, last round I was at 425 but upon checking today, I saw 426 was recommended. Booting into Catalina, while it did detect an update from Apple, applying the update did not resolve. I suspect since I had not cleared PRAM prior to booting into Catalina, that prevented a successful update. Having learned from that prior experience, cleared PRAM and reinstalled Catalina from scratch on my external HD, applied the recommended patches from Apple brought my items up to date (specifically EFI, MRT). If you're like me and want to stay on the latest possible firmware, give it a shot though before booting into Catalina, clear your PRAM to avoid running into a wall with the update.
Yeah SilentKnight is saying my rMPBP 10,1 needs to go to 426 also. Bummer. I will clear PRAM before updating my Catalina install drive, thank you very much for the heads up and I'll let you know how it goes.
 
Last edited:
Yes, Parallels works fine.
I have problems with oclp and parallels. After install root patch on MacBookPro 8.1 - 12.3 with oclp 0.4.3. I can't install or run parallels v17. When I revert the root patch it installs and run but without acceleration it is very annoying.

The same with Safari swipe back gesture.

Is there any solution to get back parallels and safari gestures after installing the root patch?
 
I have problems with oclp and parallels. After install root patch on MacBookPro 8.1 - 12.3 with oclp 0.4.3. I can't install or run parallels v17. When I revert the root patch it installs and run but without acceleration it is very annoying.

The same with Safari swipe back gesture.

Is there any solution to get back parallels and safari gestures after installing the root patch?
So, may be, unpatch, install Parallels and then re-install patches?
 
So, may be, unpatch, install Parallels and then re-install patches?
After re-install parallels stop working...

-------------------------------------
Translated Report
-------------------------------------

Process: prl_client_app [990]
Path: /Applications/Parallels Desktop.app/Contents/MacOS/prl_client_app
Identifier: com.parallels.desktop.console
Version: 17.1.2 (51548)
Build Info: Parallels-51548.0~17.1.51548.0
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 501

OS Version: macOS 12.3 (21E230)
Report Version: 12

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [990]

VM Region Info: 0 is not in any region. Bytes before following region: 4308926464
 
Yeah SilentKnight is saying my rMPBP 10,1 needs to go to 426 also. Bummer. I will clear PRAM before updating my Catalina install drive, thank you very much for the heads up and I'll let you know how it goes.
Let us know if clearing the PRAM before booting into Catalina helps apply the f/w update, otherwise reinstalling Catalina is a bit painful (the route I took).
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.