OpenCore General Discussion

[Mork vom Ork]

Sorry for asking, but is it possible to patch "config.plist"s within OpenCore?

I mean is it possible to patch a value within kexts "config.plist" to any other value?

Edited February 7, 2021 by Mork vom Ork

[deeveedee]

On 2/7/2021 at 5:01 AM, Download-Fritz said:

The complaint? There are plenty of complaints ...

I disagree.  How does one complain about software that is maintained at no cost to the end user with countless hours of outstanding support and response to user questions?  Both the OC and CLOVER teams are to be commended for their incredible work and commitment.  Now I definitely agree that there are many issues that have yet to be resolved.  Complaints?  Don't really do much good.

[mhaeuser]

@Mork vom Ork Writing to the FS in UEFI is dangerous and known to cause corruption (if you mean permanently editing config.plist). Just changing parameters for the boot would not be terrible, however there are security concern (arbitrary boot args / adding kexts / ...) for most of the functionality, and the "safe" functionality was not really needed so far. External contributions could be discussed at some point, but we have no plans.

 

@MifJpn Maybe bisect the problematic commit if you believe it is not a config issue?

 

@tonyx86 I picked up the word from the original post, and it is obvious it means something like "design issues OC (supposedly) fixed".

Edited February 8, 2021 by Download-Fritz

[droples]

4 hours ago, MifJpn said:

Hello everyone.
I have compiled bf999acf6e04efda9780a1099648bd5ce393774c for OpenCore 0.6.7.
When I used it, Catalina recovery could not boot.(pause and menu screen)
What about you?

Thank you.

 

If you want to get an answer, then submit the download log (debug = 67 in the config.plist).

USE https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true it is safer.

[mhaeuser]

46 minutes ago, MifJpn said:

I wonder if there is any reason, if possible, please let me know.

Well, the driver is immature, no real reason to use it really. It's there only because it's OSS.

[ghost8282]

I'm reading that OpenHfsPlus.efi  is slower than HFSPlus.efi: well, this is not my case

Just to report it, as it seems all (or most of users) are experiencing this.

Before OpenHfsPlus.efi there was another driver from Acidanthera (sorry, I don't remember what was the file name), and yes that old driver was very slow (several minutes) compared to HFSPlusLegacy.efi (I was using the legacy version of the driver).

Now with OpenHfsPlus.efi I'm able to boot into recovery in about 40s (starting to take time from the bootpicker to the window of the recovery); the same (or a couple of seconds more) is with HFSPlusLegacy.efi.

Edited February 10, 2021 by ghost8282

[ghost8282]

6 hours ago, Hervé said:

Just a little flag I'm raising re: OpenCore and a recent behaviour observed by several people (myself included) in relation to the Big Sur 11.2.1 update:

https://www.insanelymac.com/forum/topic/346548-release-macos-big-sur-112-1121/?do=findComment&comment=2750803

https://www.insanelymac.com/forum/topic/346548-release-macos-big-sur-112-1121/?do=findComment&comment=2750828

https://osxlatitude.com/forums/topic/15114-latitude-e5470-cannot-find-latest-version-macos

 

It happened to me too, not this time with the 11.2.1 from 11.2, but with older updates, last time if I remember well to update to 11.2 (virtual machine on kvm/qemu), but I'm not sure what caused it, if a bug in OVMF_VARS/OVMF_CODE or other..

No updates available both from the terminal and the system preferences (gui).

When this happens I delete OVMF_VARS.fd and OVMF_CODE.fd, replace that files with fresh ones, reboot and after this the update shows (most probably deleting/replacing only OVMF_VARS.fd is enough).

Resetting the nvram from the picker doesn't help.

However again, I'm not sure on what it depends.

On the next update when the issue will show (if it will show) I will keep a backup of the 2 files which I will delete to compare.

Edited February 11, 2021 by ghost8282

[deeveedee]

My BS 11.2 to 11.2.1 upgrade completed with one minor issue that resolved itself.  Details below...

 

Updated my HackMini8,1 from BS 11.2 to BS 11.2.1 with almost no issues.  After the first reboot, OC 0.6.6 correctly selected the 'Macintosh HD' volume.  After the second reboot, OC correctly selected the primary BS volume.  After the 3rd reboot, OC correctly selected the primary BS volume, but a 4th reboot occurred (with a shutdown error).  However, after the 4th reboot, BS was completely upgraded to 11.2.1.  My system details are below with more documented here.

 

About This Mac: BS 11.2.1 (20D74)

Spoiler

 

EDIT: I am running Catalina 10.15.7 on this same system (Catalina is still my production environment).  My supplemental update of Catalina 10.15.7 completed without any issues.  The update was flawless using the exact same EFI that I'm using for BS (OC 0.6.6).

 

About This Mac: Catalina 10.15.7 (19H524)

Spoiler

 

System Details:

• OC: 0.6.6 Release Build (Text boot picker, HFSPlus.efi)
• SMBIOS: MacMini8,1
• Chipset: Q370
• CPU: CoffeeLake i7-8700
• Graphics: UHD630 (iGPU-only)
• Displays: 3 x DP -> DigitalDVI
• Memory: 32GB DDR4 (2x16GB)
• Storage: 2 x M.2 NVMe SSD, 1 x 2TB SATA6 HD
• Other detail that may be unique to this system: HPET is disabled via ACPI patch (see why, here)

 

Edited February 11, 2021 by tonyx86
Added notes about Catalina 10.15.7 supplemental update

[Frankovich]

Hey guys! I have some trouble. I have Intel Xeon E2690v1, BigSur 11.2.1, Win 10 Pro 20H2 on different SSD and trouble with all these. When I load in Win from OC my CPU work only on 2,4-2,88Ghz. No turboboost and no speedstep for lowers numbers. If I load from BIOS - all work perfectly. I found that if I turn off dropping "Delete CpuPm" in ACPI - CPU in windows through OC works perfectly. But in dortania's manual for my CPU I need to drop CPU tables... Without it, I haven't speedstep and turboboost in macOS... Any ideas on how to isolated dropping tables only for macOS or any other help? Will appreciate for help.

 

Added my EFI if you need it. Here my OC 0.6.4 but it doesn't matter I think.

EFI.zip

Edited February 11, 2021 by Frankovich

[Frankovich]

22 hours ago, Hervé said:

I believe the Dortania OpenCore guide full details the steps you ought to follow in order to configure proper CPU power management settings for your Sandy Bridge EP CPU; I suggest you read those again (or for the 1st time if you've never consulted the place). You would be expected to remove dropping of those tables after you've generated and installed the SSDT table created by Pike R Alpha's well-known generator script.

Dortania's OpenCore guide not a full details the steps for CPU power management settings and USB for my x79, but with Google and Dortania I fixed my trouble. Thanks.

[ghost8282]

14 hours ago, Hervé said:

On re-enabling SIP or setting csr-active-config to 0x67 or 0x3e7 (i.e. values typically set in Clover before), all is Ok and the update is offered and fully downloadable.

I have that field empty (now I have the doubt that this may be not right...), I set sip through the terminal, sip is enabled and authenticated-root is enabled too (no custom config, all shows as "Enabled"). But still sometimes the updates don't show.

This remains the only way to get updates when it hangs with "no updates available".

Edited February 13, 2021 by ghost8282

[Matgen84]

24 minutes ago, ghost8282 said:

I have that field empty (now I have the doubt that this may be not right...), I set sip through the terminal, sip is enabled and authenticated-root is enabled too (no custom config, all shows as "Enabled"). But still sometimes the updates don't show.

This remains the only way to get updates when it hangs with "no updates available".

 

With SIP enabled, do you have in config.plist:

 

<key>SecureBootModel</key>
<string>Disabled</string>

 

[ghost8282]

8 minutes ago, Matgen84 said:

 

With SIP enabled, do you have in config.plist:

 

<key>SecureBootModel</key>
<string>Disabled</string>

 

mmm no..it's "Default"

If I remember well, with "Disabled" I had issues with updates.

Edited February 13, 2021 by ghost8282

[ghelid]

On 9/11/2020 at 10:56 PM, pkdesign said:

But now at boot I get following:

OCSB: No suitable signature - Security Violation

OCB: Apple Secure Boot prohibits this boot entry, enforcing!

OCB: LoadImage failed - Security Violation

 

Not sure which of these are wrong or if I need any of them at all.

 

On 9/11/2020 at 11:03 PM, iGPU said:

 

There's one new entry that I'm not seeing in your list: set Misc/Security/SecureBootModel to "Disabled".

 

I have the same problem, it gives me this error and yet I moved securebootmodel to NO, but I don't have disabled. can I see your plist?

[ghost8282]

2 minutes ago, ghelid said:

I moved securebootmodel to NO,

It's not boolean, it's a string! Read documentation.

[hardcorehenry]

Updated OC today to the latest commit and… did I miss something? Anyone else have the same issue?

Spoiler

 

Edited February 14, 2021 by hardcorehenry

[gorans]

Do You know why Hackintool displays this info about IGPU?

 

VdaDecoderChecker shows: Hardware acceleration is fully supported, and I have UHD 630 accel in Videoproc. Do I need to check something else to confirm that it's fully working? My main video card is Radeon RX 570. MacOS 10.15.7.

[mhaeuser]

@hardcorehenry There have been multiple fix commits to the new mechanism, please reproduce with latest master in a few minutes or hours (vit is updating the code yet again at the moment). Sorry

 

EDIT: https://github.com/acidanthera/OpenCorePkg/commit/c97baf360beb66b2be8c653c0fa4241c73d9a211

Edited February 14, 2021 by Download-Fritz

[deeveedee]

3 hours ago, gorans said:

Do You know why Hackintool displays this info about IGPU?

 

What version of Hackintool?   I'm running Hackintool v3.5.3 which reports the following for my rig:

 

VDA Decoder

Spoiler

 

IGPU

Spoiler

 

[gorans]

3 hours ago, Hervé said:

Check what SysInfo shows. If Ok, contact Hackintool author as it would not be OpenCore related, would it?

 

If by SysInfo You mean System Information, it doesn't show IGPU at all. In Activity monitor I also have only RX 570. I don't know if that is expected behavior, that's why I'm checking here. Thanks.

 

@tonyx86 I have 3.5.3 also. VDA decoder also says Fully Supported, but GPU name is "Intel ???". Do You drive a display with Your iGPU?

Edited February 14, 2021 by gorans

[gorans]

48 minutes ago, Hervé said:

Don't know why you post here to be honest; you probably have some config settings to adjust and it's not really an OpenCore matter or problem.

 

Well, I'm using OpenCore as a bootloader and I set IGPU properties through OpenCore config.plist as per Dortania OpenCore guide. The only app that shows IGPU properties (Hackintool 3.5.3) is not showing proper value. If You say that's normal behavior for IGPU that's only used for acceleration or if You have any advice how to do a proper check, please do so.

[hardcorehenry]

On 2/14/2021 at 8:12 AM, hardcorehenry said:

Updated OC today to the latest commit and… did I miss something? Anyone else have the same issue?

  Reveal hidden contents

 

 

Smbios(MLB) issue has been fixed. Hackintool shows everything correctly

Also:

nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB

nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:HW_MLB

return correct value.

Thanks!

Edited February 15, 2021 by hardcorehenry

[Frankovich]

On 2/12/2021 at 10:47 PM, Hervé said:

@Frankovich, yes Dortania's documentation does detail what to do for CPU power management on Sandy Bridge and Ivy Bridge CPUs and clearly explains what to do with CPU PM tables with regards to impact on Windows, but whatever...

https://dortania.github.io/OpenCore-Post-Install/universal/pm.html#sandy-and-ivy-bridge-power-management

 

As for "USB for x79", you made no mention of this until now, so no further comment...

For x79, USBInjectAll.kext not work without some patches (EUSB to EH01 and USBE to EH02) that make loading macOS impossible to run ssdtPRGen.sh and etc. About this issue, I didn`t find any info at dortania. And if you think that dortania does detail wrote about PM, I can not conform with it. Again for x79 need some patches except your godly ssdtPRGen.sh. Yes, I realize that my motherboard not typical and dortania documentation is very good, but not fully for all hardware, but you shouldn't think that if something not works, it`s only because users can not read dortania correctly, should suggest that maybe there missed some info for some situations. When I migrate from Clover to OC near a year ago - in dortania wasn`t info about Sandy Bridge or Sandy-E, the oldest was Ivy. So I was really happy that an article about it was added. 

 

Hope you will understand me correctly. I don't want to make an angry discussion, maybe I didn`t found info about these patches at dortania and it`s only my mistake, just want to say that everyone can do mistakes and need to be able to recognize them. 100% dortania is a perfect example of documentation with the most detailed info but not with all, and all Hackintosh user happy that they have it. 

Finally want to say thanks for showing that now we have an article about Sandy-E, and wish you a good day. Best regards.

Edited February 15, 2021 by Frankovich

[Alpha22]

Question: dualboot windows10 big sur using open core I have to configure something related to dualboot in the config.plist.
I ask why with open core windows 10 loads the wheel endlessly

thanks

[deeveedee]

For anyone who still likes the FakeSMC (v.6.26-357.1800) HWMonitor.app and wants to use FakeSMC with OC, see @FreeJHack 's newer FakeSMC (v.6.26-357.1801)  here.  I was still using the 'old' FakeSMC.kext on my rig with OC 0.6.6 and thought it was working fine (despite the backtrace errors).  I now suspect that the 'old' FakeSMC with OC was responsible for some random reboots that I experienced after updating my rig's BIOS.  I also suspect that my use of the 'old' FakeSMC with OC 0.6.6 was responsible for the restart that I experienced here when upgrading from BS 11.2 to 11.2.1.  If you use FreeJHack's FakeSMC and you use XCode to edit your config.plist, see my note here.

Edited February 16, 2021 by tonyx86
Added FakeSMC version (to distinguish from different FakeSMC products)