Jump to content

OpenCore General Discussion


dgsga
8,888 posts in this topic

Recommended Posts

1 hour ago, Matgen84 said:

Hi all

 

I build OC myself from local repo.


Is it possible to build OpencorePKG only for X64 ! If yes, how

Let me know, please 🙂

Looks like setting "export ARCHS=(X64)" in your shell first before running `oc_build.tool` should work, haven't tested on my machine though. Parenthesis are important since it's specifying an array of builds you want.

 

Edit: Added export to shell command.

Edited by 1Revenger1
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, 1Revenger1 said:

Looks like setting "export ARCHS=(X64)" in your shell first before running `oc_build.tool` should work, haven't tested on my machine though. Parenthesis are important since it's specifying an array of builds you want.

 

Edit: Added export to shell command.

Thanks. I mistaken somewhere. Don't work for me 😔

Link to comment
Share on other sites

I'll be the first to admit that I'm not the best at staying current with OC changes between releases.  I believe that I'm getting to the bottom of the sleep problem that I documented here.  I now suspect that I need the APFS EFI driver with OpenCore 0.8.1.  

 

 When (which OC version) did the APFS EFI driver become necessary for macOS installs on SATA SSDs?

Edited by deeveedee
Link to comment
Share on other sites

@Download-Fritz Thank you for the quick reply.  Your response makes sense, but I'm almost certain that I've never needed to add the APFS EFI driver to OC before.  I'm doing some testing that required me to revert to Catalina for macOS installation on a SATA SSD with OC 0.8.1.  Without the APFS EFI driver, the 'macOS Install Data' volume was not visible to complete installation of macOS on the SATA SSD.  I have installed macOS on SATA SSD before (with OC) and never needed to add the APFS EFI driver.

 

It is very possible (and likely) that I am losing my mind, but I could have sworn that I never before needed to add the APFS EFI driver to OC's OC/Drivers folder (and config.plist).

Link to comment
Share on other sites

@Download-Fritz UEFI > APFS > EnableJumpstart is True in my config.plist.  Without adding ApfsDriverLoader.efi, my 'macos Install Data' volume was not visible to complete Catalina install with OC 0.8.1.  I have also enabled Kernel > Quirks > ThirdPartyDrives.

 

There's definitely something strange going on.  I don't want to waste your time, but if you can think of something obvious that I'm not doing (that would explain why I needed ApfsDriverLoader even though EnableJumpstart was True)...  Thank you.

 

EDIT: Maybe I also need JumpstartHotPlug?  Testing now...

 

EDIT2: @Download-Fritz I stumbled upon these issues here and here while trying to figure this out.  I played with various combinations of GlobalConnect, JumpstartHotPlug and ConnectDrivers mentioned in the issues, but to no avail.  With OC 0.8.1 (on USB) and without ApfsDriverLoader.efi, my hack does not list APFS volumes in the OC picker.  My config.plist is attached.  

 

I'm going to take a break from this, since I must be missing something obvious and need a fresh set of eyes to examine again.  I'm prepared to feel very stupid about the remedial mistake that I'm making.  At this time with OC 0.8.1 and Catalina, no combation of EnableJumpstart, GlobalConnect, JumpstartHotPlug and ConnectDrivers "shows" APFS volumes.  It is only with ApfsDriverLoader.efi that I'm able "see" APFS volumes on a SATA SSD when booting Catalina with OC 0.8.1.

 

EDIT3: I also tried with UnblockFsConnect set to True and False as mentioned here, but that did not help.  I'm going to revert to older OC to see if that resolves the issue.

config.plist.zip

Edited by deeveedee
Link to comment
Share on other sites

@Download-Fritz I reverted to OC 0.7.1 (an arbitrary choice) and all is working (APFS, sleep).

 

My 0C 0.7.1 config.plist is attached.

config.plist.zip

 

I got lucky with my arbitrary selection of OC 0.7.1.  When I test with any OC versions newer than 0.7.1 (Catalina), APFS volumes are not visible in OC boot picker when Catalina is installed on a SATA SSD (no NVMe SSDs).

Edited by deeveedee
Link to comment
Share on other sites

@Download-Fritz Thank you!  I'll look at this and figure out what I need to change.  I don't feel too stupid (just a little) - the MinDate/Version was something I generally ignored (big mistake).  Not so simple after all.

 

Thanks for taking the time to look.  I know you're very busy.  Hope you're well.

 

 

@Download-Fritz After you set me straight with the MinDate/MinVersion issue, I have found that I need to revert to OC 0.7.5 in order to reliably sleep/wake on my HackMini8,1 with Catalina installed on a SATA SSD.  I will continue to try to diagnose this problem in this thread.  Thank you again for the assist.

Edited by deeveedee
Link to comment
Share on other sites

@Download-Fritz  Thanks again for your help.  I have determined that my addition of boot-arg igfxfw=2 caused the sleep problem when my rig boots/runs MacOS from SATA SSD.  I'm not sure why this is not a problem when running from NVMe SSD, but since the performance improvement resulting from this boot-arg is marginal, I'm removing it from my posted EFI baseline.  More details here.

Link to comment
Share on other sites

1 hour ago, FredWst said:

Hi,

 

Update 0.8.1 to 0.8.2 without any change in config.plist, drivers, kext, ssdt, (Dell Optiplex 3070 i5-9500T MacMini 8,1  : Monterey)

I've kernel panic.

 

opencore-2022-07-04-192530.txt 256 kB · 4 downloads

 

 Screenshot.thumb.jpg.41265bc8932cc6a9e63770d5c8c502b2.jpg

 

 

Fred

 

1 hour ago, GOOGE said:

Seems like AppleALC.kext is what's making 0.8.2 crash...

 

https://github.com/acidanthera/bugtracker/issues/2070

  • Like 3
Link to comment
Share on other sites

@deeveedee

 

if it can help, I was having the same issu with igfxfw=2, I solved with adding a sleep(0x364) in _PTS. (Dell Optiplex 3070)

 

    Method (_PTS, 1, Serialized)  // _PTS: Prepare To Sleep
    {
        Debug = Concatenate ("Method _PTS Called 0x", ToHexString (Arg0))
        Sleep (0x0364)
        ZPTS (Arg0) -> call to original in dsdt witch was rename at boot to ZPTS
    }

 

Fred

Edited by FredWst
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

 

@Andrey1970

 

Removing AppleALC.kext at boot solve kernel panic but boot stop à little bit later.

Will do a screenshot ASAP.

 

Fred

 

Edit: just read bug tracker will test tomorrow.

 

Edit : last AppleALC solve my issu.

Edited by FredWst
Link to comment
Share on other sites

@deeveedee

 

Yes trial and error and big luck, 0x364 maybe it change for other platform and I'm not able to confirm.

Even not sure it should solve your issu with different platform HP vs Dell, and other differences.

It was just to share my case. 

 

Fred

Edited by FredWst
Link to comment
Share on other sites

29 minutes ago, Andrey1970 said:

Seems like AppleALC.kext is what's making 0.8.2 crash...

Happening on my rig as well, had to revert to the last working one.

Link to comment
Share on other sites

Guest 5T33Z0

My heart stopped for a minute, since I also submitted a Layout for ALC269. But mine is Layout-ID 39 and it has been working on my system for weeks without issues.

Link to comment
Share on other sites

×
×
  • Create New...