OpenCore General Discussion

[Guest 5T33Z0]

Thanks for the Icons! This is how it looks now. I don't know why the ResetNVRAM Icon is not applied, but it's okay.

 

 

Edited September 6, 2021 by 5T33Z0

[Allan]

First monday = exciting day! 😁
Already get OC 0.7.3 running veery smooth here!

 

Thank you devs 👏👏

[Anto65]

Pleasant awakening this morning
everything ok here too😀 

 

 

 

 

https://www.insanelymac.com/forum/topic/348778-problems-with-latest-opencore-073-build/?do=findComment&comment=2765709

 

[deeveedee]

22 hours ago, Download-Fritz said:

I have explained that this is not easily possible. Let me know when instead of CAPS you provide a PULL REQUEST to improve the tool.

Is it possible to provide the section where the violation occurs (even if the line number is not possible).  For this most recent update from OC 0.7.2 -> 0.7.3, could ocvalidate have indicated that the errors were in UEFI>Drivers?

 

EDIT: I'm referring to the initial 'OCS: Couldn't get array serialized at 0 index!' error.  I realize that UEFI->Drivers is referenced later in the error report  '

UEFI->Quirks->RequestBootVarRouting is enabled, but OpenRuntime.efi is not loaded at UEFI->Drivers!

CheckUEFI returns 1 error!'

Edited September 7, 2021 by tonyx86

[mhaeuser]

@tonyx86 Not sure, the XML stack is entirely @vit9696's work. At the moment we have more urgent issues, like the continuous breaking of Apple Secure Boot, sorry.

[deeveedee]

@Download-Fritz As always, I greatly appreciate all the work that you and the OC team are doing.  OC 0.7.3 was a painless update and it is working perfectly for me.  Thank you.

Edited September 7, 2021 by tonyx86

[Guest 5T33Z0]

Wow, I just stumbled over this ECEnabler.kext and now I no longer need all these binary renames to get the battery indicator working. Best kext evuuuurrr!

[shiecldk]

@vit9696

 

My i9-10980HK is recognized as a n Intel i7. Can you fix it in OpenCore?

 

Edited September 9, 2021 by shiecldk

[Guest 5T33Z0]

LOL… this sounds like Angela Merkel talking about the dangers of the internet. Basically, this directly takes shots at OpenCoreConfigurator without calling it out by name.

 

 

 

Edited September 10, 2021 by 5T33Z0

[Allan]

19 minutes ago, shiecldk said:

@vit9696

 

My i9-10980HK is recognized as a n Intel i7. Can you fix it in OpenCore?

 

Try change the SMBios. E,g: MacBookPro16,2

[Anto65]

In addition to choosing the right smbios as recommended, verify that ProcessorType is set to 0 in PlatformInfo> Generic

[Guest 5T33Z0]

@antuneddu @shiecldk This might be a problem – becaue there is no SMBIOS for 10th Gen Intel Mobile I9. And my guess is: there won't ever be one, since Apple abandoned Intel… especially for mobile computing – that's why the developed M1 processors primarily. Closest thing would be MacBookPro16,1 (9th Gen i9) or MacBookPro16,2 (10th Gen I7). I would test both and run with the one which scores the highest in Geekbench 5. But don't forget to adjust the Framebuffer Patchfor each SMBIOS accordingl.

 

Edited September 10, 2021 by 5T33Z0

[Anto65]

But hit is a 10gen Comet Lake or am I wrong ? 11gen is more problematic

https://www.intel.it/content/www/it/it/products/sku/201838/intel-core-i910980hk-processor-16m-cache-up-to-5-30-ghz/specifications.html

For desktop 

https://dortania.github.io/OpenCore-Install-Guide/config.plist/comet-lake.html#platforminfo

For laptop

https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/coffee-lake-plus.html#platforminfo

 

[Guest 5T33Z0]

57 minutes ago, antuneddu said:

But hit is a 10gen Comet Lake or am I wrong ? 11gen is more problematic

https://www.intel.it/content/www/it/it/products/sku/201838/intel-core-i910980hk-processor-16m-cache-up-to-5-30-ghz/specifications.html

For desktop 

https://dortania.github.io/OpenCore-Install-Guide/config.plist/comet-lake.html#platforminfo

For laptop

https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/coffee-lake-plus.html#platforminfo

 

 

I know that he has a 10 th gen Intel Mobile i9… that's not the question. The point is that there is no SMBIOS for it!

 

The lastest macBook Pro Model is 17, and it has an M1 Chip ONLY: https://everymac.com/ultimate-mac-lookup/?search_keywords=MacBookPro17,1

The last MacBookPro Model with an i9 Intel chip was 9th Gen: https://everymac.com/ultimate-mac-lookup/?search_keywords=MacBookPro16,1

The only 10th gen SMBIOSes ar for these models and none of them use a mobile i9: https://everymac.com/ultimate-mac-lookup/?search_keywords=MacBookPro16,2

Edited September 10, 2021 by 5T33Z0

[Guest 5T33Z0]

I have a quesion about the use of PlatformInfo > Generic > ProcessorType.

 

In my Notebook (running as MacBookPro10,1) I have an Intel I7 3630QM. According to this List, it is a Type Core i7 Type 4.and has the value 0x0704 as listed here

 

So if I wanted to change the field ProcessorType from "0" (Auto) to 0x0704, do I have to bit swap it to 0407 or what do I just enter 0704?

[Guest 5T33Z0]

@Download-Fritz Suggestion for https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Kexts.md

 

NoTouchID: Add MaxKernel: 18.9.9 (since this kext is no longer needed past macOS 10.14)

[mhaeuser]

@5T33Z0 Create a PR? The README mentions different versions, but I don't whether they are exact.

[chris1111]

0.7.4

Good no issue

Config Validator update in my github

[Henties]

Whenever I try to boot Ubuntu 20.04 from Big Sur 11.5.2 with OC 0.7.3 and  the OpenLinuxBoot.efi and ext4_x64.efi enabled in the config.plist UEFI --> Drivers section on a Haswell or Skylake based hack, the machines lock up solid during booting and do not even reach the OC boot selection screen.

In the Misc --> Entries section, the directives for booting Linux have been disabled.

This new method of bypassing GRUB, works very well on my two Comet Lake hacks but not on my Haswell and Skylake based hacks. 

Anybody experiencing a similar issue with they older hacks? 

I my case all my machines are on Big Sur 11.5.2 and run without any issues whatsoever, except that for the Haswell and Skylake builds I cannot migrate to booting Linux with the new "GUB bypass" method. 

Some feedback as to what could cause the issue would be appreciated.

Oh by the way all Ubuntu 20.04 LTS Linux systems on all my machines have been upgraded to the latest available codebase, ie. Ubuntu 20.04....LTS...34. and all the respective config.plist files pass the ocvalidate sanity scan without any issues.

Needless to say, I am using the exact same OpenLinuxBoot.efi and ext4_x64.efi drivers and versions that are successfully deployed in my Comet Lake hacks.

 

Greetings Henties

 

Edit:

When attempting to boot into Linux from Haswell, with the OpenLinuxBoot.efi and ext4_x64.efi drivers, the hack not only hangs good and solid but while attempting to boot it actually screws up Grub to the extent that I need to reinstall GRUP with Linux's "Boot repair" in order to at least be able to get into Linux again via the old Misc--> Entries method.

 

 

 

 

Edited September 11, 2021 by Henties

[Guest 5T33Z0]

@Henties Did you disbale the custom entries to the linux bootloader in the config? I think it is not needed anymore. Otherwise I would create an issue in acidantheras bug tracker. That Linux implementation is pretty new.

[Septendre]

6 hours ago, Henties said:

Whenever I try to boot Ubuntu 20.04 from Big Sur 11.5.2 with OC 0.7.3 and  the OpenLinuxBoot.efi and ext4_x64.efi enabled in the config.plist UEFI --> Drivers section on a Haswell or Skylake based hack, the machines lock up solid during booting and do not even reach the OC boot selection screen.

In the Misc --> Entries section, the directives for booting Linux have been disabled.

This new method of bypassing GRUB, works very well on my two Comet Lake hacks but not on my Haswell and Skylake based hacks. 

Anybody experiencing a similar issue with they older hacks? 

I my case all my machines are on Big Sur 11.5.2 and run without any issues whatsoever, except that for the Haswell and Skylake builds I cannot migrate to booting Linux with the new "GUB bypass" method. 

Some feedback as to what could cause the issue would be appreciated.

Oh by the way all Ubuntu 20.04 LTS Linux systems on all my machines have been upgraded to the latest available codebase, ie. Ubuntu 20.04....LTS...34. and all the respective config.plist files pass the ocvalidate sanity scan without any issues.

Needless to say, I am using the exact same OpenLinuxBoot.efi and ext4_x64.efi drivers and versions that are successfully deployed in my Comet Lake hacks.

 

Greetings Henties

 

Edit:

When attempting to boot into Linux from Haswell, with the OpenLinuxBoot.efi and ext4_x64.efi drivers, the hack not only hangs good and solid but while attempting to boot it actually screws up Grub to the extent that I need to reinstall GRUP with Linux's "Boot repair" in order to at least be able to get into Linux again via the old Misc--> Entries method.

 

 

 

 

I have the same problem with my E6540 (Haswell) and OC 7.3 .With both ext4 and openlinux all I get is a big nothing occurs, and I have to disable either ext4 or openlinux to be able to start OpenCore . The same thing occurs if I enable Misc:Security:OC_scan_allow_fs_ext with openlinux, ext4, or both. And I don't have any custom entries in misc:Entries .

Edited September 11, 2021 by Septendre

[Anto65]

have you tried adding to scan policy also 

 

 8192        0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems

Edited September 11, 2021 by antuneddu

[Muaitai]

I tried to use the Config Checker under Tools on the latest version 2.49.0.1 and got the following error:

 

Fatal error: Uncaught Exception: File not found - / file:///Volumes/Storage/Mac/Hackintosh/EFI%200.7.3/OC/Config.plist in /Users/xxxxxx/Library/Caches/org.altervista.mackie100projects.OpenCore-Configurator/ocs/src/OpenCorePlist.php:6 Stack trace: #0 /Users/xxxxxx/Library/Caches/org.altervista.mackie100projects.OpenCore-Configurator/ocs/ocs(28): OpenCorePlist->__construct('file:///Volumes...') #1 /Users/desantis/Library/Caches/org.altervista.mackie100projects.OpenCore-Configurator/ocs/ocs(36): {closure}() #2 {main} thrown in /Users/xxxxxx/Library/Caches/org.altervista.mackie100projects.OpenCore-Configurator/ocs/src/OpenCorePlist.php on line 6

 

I have updated to OpenCore 0.7.3 and everything is working flawlessly.

 

p.s.: the"xxxxxx"is where my computer name is and I replaced above.

Edited September 12, 2021 by Muaitai

[Septendre]

21 hours ago, antuneddu said:

have you tried adding to scan policy also 

 

 8192        0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems

I've tried it to no avail. Openlinux enable without parameters in scan policy = boot. Ext4_x64 without parameters = boot. Openlinux with scan parameters = nothing, same for ext4_x64. Openlinux + ext4_x64 = nothing. It simply won't start OpenCore 0.7.3 . As if the config.plist is non-existent on this Haswell Latitude E6540 with an ami aptioIV firmware

[Stefanalmare]

1 hour ago, Septendre said:

I've tried it to no avail. Openlinux enable without parameters in scan policy = boot. Ext4_x64 without parameters = boot. Openlinux with scan parameters = nothing, same for ext4_x64. Openlinux + ext4_x64 = nothing. It simply won't start OpenCore 0.7.3 . As if the config.plist is non-existent on this Haswell Latitude E6540 with an ami aptioIV firmware

Same in my coffee lake rig. No avail to make openlinux work.