miliuco Posted April 27 Share Posted April 27 @ameenjuz Try the driver (ExFatDxe.efi) instead of the kext, put it into Drivers folder and config.plist and remove exfat.kext: https://github.com/acidanthera/OcBinaryData/tree/master/Drivers 3 Link to comment Share on other sites More sharing options...
Slice Posted April 28 Share Posted April 28 7 hours ago, miliuco said: @ameenjuz Try the driver (ExFatDxe.efi) instead of the kext, put it into Drivers folder and config.plist and remove exfat.kext: https://github.com/acidanthera/OcBinaryData/tree/master/Drivers There are two different worlds divided by mach_kernel start to process. First of all it clears all interrupt vectors and set own drivers. Briefly: efi drivers work before kernel started kext drivers work after kernel started including recovery mode. 3 Link to comment Share on other sites More sharing options...
ameenjuz Posted April 28 Share Posted April 28 (edited) 19 hours ago, miliuco said: @ameenjuz Try the driver (ExFatDxe.efi) instead of the kext, put it into Drivers folder and config.plist and remove exfat.kext: https://github.com/acidanthera/OcBinaryData/tree/master/Drivers Didn’t work with ExFatDxe.efi but in Ventura exfat volume mountable work fine intel base Mac without ExFatDxe.efi other hand in macOS Sonoma exfat volume is not mount recovery mode under disk utility Edited April 28 by ameenjuz Link to comment Share on other sites More sharing options...
Slice Posted April 28 Share Posted April 28 Apple didn't make exfat driver working in recovery because the is no sense to use exfat during system recovery. System recovery should use only APFS drives, exfat can be used for data store, no more. If you have a system installer on exfat volume then copy it in a bootloader to APFS volume and then use in recovery. 4 Link to comment Share on other sites More sharing options...
deeveedee Posted May 4 Share Posted May 4 (edited) @chris1111 Thanks . I have been setting FixupAppleEfiImages since here, but it didn't work for me and I still needed to use OC 0.9.6 legacy boot. I'll try again after OC 1.0.0 is released. EDIT: I have always required HfsPlusLegacy.efi on my HackBookPro6,2 since I created the Open Core solution for it. Since OC 0.9.7, I have assumed that I'm doing something wrong, but never took the time to debug and just reverted to OC 0.9.6 legacy boot. Edited May 4 by deeveedee 1 Link to comment Share on other sites More sharing options...
chris1111 Posted May 4 Share Posted May 4 (edited) 1 hour ago, deeveedee said: @chris1111 Thanks . I have been setting FixupAppleEfiImages since here, but it didn't work for me and I still needed to use OC 0.9.6 legacy boot. I'll try again after OC 1.0.0 is released. EDIT: I have always required HfsPlusLegacy.efi on my HackBookPro6,2 since I created the Open Core solution for it. Since OC 0.9.7, I have assumed that I'm doing something wrong, but never took the time to debug and just reverted to OC 0.9.6 legacy boot. Maybe a temporary solution Did you try to use only boot file from OC 0.9.6 to OC 1.0.0 EFI duet simply replace it If it work You are booting to OC 1.0.0 after Duet Init - Edited May 4 by chris1111 1 Link to comment Share on other sites More sharing options...
deeveedee Posted May 4 Share Posted May 4 @chris1111 Thanks. That is similar to @droples suggestion here. I haven't tried it, but I'm sure it would work. I'm going to test again when OC 1.0.0 is officially released. Thanks again. Link to comment Share on other sites More sharing options...
Stefanalmare Posted May 4 Share Posted May 4 3 hours ago, deeveedee said: @chris1111 Thanks. That is similar to @droples suggestion here. I haven't tried it, but I'm sure it would work. I'm going to test again when OC 1.0.0 is officially released. Thanks again. It works. I used duet like this last months. 1 Link to comment Share on other sites More sharing options...
Slice Posted May 4 Share Posted May 4 I used duet like this ten years or more. Link to comment Share on other sites More sharing options...
Anto65 Posted May 9 Share Posted May 9 (edited) Release v1.0.0 🎉 Updated builtin firmware versions for SMBIOS and the rest Switched to Apple silicon GitHub runner for CI, thx @Goooler Added Apple Silicon support in all provided utilities Utilities now require macOS 10.9+ (OpenCore itself still supports macOS 10.4+) Added AllowRelocationBlock support for 32-bit version Enabled additional serial logging in non-RELEASE builds of OpenDuet Added missing DxeCore ImageContext HOB in OpenDuet Fixed assert caused by dependency ordering in OpenDuet Prevented assert in normal situation when freeing memory above 4GB in OpenDuet Prevented debug assert reporting that optional Hii protocols are not present in OpenDuet Fixed problem loading non-firmware runtime drivers (e.g. OpenRuntime.efi) in OpenDuet Resolved issue using NOOPT debugging in OpenDuet Fixed alphabetical ordering in Configuration.pdf, thx @leon9078 Edited May 9 by Anto65 5 3 Link to comment Share on other sites More sharing options...
deeveedee Posted May 13 Share Posted May 13 Upgraded my HackBookPro6,2 to Open Core 1.0.0. LegacyBoot, LogoutHook and Vault all working perfectly. Running Big Sur, Monterey, Ventura and Sonoma. Well done, Devs! 2 Link to comment Share on other sites More sharing options...
chris1111 Posted June 8 Share Posted June 8 (edited) Why Insanelymac is not anymore in the support forum list of OpenCore ? I don't dream he was before EDIT *** Got it He was remove from this commit Edited June 8 by chris1111 2 Link to comment Share on other sites More sharing options...
MaLd0n Posted June 8 Share Posted June 8 Some comrades think here is a mess like Reedit or TonyMAc. There they can lie as much as they want or create 30 accounts to make cute spam. Here we have order and people have to follow the laws. We need understand one thing, wherever the Acidanthera sycophant are, it's just a mess and people know these guys. That's all folks! 7 4 Link to comment Share on other sites More sharing options...
Matgen84 Posted June 13 Share Posted June 13 (edited) Need help 😊 Please I've this error: OC Prelinked kexts invalid parameters with AirportItwml on Sequoia. Despite of SecureBootModel = j185 (for SMBIOS Imac20,1). So Opencore 1.0.1 Nightly do not injected this wifi kext Anybody knows....the solution ? Thanks Edited June 13 by Matgen84 1 Link to comment Share on other sites More sharing options...
cankiulascmnfye Posted June 13 Share Posted June 13 (edited) 9 minutes ago, Matgen84 said: Need help 😊 Please I've this error: OC Prelinked kexts invalid parameters with AirportItwml on Sequoia. Despite of SecureBootModel = j185 (for SMBIOS Imac20,1). So Opencore 1.0.1 Nightly do not injected this wifi kext Anybody knows....the solution ? Thanks AirportItwml is troublsome when updating macOS eversince 14.4. The workaround since then has been: disable AirportItwml, enable itlwm kext and heliport, disable SecureBootModel, update then revert settings But remeber: until a Sequoia Variant for AirportItlwm is released, you probably have to use itlwm. More info: https://github.com/OpenIntelWireless/itlwm/issues/983 On 6/8/2024 at 8:48 PM, chris1111 said: Why Insanelymac is not anymore in the support forum list of OpenCore ? I don't dream he was before EDIT *** Got it He was remove from this commit It has been taken off for this list for years now… Edited June 13 by cankiulascmnfye 1 1 Link to comment Share on other sites More sharing options...
cankiulascmnfye Posted June 13 Share Posted June 13 I am trying to install Sonoma on my Z490 System, but I get a grey screen where I should get the Setup Interface. I changed the Keyboard to a US Layout and also tried "-radvesa" boot-arg because I am uncertain if the AMD RX580 is still supported or not but no luck 1 Link to comment Share on other sites More sharing options...
Matgen84 Posted June 13 Share Posted June 13 4 minutes ago, cankiulascmnfye said: I am trying to install Sonoma on my Z490 System, but I get a grey screen where I should get the Setup Interface. I changed the Keyboard to a US Layout and also tried "-radvesa" boot-arg because I am uncertain if the AMD RX580 is still supported or not but no luck Do you try: -lilubetaall ! until new Lily plugins for Sequoia are realized. 1 Link to comment Share on other sites More sharing options...
eSaF Posted June 13 Share Posted June 13 1 hour ago, cankiulascmnfye said: I am trying to install Sonoma on my Z490 System, but I get a grey screen where I should get the Setup Interface. I changed the Keyboard to a US Layout and also tried "-radvesa" boot-arg because I am uncertain if the AMD RX580 is still supported or not but no luck Bro - This is my Z490 EFI Folder running from a clean install Spoiler , albeit an MSI Board but my Card is a RX580 also. Have a look for comparison and see if you can find and clear the hang-up on your system. Sequoia is running very smooth on my rig and the boot is a lot quicker than Sonoma. I even installed all my daily software that I use and all run no problem. Good luck. EFI.zip 3 Link to comment Share on other sites More sharing options...
cankiulascmnfye Posted June 13 Share Posted June 13 (edited) @eSaF Thanks for sharing 3 hours ago, Matgen84 said: Do you try: -lilubetaall ! until new Lily plugins for Sequoia are realized. no, only -lilubeta, but I guess I'll try -lilubetall next. thanks Edited June 13 by cankiulascmnfye 3 Link to comment Share on other sites More sharing options...
JorgeMax Posted June 14 Share Posted June 14 “Clean” installation of Sequoia still not possible with OpenCore? Link to comment Share on other sites More sharing options...
miliuco Posted June 14 Share Posted June 14 (edited) 6 minutes ago, JorgeMax said: “Clean” installation of Sequoia still not possible with OpenCore? Go to the Sequoia thread, a lot of users are installing it with OpenCore. Edited June 14 by miliuco 4 Link to comment Share on other sites More sharing options...
eSaF Posted June 14 Share Posted June 14 1 hour ago, JorgeMax said: “Clean” installation of Sequoia still not possible with OpenCore? I did a clean install with OC no problem. 2 1 Link to comment Share on other sites More sharing options...
AlfredoM Posted June 14 Share Posted June 14 (edited) I also had no problems with a clean install of Beta1 Sequoia on Hacki. Also update from Sonoma 14.5 to Beta1 of Sequoia worked perfectly on my hackintosh (see signature) You obviously have to use OC 1.0.0 and the latest kexts and bootarg option -lilubetaall. Edited June 14 by AlfredoM 3 Link to comment Share on other sites More sharing options...
deeveedee Posted June 19 Share Posted June 19 (edited) I see "Fixed `ThirdPartyDrives` quirk on macOS 14.4 and above" in the Open Core 1.0.1 change log. Apparently OC 1.0.1 is required for working SATA SSD Trim in 14.4+. Edited June 19 by deeveedee 3 1 Link to comment Share on other sites More sharing options...
deeveedee Posted July 19 Share Posted July 19 (edited) *** SOLVED - See EDITs at bottom of this post and see next post *** I discovered an interesting ACPI patching case with my hack's DSDT. I have an ACPI patch in my Open Core config.plist that changes _PTS -> XPTS. When I created the patch, I inspected my extracted DSDT table with MaciASL and I observed two instances of the string _PTS in the DSDT Table: the method definition (the instance I wanted to replace with XPTS) Method (_PTS, 1, NotSerialized) and a debug statement ADBG (Concatenate ("_PTS=", ToHexString (Arg0))) With my ACPI Patch count set to 0 and my Table Signature set to "DSDT" (so that all instances of _PTS in my DSDT were replaced by XPTS), my _PTS -> XPTS patch appeared to work fine (I inspected the patch result by using MaciASL's "File > New from ACPI" utility. However, when I changed the patch count from 0 to 1 (because I only want to replace the Method _PTS and not the Debug statement), my patch stopped working. With a patch count of 1, inspection of the DSDT with MaciASL's "File > New from ACPI" showed that Method (_PTS) remained unchanged. I inspected my DSDT.aml with hexfiend and found an instance of _PTS earlier in the DSDT. This instance of _PTS does NOT appear when viewed with MaciASL. Open Core was performing the _PTS -> XPTS replacement on an instance of _PTS that I did not intend to replace (and that I could not inspect with MaciASL). EDIT: There are a couple of ways that I can think to address this issue. I chose to add a byte to my ACPI Patch Find/Replace bit sequences for _PTS -> XPTS. My new ACPI patch for _PTS -> XPTS is as follows: Spoiler The additional byte <01> distinguishes the Method (_PTS) from other instances of _PTS in my DSDT. EDIT2: For anyone who wants to check my work (I'm open to a second opinion and to being corrected), my original, unpatched DSDT.aml is attached. DSDT.aml.zip Edited July 20 by deeveedee 3 Link to comment Share on other sites More sharing options...
Recommended Posts