OpenCore General Discussion

[Andres ZeroCross]

Hi @Download-Fritz and @vit9696

I need to ask about one thing

1. I have HP Notebook with SkyLake generations.
2. The UEFI entry in BIOS is only about "OS Boot Manager" for whatever of your UEFI OS. And if you installed Windows, Linux or add OpenCore Bootloader, then this "OS Boot Manager" only will read and run from "EFI/Microsoft/Boot/bootmgfw.efi" only and will ignore other OS Boot Files ("EFI/BOOT/BOOTx64.efi") because i have change BOOTx64.efi with OpenCore files and still boot from Windows.
3. I have set "Misc/Security/BootProtect=Bootstrap" and temporary remove "Microsoft" folder, and it boot to OpenCore but after several reboot, i can't see "OpenCore" entry in BIOS. As i expected,, this "OS Boot Manager" take over of UEFI Boot OS.

So, can you give me another solution for this???

[ghost8282]

12 hours ago, Stefanalmare said:

Nope! I changed to 656E5F55 533A30 - en_US:0, and the same. Recovery = gray screen. I do something wrong?

it's not with underscore (Edit: I'm not sure if with underscore is ok), it should be en-US:0 (edit: with "-" I'm 100% sure it works, so it worth trying with "-")

Field in config.plist is data so you need to write ZW4tVVM6MA==

If it doesn't work try with empty field.

A nvram reset could help too.

Edited October 27, 2020 by ghost8282

[Matgen84]

11 hours ago, Stefanalmare said:

Nope! I changed to 656E5F55 533A30 - en_US:0, and the same. Recovery = gray screen. I do something wrong?

 

About grey screen as macrumors forums and others sites said, the issue as many already reported, is due to the Beta 10 installer language, currently to avoid grey screen should be selected English as main installer recovery language.  If you don't want grey screen, wait and see golden master or Big Sur release.

Edited October 27, 2020 by Matgen84

[naiclub]

5 minutes ago, Matgen84 said:

 

About grey screen as macrumors forums and others sites said, the issue as many already reported, is due to the Beta 10 installer language, currently to avoid grey screen should be selected English as main installer recovery language.  If you don't want grey screen, wait and see golden master or Big Sur release.

As stated, all are correct. Must be selected in the default English language only. Never use any other language.

Spoiler

OC is now compatible with mojave Catalina big sur, but can not access it High_Sierra by KP.

[Stefanalmare]

3 hours ago, Andres ZeroCross said:

Hi @Download-Fritz and @vit9696

I need to ask about one thing

1. I have HP Notebook with SkyLake generations.
2. The UEFI entry in BIOS is only about "OS Boot Manager" for whatever of your UEFI OS. And if you installed Windows, Linux or add OpenCore Bootloader, then this "OS Boot Manager" only will read and run from "EFI/Microsoft/Boot/bootmgfw.efi" only and will ignore other OS Boot Files ("EFI/BOOT/BOOTx64.efi") because i have change BOOTx64.efi with OpenCore files and still boot from Windows.
3. I have set "Misc/Security/BootProtect=Bootstrap" and temporary remove "Microsoft" folder, and it boot to OpenCore but after several reboot, i can't see "OpenCore" entry in BIOS. As i expected,, this "OS Boot Manager" take over of UEFI Boot OS.

So, can you give me another solution for this???

I use rEFInd on my HP. Same buggy BIOS, but with rEFInd I have no problem booting Windows and OpenCore (also, I can boot Windows from OpenCore).

[gorans]

17 hours ago, naiclub said:

Good news for me now opencore no longer causes the bios to be locked. Many thanks to developers.

I wish it was a bit sooner.
At least I have a new hack.

[Deanor30]

Hi Folks, 

  Quick question, has anyone had any success installing Catalina on a DIY apfs fusion drive. I made an attempt to install Catalina on same using a working opencore 6.2 setup but when the install screen reboots opencore cannot detect the APFS fusion drive. I have seen a few forums where people use APFS.efi in attempts but have seen no forum where it works. 

[chris1111]

Some body explain me why booting OC to windows 10 with a perfect DSDT.aml result not boot spinning wheel to the LOGO 

With out DSDT its boot natively No need Entry and Icon stuff  and the same DSDT.aml , same kext booting with Clover its boot correct

this is a non sense I really don't understand

Edited October 29, 2020 by chris1111

[Avery B]

7 hours ago, chris1111 said:

Some body explain me why booting OC to windows 10 with a perfect DSDT.aml result not boot spinning wheel to the LOGO 

With out DSDT its boot natively No need Entry and Icon stuff  and the same DSDT.aml , same kext booting with Clover its boot correct

this is a non sense I really don't understand

Opencore injects acpi no matter which OS you boot through it - so it's likely something modified within the DSDT which windows doesn't like.

[ghost8282]

 

 

Maybe this is off topic, this is related to smb transfers and kernel panics, not sure if it's an apple bug, an error in oc config or what..Others seem to have no issues with smb and big sur.

I started having issues from beta 6 (included).

For some files, big sur fails with -8084 error, sometimes there's a kernel panic.

Transfers of that same files work with no issue in Catalina.

Here is an example of a kernel panic:

panic(cpu 11 caller 0x<ptr>): "Zone element 0xffffff9379469600 was modified after free for zone kext.kalloc.512: " "Expected element to be cleared"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-7195.50.3.201.1/osfmk/kern/zalloc.c:1968
Backtrace (CPU 11), Frame : Return Address
0xffffffa0ea4cb120 : 0xffffff8004eb76dd mach_kernel : _handle_debugger_trap + 0x3dd
0xffffffa0ea4cb170 : 0xffffff8004ffa0e3 mach_kernel : _kdp_i386_trap + 0x143
0xffffffa0ea4cb1b0 : 0xffffff8004fea71a mach_kernel : _kernel_trap + 0x55a
0xffffffa0ea4cb200 : 0xffffff8008c12924 as.vit9696.VirtualSMC : __ZN18VirtualSMCProvider10kernelTrapI22x86_saved_state_1010_tEEvPT_Pm + 0x454
0xffffffa0ea4cb280 : 0xffffff8004e5ca2f mach_kernel : _return_from_trap + 0xff
0xffffffa0ea4cb2a0 : 0xffffff8004eb6f7d mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffa0ea4cb3c0 : 0xffffff8004eb7268 mach_kernel : _panic_trap_to_debugger + 0x268
0xffffffa0ea4cb430 : 0xffffff80056b9c9a mach_kernel : _panic + 0x54
0xffffffa0ea4cb4a0 : 0xffffff80056ba2a4 mach_kernel : _kheap_temp_leak_panic + 0x4fa
0xffffffa0ea4cb4b0 : 0xffffff8004f1303a mach_kernel : _zone_require + 0x12a
0xffffffa0ea4cb4e0 : 0xffffff8004f14262 mach_kernel : _zdestroy + 0x1062
0xffffffa0ea4cb560 : 0xffffff8004ec5c64 mach_kernel : _task_get_exception_ports_from_user + 0x554
0xffffffa0ea4cb5b0 : 0xffffff800543fd63 mach_kernel : __MALLOC + 0x33
0xffffffa0ea4cb5d0 : 0xffffff7fa52f92ad com.apple.filesystems.smbfs : _smb2_rq_alloc + 0x32
0xffffffa0ea4cb660 : 0xffffff7fa5300908 com.apple.filesystems.smbfs : _smb2_smb_query_dir + 0x3b
0xffffffa0ea4cb6d0 : 0xffffff7fa5307eeb com.apple.filesystems.smbfs : _smb2fs_smb_cmpd_query_dir_one + 0x331
0xffffffa0ea4cb7a0 : 0xffffff7fa52c18f8 com.apple.filesystems.smbfs : _smbfs_lookup + 0x3f3
0xffffffa0ea4cb830 : 0xffffff7fa52ce01a com.apple.filesystems.smbfs : _smbfs_update_cache + 0xe6
0xffffffa0ea4cb960 : 0xffffff7fa52cf60e com.apple.filesystems.smbfs : _smbfs_getattr + 0x82
0xffffffa0ea4cb9e0 : 0xffffff7fa52d16ad com.apple.filesystems.smbfs : _smbfs_vnop_getattr + 0x1d3
0xffffffa0ea4cba20 : 0xffffff800517644e mach_kernel : _vnode_getattr + 0xae
0xffffffa0ea4cbaa0 : 0xffffff8005118b99 mach_kernel : _fgetattrlist + 0x6c9
0xffffffa0ea4cbb80 : 0xffffff800511c691 mach_kernel : _getattrlistbulk + 0xb61
0xffffffa0ea4cbde0 : 0xffffff800511c26c mach_kernel : _getattrlistbulk + 0x73c
0xffffffa0ea4cbf40 : 0xffffff8005564bfb mach_kernel : _unix_syscall64 + 0x27b
0xffffffa0ea4cbfa0 : 0xffffff8004e5d1f6 mach_kernel : _hndl_unix_scall64 + 0x16
      Kernel Extensions in backtrace:
         as.vit9696.VirtualSMC(1.1.8)[F538DE46-9C0D-3926-B33C-C9FFDBDA1FE8]@0xffffff8008c03000->0xffffff8008c29fff
            dependency: as.vit9696.Lilu(1.4.9)[B6D37460-150C-38A3-9285-670846DCE358]@0xffffff8008b7d000->0xffffff8008c00fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[B9AEA347-5086-364F-932A-211B8CF8C661]@0xffffff80072af000->0xffffff80072b0fff
         com.apple.filesystems.smbfs(3.4.1)[FE7EA393-7E63-3221-B418-ACDA34A2A664]@0xffffff7fa52b5000->0xffffff7fa531efff
            dependency: com.apple.kec.corecrypto(1.0)[F0B4250F-76E4-34C4-BCBC-344BFC372FA2]@0xffffff8007fd8000->0xffffff8008064fff
            dependency: com.apple.kext.triggers(1.0)[F0CF9E2C-553D-3F1D-8B95-71394A24526A]@0xffffff7fa5323000->0xffffff7fa5325fff

Process name corresponding to current thread: find
Boot args: -v keepsyms=1 debug=0x100 

Mac OS version:
20B5012d

Kernel version:
Darwin Kernel Version 20.1.0: Sat Oct 24 21:21:05 PDT 2020; root:xnu-7195.50.3.201.1~1/RELEASE_X86_64
Kernel UUID: 2BA1C8BD-9C95-3FA7-B7A4-F991BB96D49C
KernelCache slide: 0x0000000004c00000
KernelCache base:  0xffffff8004e00000
Kernel slide:      0x0000000004c10000
Kernel text base:  0xffffff8004e10000
__HIB  text base: 0xffffff8004d00000
System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)
System shutdown begun: NO
Panic diags file available: YES (0x0)
Hibernation exit count: 0

System uptime in nanoseconds: 2333691511522
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x0000021f5ada88d8
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x0000035211e4aa51 0x0000000000000000

Wrong OC configuration, smb bug or other? What do you think?

[chris1111]

4 hours ago, 1Revenger1 said:

Opencore injects acpi no matter which OS you boot through it - so it's likely something modified within the DSDT which windows doesn't like.

How to explain that with Clover he likes the same DSDT

EDIT *** 

Boot windows with DSDT.aml is Fix  add SSDT-XOSI.aml

Edited October 29, 2020 by chris1111
Boot windows with DSDT.aml is Fix  add SSDT-XOSI.aml

[Mike Ranger]

Hi

I have a question about how OC is doing kext patches. My question specifically is, where does the find / replace happen?

The background of the question:

I want to patch the info.plist of a kext (AMD Graphic Driver) to change some properties in info.plist within the kext I want to patch.

So does the find / replace also apply to the info.plist itself? Can I patch info.plist within the kext?

 

Thanks, Mike

 

Edit.... checking some more, it seems that InfoPlistPatch was the function in Clover that could do that.... is there another way to achieve that in OC? Maybe there is something I have overseen here.

 

Edit.... seems like a plist.info only kext is the solution, will further investigate, injection by device properties does not work it seems

Edited October 30, 2020 by Mike Ranger

[Sherlocks]

hi i wonder how can i get SYSLOG like this in log?

https://github.com/acidanthera/VirtualSMC/blob/master/Sensors/SMCBatteryManager/BatteryManager.cpp#L33

i tried to get SYSLOG log. but always fail. i don't know where is it.

where can i found this log history?

 

i added like this

-lgwmidbg -liludbg -vsmcdbg msgbuf=1048576 -sbatdbg

 

i can see only this part like this. "DBDLOG"

https://github.com/acidanthera/VirtualSMC/blob/master/Sensors/SMCBatteryManager/BatteryManager.cpp#L52

[mhaeuser]

@Sherlocks What does this have to do with OC...?

 

@Mike Ranger PLIST patches indeed are unsupported, dev props should work fine. If not, please detail why PLIST patches are required despite alternatives being available.

[MacNB]

8 hours ago, Mike Ranger said:

Hi

I have a question about how OC is doing kext patches. My question specifically is, where does the find / replace happen?

The background of the question:

I want to patch the info.plist of a kext (AMD Graphic Driver) to change some properties in info.plist within the kext I want to patch.

So does the find / replace also apply to the info.plist itself? Can I patch info.plist within the kext?

 

Thanks, Mike

 

Edit.... checking some more, it seems that InfoPlistPatch was the function in Clover that could do that.... is there another way to achieve that in OC? Maybe there is something I have overseen here.

 

Edit.... seems like a plist.info only kext is the solution, will further investigate, injection by device properties does not work it seems

 

Device Properties Inject is the way to go.

 

I helped someone with Clover's equivalent of Graphics->Inject->Nvidia=TRUE (which does not exist in OC).

See the config.plist file I posted there as an example. It uses Device Properties Injection.

 

Edited October 30, 2020 by MacNB

[Mike Ranger]

Thanks... well... some properties did not work for me.

I tried to inject some ATI properties, that were already defined by the driver it seems. So injecting did for some reason not change these values through device properties.

I created now a kext with info.plist that could successfully change the value (if changing the value makes sense is another question of course).

I agree that usually,the way to go is with Device Properties.

 

Regards, Mike

 

[hardcorehenry]

34 minutes ago, Mike Ranger said:

Thanks... well... some properties did not work for me.

I tried to inject some ATI properties, that were already defined by the driver it seems. So injecting did for some reason not change these values through device properties.

I created now a kext with info.plist that could successfully change the value (if changing the value makes sense is another question of course).

I agree that usually,the way to go is with Device Properties.

 

Regards, Mike

 

 

This Sample.dsl might give you some hints.

[0xAE9]

OpenGL issues with iGPU drivers? Happens on many apps like OpenGL Extensions Viewer. Using Comet Lake iMac 20,2 smbios, tried 20,1 same problem.

 

Log: https://ybin.me/p/4d1102d1d7df65f8#lA3b21Z7Kduq1D/E4e/x1Cp6SW4AfwAaP6pV8GNGuT4=

 

Edit:

Spoof device-id 923E0000 if you have Comet Lake. That will fix it for now

Edited October 30, 2020 by 0xAE9

[PlutoDelic]

Would anyone know by any chance why a Clear NVRAM from OpenCore would result in very slow Windows Shutdowns/Restarts/Sleeps/Wakeups?

 

Windows is by far the least standard respecting OS out there. I know that its GPT usage is quite different from Linux and macOS, and for some reason, every time i tries to fix its Boot Entry on the UEFI list, it will inject the correct path for its EFI file, but on the wrong EFI partition, it chooses the OC disk/partition. Obviously, there is no file there as both OS's reside on their own EFI/DISK. This habit choosing the wrong location seems to happen with a few Duet/Linux users too.

 

I highly doubt if this is specifically an OC issue at all, but i'm just trying to troubleshoot it.

 

EDIT: Just to clarify, i dont boot Windows through OC.

Edited October 31, 2020 by PlutoDelic

[mhaeuser]

@PlutoDelic Never heard about that. Does it vanish after the next reboot?

[PlutoDelic]

@Download-Fritz You mean the Windows entry? Only if i manually remove it or clear NVRAM. A workaround i made, i let the automatic entry stay on the boot list but just leave it as the last one, and use a manually created one as the first. I can live with that.

 

The Windows issue arose on the first NVRAM clearance, this was in the early boot trials to get the installer working. While i've settled with the complete/post install, or should i say, on the last NVRAM clearance, i thought maybe it would settle down. It's weird cause Windows is quite fast and rests on a x4 NVMe, where as the macOS in a 1x NVMe (port limitation), but macOS boots (and shutdowns etc) a lot faster than Windows. I've used the opportunity to upgrade to the latest Windows too to see if that would bring me any changes, but unfortunately not.

 

This could most probably either be a Windows UEFI implementation that just doesnt give a damn about standards, or the BIOS Firmware being what they usually are, BAD (Dell Latitude e7470).

 

 

Edited November 1, 2020 by PlutoDelic

[anonymous writer]

Hello OpenCore team.
I have a question about SecureBootModel. Is there a way to see the status of SecureBootModel under OSX?
SecureBootModel is active on may hack, but I have no idea where I can see under OSX the status of SecureBootModel.

[Avery B]

11 hours ago, anonymous writer said:

Hello OpenCore team.
I have a question about SecureBootModel. Is there a way to see the status of SecureBootModel under OSX?
SecureBootModel is active on may hack, but I have no idea where I can see under OSX the status of SecureBootModel.

No there isn't afaik. You could check the logs from boot.efi though - should say what model secure boot is used, if any (ie j680.im4 or some other statement).

[Nemphys]

Is anyone else experiencing slow boot times in Big Sur 11.0.1 Beta due to "kextcache -Boot -U /" being executed on every single boot?

It slows down my NUC8i7BEH boot by ~15 seconds...

Running Opencore 0.6.3.

[MICKHAEL]

Hi @mikorist, how you solved "tx_flush" errors?
Thanks