Jump to content
1961 posts in this topic

Recommended Posts

@ismolika Have you posted your current EFI (with config.plist) anywhere for public review?  Also, there is some conflicting / confusing info in this thread.  When csr-active-config = 0x0, SIP is fully ENABLED.  If you're still struggling with this, post your EFI when you ask for help.

3 minutes ago, deeveedee said:

@ismolika Have you posted your current EFI (with config.plist) anywhere for public review?  Also, there is some conflicting / confusing info in this thread.  When csr-active-config = 0x0, SIP is fully ENABLED.  If you're still struggling with this, post your EFI when you ask for help.

Hi, my csr-active-config is set to 67000000. I will try to post my EFI. Thank you.

@ismolika It looks like you may be confusing SIP settings after migrating from CLOVER to OC.  In addition to posting your EFI, test with csr-active-config=0x03080000 as has already been recommended to you.

  • Confused 1
34 minutes ago, deeveedee said:

@ismolika It looks like you may be confusing SIP settings after migrating from CLOVER to OC.  In addition to posting your EFI, test with csr-active-config=0x03080000 as has already been recommended to you.

Here is my EFI. If i change it to 0x03080000, i can not boot. Had to revert to 67000000.

config.plist

Edited by ismolika

@ismolika  Read this.  I won't go so far as to say that you got lucky with your SIP setting.  

 

WARNING: Disabling SIP can break OS functionality such as software updates in macOS 11, Big Sur and newer. Please be careful to only disable specific SIP values instead of disabling SIP outright to avoid these issues.
Enabling CSR_ALLOW_UNAUTHENTICATED_ROOT and CSR_ALLOW_APPLE_INTERNAL are common options that can break OS updates for users
You can choose different values to enable or disable certain flags of SIP. Some useful tools to help you with these are BitmaskDecode (opens new window) and csrstat (opens new window). Common values are as follows (bytes are pre-hex swapped for you, and note that they go under NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> csr-active-config):

00000000 - SIP completely enabled (0x0).
03000000 - Disable kext signing (0x1) and filesystem protections (0x2).
FF030000 - Disable all flags in macOS High Sierra (opens new window) (0x3ff).
FF070000 - Disable all flags in macOS Mojave (opens new window) and in macOS Catalina (opens new window) (0x7ff) as Apple introduced a value for executable policy.
FF0F0000 - Disable all flags in macOS Big Sur (0xfff) which has another new flag for authenticated root

 

EDIT: @ismolika Also, your config.plist does not include a corresponding "Delete" for NVRAM > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > csr-active-config.  This means that you are REQUIRED to Reset NVRAM every time you change csr-active-config and retest.  If you are testing without Reset NVRAM, your tests are probably inconclusive.  Best to add the corresponding Delete to your config.plist.

 

Screenshot2024-07-18at10_53_50AM.png.cb4db9746cc95aed25e90ac51c0e1741.png

Edited by deeveedee
  • Like 2
32 minutes ago, deeveedee said:

@ismolika  Read this.  I won't go so far as to say that you got lucky with your SIP setting.  

 

WARNING: Disabling SIP can break OS functionality such as software updates in macOS 11, Big Sur and newer. Please be careful to only disable specific SIP values instead of disabling SIP outright to avoid these issues.
Enabling CSR_ALLOW_UNAUTHENTICATED_ROOT and CSR_ALLOW_APPLE_INTERNAL are common options that can break OS updates for users
You can choose different values to enable or disable certain flags of SIP. Some useful tools to help you with these are BitmaskDecode (opens new window) and csrstat (opens new window). Common values are as follows (bytes are pre-hex swapped for you, and note that they go under NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> csr-active-config):

00000000 - SIP completely enabled (0x0).
03000000 - Disable kext signing (0x1) and filesystem protections (0x2).
FF030000 - Disable all flags in macOS High Sierra (opens new window) (0x3ff).
FF070000 - Disable all flags in macOS Mojave (opens new window) and in macOS Catalina (opens new window) (0x7ff) as Apple introduced a value for executable policy.
FF0F0000 - Disable all flags in macOS Big Sur (0xfff) which has another new flag for authenticated root

 

EDIT: @ismolika Also, your config.plist does not include a corresponding "Delete" for NVRAM > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > csr-active-config.  This means that you are REQUIRED to Reset NVRAM every time you change csr-active-config and retest.  If you are testing without Reset NVRAM, your tests are probably inconclusive.  Best to add the corresponding Delete to your config.plist.

 

Screenshot2024-07-18at10_53_50AM.png.cb4db9746cc95aed25e90ac51c0e1741.png

Screw this, lol i give up. status saz disabled, but oclp saz its enabled. i have no clue whats going on. Can live without the fenvi i guess. Thank you for your ehlp :)

17 minutes ago, ismolika said:

Screw this, lol i give up. status saz disabled, but oclp saz its enabled. i have no clue whats going on. Can live without the fenvi i guess. Thank you for your ehlp :)

 

You are welcome. You're just burnt-out from too many failed attempts. Give it a rest and then read the last few posts in this thread when you are ready to try again.

7 minutes ago, deeveedee said:

 

You are welcome. You're just burnt-out from too many failed attempts. Give it a rest and then read the last few posts in this thread when you are ready to try again.

Lol so true. I tried using 03080000 one last time, but im getting "bad cpu type in executable" at boot. 

 

2 minutes ago, eSaF said:

@ismolika - Hi you've been asked a few times by @deeveedee to post your EFI Folder and you haven't.

Whilst a config.plist can be helpful somewhat, the entire EFI Folder gives a far better understanding what the problem could be so that a member can give or suggest a fix.

Hopefully from the config.plist alone someone can spot what is wrong.

i have tried but can attach efi here. Guess have to do it somewhere else and link it here?

22 hours ago, deeveedee said:

 

Ok.  I assumed your were working more closely together.  I also assumed that you were posting what you thought should be a fully working config.

 

 @mek21 Always run OpenCore's ocvalidate utility on config.plist when you make changes.  Try using it on the OC config.plist that you posted and see what you find.  Also look at the two USBPort kexts enabled in your config.plist.

 

@eSaF I am trying to be good.  How am I doing?

 

EDIT: @mek21 Here's a hint for one of the problems that you'll uncover by using ocvalidate:

  Hide contents

Screenshot2024-07-17at2_34_15PM.png.c25baba64b93d9c0d166547580aaf06b.png

How do you spell VoodooPS2Controller.kext?

 

Thank you for your replies, the kext name was changed intentionally.

  • Confused 1
24 minutes ago, eSaF said:

You can post it here if you remove the Resources Folder to reduce the size.

PS - Found other possible error, remove or disable these patches, I don't think they are needed.

What I suggested before should suffice.

 

I am still going through your config for other improvements that can be made.

Screenshot 2024-07-18 at 17.23.03.png

Well after deletng resources folder its still too big. Max size is 10MB allowed here i see. So i dont know how to share the efi.

41 minutes ago, mek21 said:

Thank you for your replies, the kext name was changed intentionally.

 

That's a new technique for me, but glad you already know about it and I assume your EFI includes a kext named YoodooPS2Controller.kext.  Hard to tell without seeing your full EFI.  That's all I've got.  I hope you figure it out.  

 

For others trying to follow this issue, it's a good lesson.  When you ask for help, post your full EFI.  If, after compressing the EFI, it's too large to be attached to a post, copy your EFI to a temporary location, delete the OC/Resources, OC/Drivers and OC/Tools folders.  Then compress and attached the abridged EFI zip file.  Asking for help and expecting others to be mind readers is a bit of a stretch.  If you care about your privacy, remove MLB, ROM, SystemSerialNumber and SystemUUID from your config.plist before compressing and uploading.

Edited by deeveedee
  • Like 4

@ismolika You're the second person in a day to post a hack config with two USB kexts:

 

Spoiler

Screenshot2024-07-18at1_41_13PM.png.12db5b8f6758ef085c40c7baba82c910.png

 

I admit to being unfamiliar with most USB patching methods.  Are there USB patching kexts that require the use of USBInjectAll and a separate USB mapping kext (in your case, USBMap.kext)?

 

EDIT: @ismolika Also, I see that you added the NVRAM > Delete for csr-active-config.  You're still setting csr-active-config = 0x67 which is wrong.  Is that what you're still testing with?

 

EDIT2: @ismolika I am not familiar with USBPower.kext which is enabled in your config.plist and which exists in your OC/Kexts folder.  You also inject SSDT-EC-USBX.aml (ACPI > Add) in your config.plist.  Are you testing multiple USB patching techniques and accidentally leaving multiple methods enabled at the same time?

 

EDIT3: @ismolika I just read CorpNewt's instructions for USBMap.kext.  USBInjectAll.kext (and other USB kexts) must be disabled.  

 

Has this EFI worked with macOS versions prior to Sequoia Beta?  If not, I would recommend that you develop a fully working EFI with a released version of macOS (e.g. Sonoma) and then move on to Beta versions of Sequoia.  Just my recommendation and what I would do if I were you.

Edited by deeveedee
  • Like 3

@ismolika

Without csr-active-config=0308000 (type as Data) you'll not be able to apply OCLP root patch. This is mandatory. I don't know why you don't boot with such value but any other value prevents OCLP to apple the patch.

 

  • Like 3
  • Confused 1
2 hours ago, eSaF said:

You can post it here if you remove the Resources Folder to reduce the size.

PS - Found other possible error, remove or disable these patches, I don't think they are needed.

What I suggested before should suffice.

 

I am still going through your config for other improvements that can be made.

Screenshot 2024-07-18 at 17.23.03.png

Hi I still use disable rtc scheduling otherwise my hack has a lot of darkwake from sleep 😊

  • Like 1
1 hour ago, eSaF said:

I tried my best, I am done for the day editing EFI Folders. :lol:

You are always very polite and always help everyone. If the Hackintosh scene had more people like you, we wouldn't be where we are. Nowadays the Vanilla Rockets are too much to handle.

  • Like 5
5 hours ago, deeveedee said:

@ismolika  Read this.  I won't go so far as to say that you got lucky with your SIP setting. 

 

This has nothing to do with luck! 0x67 still is a valid mask (see 10.12 column). It's just that it won't work for applying root patches. The fact that 0x803 crashes the system might be due  bits 2, 6 and 7 are now missing. Maybe 0x867 yields better results.

 

Bildschirmfoto2024-07-18um22_11_20.thumb.png.3508979d5d75c62e95071c6426594cc2.png

Edited by cankiulascmnfye
  • Like 1
  • Thanks 1

@cankiulascmnfye I'm not sure what to say.  Read my statement again?

 

EDIT: It is clear that 0x67 is from a CLOVER EFI that was attempting to fully disable SIP.  See here for a refresher.  Again, I won't go so far as to say that it is lucky that this same CLOVER bit-pattern works in OC.

Edited by deeveedee
  • Sad 1
22 hours ago, robi62 said:

hi do you know if any version for sequoia have the Haswell patch included 

the one I use has not so cannot apply wireless coz it has errors

This error might be because of the OCLP itself, when you open the OCLP does it install the services required for the OCLP at first run or not? if not download the latest nightly version, delete the previous version, open the latest OCLP that you've downloaded and it should install all the required files to run OCLP properly.

  • Like 5
Guest
This topic is now closed to further replies.
×
×
  • Create New...