deeveedee Posted March 31 Author Share Posted March 31 (edited) I haven't investigated this issue much, so accept my apologies for what might be a remedial question. Has anyone figured out why installation of Sonoma 14.4+ requires OC's SecureBootModel=Disabled on hacks that don't need SecureBootModel=Disabled to install previous versions of macOS? Currently, my hack (SMBIOS MacMini8,1 / OC 0.9.9) requires SecureBootModel=Disabled to install Sonoma 14.4+, but after installation, Sonoma 14.4+ runs with SecureBootModel=Default and SecureBootModel=j174. Edited March 31 by deeveedee 1 Link to comment Share on other sites More sharing options...
miliuco Posted March 31 Share Posted March 31 @deeveedee Here, with iMac19,1, I update having SBM as x86legacy. Disabled not needed. I don’t know why. 1 Link to comment Share on other sites More sharing options...
deeveedee Posted March 31 Author Share Posted March 31 (edited) @miliuco Good to know. Setting SecureBootModel=Disabled was a lucky guess for me (based on OCLP testing), but now I'm seeing that others knew about this well before me since I didn't test 14.4 Beta. I see SecureBootModel=Disabled in other posted hack installation/upgrade guides for 14.4. If I'm correct, iMac19,1 does not have T2 chip (or at least some variations of iMac19,1 do not have T2) - correct? If so, that's probably why you don't need SecureBootModel=Disabled, but I still don't know why I would need to disable SecureBootModel for installation of 14.4 but not for normal operation of 14.4 on my hack with SMBIOS MacMIni8,1 (which does have T2). Edited March 31 by deeveedee 2 Link to comment Share on other sites More sharing options...
Cyberdevs Posted March 31 Share Posted March 31 @deeveedee I'm using MacPro7,1 SMBIOS on my Alder Lake rig and I'm still on Monterey and for installing Monterey updates and/or installing macOS Monterey, Ventura and Sonoma I have to set SecureBootModel=Disabled to be successful otherwise I'll get the reboot loop. So I guess this issue isn't only limited to Sonoma. 2 Link to comment Share on other sites More sharing options...
deeveedee Posted March 31 Author Share Posted March 31 (edited) @Cyberdevs MacPro7,1 does have T2, correct? Interesting that you started observing this with Monterey. Are you using RestrictEvents.kext with revpatch=sbvmm? @miliuco Are you using RestrictEvents.kext with revpatch=sbvmm? Edited March 31 by deeveedee 1 Link to comment Share on other sites More sharing options...
miliuco Posted March 31 Share Posted March 31 @deeveedee Afaik, iMac19,1 Macs did not have T2. This is why I don't need RestrictEvents to be notified of updates. What I've noticed recently is that, if I disable Gatekeeper, I don't get update notifications. In previous Sonoma updates this was not necessary. 1 Link to comment Share on other sites More sharing options...
Cyberdevs Posted March 31 Share Posted March 31 4 hours ago, deeveedee said: @Cyberdevs MacPro7,1 does have T2, correct? Interesting that you started observing this with Monterey. Are you using RestrictEvents.kext with revpatch=sbvmm? @miliuco Are you using RestrictEvents.kext with revpatch=sbvmm? Yes as far as I know it has a T2 Chip and yes I do use RestrictEvents.kext but for Monterey I don't use revpatch=sbvmm boot arg, maybe I should use the boot arg and see if that changes the behavior when I try to install Monterey or other installations. I don't use the revpatch=sbvmm because I do get the incremental updates so I didn't think that it was needed in my case. 2 Link to comment Share on other sites More sharing options...
deeveedee Posted April 1 Author Share Posted April 1 6 hours ago, Cyberdevs said: I don't use the revpatch=sbvmm because I do get the incremental updates so I didn't think that it was needed in my case. You're probably right. I don't remember all the reasons for using revpatch and will need to refresh my memory. Link to comment Share on other sites More sharing options...
Slice Posted April 1 Share Posted April 1 Revpatch informs macOS that you are using VMWare to get updates from Apple. But if you are using SMBIOS iMac19,1 (or MacBookPro15,1?) then you'll get update without this patch. 3 1 Link to comment Share on other sites More sharing options...
AslashA Posted May 17 Share Posted May 17 On 4/1/2024 at 9:05 AM, Slice said: Revpatch informs macOS that you are using VMWare to get updates from Apple. But if you are using SMBIOS iMac19,1 (or MacBookPro15,1?) then you'll get update without this patch. There is also a kext to avoid using this revpatch entry in the bootarg every time you update. 1 Link to comment Share on other sites More sharing options...
cankiulascmnfye Posted May 17 Share Posted May 17 On 4/1/2024 at 8:05 AM, Slice said: Revpatch informs macOS that you are using VMWare to get updates from Apple. But if you are using SMBIOS iMac19,1 (or MacBookPro15,1?) then you'll get update without this patch. This must be one of the most inadequate description of what the revpatch=sbvmm actually does I've seen so far… 1 Link to comment Share on other sites More sharing options...
miliuco Posted May 17 Share Posted May 17 @AslashA it's the same kext forked by @lorys89 who has made updates to the code. 1 Link to comment Share on other sites More sharing options...
RobertX Posted May 18 Share Posted May 18 6 hours ago, cankiulascmnfye said: This must be one of the most inadequate description of what the revpatch=sbvmm actually does I've seen so far… revpatch=value to enable patching as comma separated options. Default value is auto. sbvmm - forces VMM SB model, allowing OTA updates for unsupported models on macOS 11.3 or newer ...that is from github, is it more correct? Link to comment Share on other sites More sharing options...
cankiulascmnfye Posted May 19 Share Posted May 19 On 5/18/2024 at 5:57 AM, RobertX said: revpatch=value to enable patching as comma separated options. Default value is auto. sbvmm - forces VMM SB model, allowing OTA updates for unsupported models on macOS 11.3 or newer ...that is from github, is it more correct? What it actually does is described in detail here: https://github.com/5T33Z0/OC-Little-Translated/tree/main/09_Board-ID_VMM-Spoof 2 Link to comment Share on other sites More sharing options...
Slice Posted May 19 Share Posted May 19 On 5/18/2024 at 12:00 AM, cankiulascmnfye said: This must be one of the most inadequate description of what the revpatch=sbvmm actually does I've seen so far… Brief but exact. 2 hours ago, cankiulascmnfye said: What it actually does is described in detail here: https://github.com/5T33Z0/OC-Little-Translated/tree/main/09_Board-ID_VMM-Spoof Very good manual! All principles here are for OC. 1 Link to comment Share on other sites More sharing options...
miliuco Posted May 21 Share Posted May 21 @Slice This user has also a repo for Clover: https://github.com/5T33Z0/Clover-Crate Link to comment Share on other sites More sharing options...
Slice Posted May 21 Share Posted May 21 25 minutes ago, miliuco said: @Slice This user has also a repo for Clover: https://github.com/5T33Z0/Clover-Crate I know he is the same man. Link to comment Share on other sites More sharing options...
AslashA Posted May 21 Share Posted May 21 If I use kext forked by @lorys89, is the revpatch=sbvmm value always active? Or is it only activated when updating? Who can tell? Link to comment Share on other sites More sharing options...
miliuco Posted May 22 Share Posted May 22 @AslashA I think that @lorys89 fork doesn’t need the boot arg. Try yourself. 1 Link to comment Share on other sites More sharing options...
Recommended Posts