Jump to content

OpenCore General Discussion


dgsga
8,887 posts in this topic

Recommended Posts

@Download-Fritz @vit9696 i need your help

Device name

Dell XPS 13 7390
Processor : Intel Core i7 10710U

the problem is always stuck at ExitBSStart:xxx

I have tried using combination
AvoidRuntimeDefrag = YeS
EnableSafeModeSlide = Yes
EnableWriteUnprotector = Yes
ProtectUefiServices = Yes
RebuildAppleMemoryMap = Yes
SyncRuntimePermissions = Yes

and 


AvoidRuntimeDefrag = YeS
EnableSafeModeSlide = Yes
EnableWriteUnprotector = Yes
ProtectUefiServices = Yes
SetupVirtualMap = Yes
SyncRuntimePermissions = Yes

 

I have tried to use "ForceExitBootServices=Yes" for both combination above with no result, still can't bypass the error.
i have installed Commetlake platform for HP and Asus and never see this problem,,
image.thumb.png.841a1c3f5a73ab0c87b834f017ff87e0.png
I attach debug output
 

 

opencore-2020-10-06-235644.txt

config.plist

Edited by Andres ZeroCross
Link to comment
Share on other sites

1 hour ago, Andres ZeroCross said:

@Download-Fritz @vit9696 i need your help

Device name

Dell XPS 13 7390
Processor : Intel Core i7 10710U

the problem is always stuck at ExitBSStart:xxx

I have tried using combination
AvoidRuntimeDefrag = YeS
EnableSafeModeSlide = Yes
EnableWriteUnprotector = Yes
ProtectUefiServices = Yes
RebuildAppleMemoryMap = Yes
SyncRuntimePermissions = Yes

and 


AvoidRuntimeDefrag = YeS
EnableSafeModeSlide = Yes
EnableWriteUnprotector = Yes
ProtectUefiServices = Yes
SetupVirtualMap = Yes
SyncRuntimePermissions = Yes


10000 series laptops/devices can have issues with SetupVirtualMap - I'd try both combos with it disabled.

Link to comment
Share on other sites

Hello!
Currently running 0.63 nightly with a Mald0n DSDT.
Been using OpenCore since 0.58

I have Window10 on a separate NVMe drive that is bootable thanks to bootstrap.efi

Has OpenCore reached the state of development where we can make Windows ignore the DSDT?
The reason I ask:
When I avoid the OpenCore boot entry and boot to the Windows Boot Manager directly, everything works as expected in Windows
When I boot to windows via OpenCore, the only thing that does not work is my onboard audio and Device Manager in Windows states there are not enough resources to load that driver correctly.

Edited by Musicalchairs
Link to comment
Share on other sites

8 minutes ago, Musicalchairs said:

Has OpenCore reached the state of development where we can make Windows ignore the DSDT?

This has nothing to do with "stage of development", infact such a quirk existed before and was deprecated after the documentations were refined enough to not need it anymore.

9 minutes ago, Musicalchairs said:

When I boot to windows via OpenCore, the only thing that does not work is my onboard audio and Device Manager in Windows states there are not enough resources to load that driver correctly.

You probably have some weird patch you do not even really need. OC really is made for the "minimal SSDT" approach where you leave DSDT alone and add a minimal amount of conditional SSDTs.

Link to comment
Share on other sites

2 minutes ago, Download-Fritz said:

This has nothing to do with "stage of development", infact such a quirk existed before and was deprecated after the documentations were refined enough to not need it anymore.

You probably have some weird patch you do not even really need. OC really is made for the "minimal SSDT" approach where you leave DSDT alone and add a minimal amount of conditional SSDTs.

Good info, Thank you!
Suspected it was something in my DSDT that did not need to be there (or the DSDT itself should be removed and I should attempt to reach zero ACPI errors with SSDT only.
 

  • Like 1
Link to comment
Share on other sites

670341648_ScreenShot2020-10-24at04_13_43.thumb.png.d97b4d712fb8c80dbfc065d10ab6d51d.png

On 10/22/2020 at 11:16 PM, Download-Fritz said:

This has nothing to do with "stage of development", infact such a quirk existed before and was deprecated after the documentations were refined enough to not need it anymore.

You probably have some weird patch you do not even really need. OC really is made for the "minimal SSDT" approach where you leave DSDT alone and add a minimal amount of conditional SSDTs.


Challenge accepted:
DSDT free now after challenging myself to read the https://dortania.github.io/OpenCore-Post-Install/
opencore-2020-10-24-v0.63-Debug-SSDT's_Only+USBMap.kext&SATA-unsupported.kext for System Information cosmetic reasons only.
Windows 10 now acts as though it isn't living alongside macOS.
*Removed all personal info from PlatformInfo

 

1447426960_ScreenShot2020-10-24at10_19_50.thumb.png.f313b06b8f59b85d09026d0947ef83c4.png 1054718989_ScreenShot2020-10-24at10_27_53.thumb.png.6ed5b4bddcf6584df6a2a21e0e873b57.png

EFI.zip

Edited by Musicalchairs
Cleaned it up a bit more by separating SSDT-EXT.aml into what was actually needed if I am not concerned about the cosmetic appearance of System Profiler
  • Like 1
Link to comment
Share on other sites

1 hour ago, Stefanalmare said:

Hi all! Does anybody have empty grey screen on recovery BS beta 10? It happen on my HP Probook 4540s. Just on beta 10.

Did you fill in the Language Section in the config.plist? If left blank will sometimes hang and cause a grey screen.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Stefanalmare said:

Hi all! Does anybody have empty grey screen on recovery BS beta 10? It happen on my HP Probook 4540s. Just on beta 10.

 

6 minutes ago, eSaF said:

Did you fill in the Language Section in the config.plist? If left blank will sometimes hang and cause a grey screen.

 

It's a Apple "Bug": all the forums talk about this. Beta 10 comes with US English only for recovery mode, for a clean installation. So you have to choose only this language.

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

And remember to clean in the config.plist the prev-lang:kbd field.

 

Oh sorry just read better esaf comment: in my case if language is forced in the config.plist (other than english) grey screen; if left empty all is ok (and choosing english in the language selector).

Edited by ghost8282
  • Like 3
Link to comment
Share on other sites

4 hours ago, Matgen84 said:

 

 

It's a Apple "Bug": all the forums talk about this. Beta 10 comes with US English only for recovery mode, for a clean installation. So you have to choose only this language.

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

Link to comment
Share on other sites

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???

Link to comment
Share on other sites

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 by ghost8282
Link to comment
Share on other sites

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 by Matgen84
  • Like 1
Link to comment
Share on other sites

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

122780391_762880014568466_1807573105298013635_n.thumb.jpg.d1549ef1d8b6ed94ef62dae6be56f817.jpg

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

  • Like 1
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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 by chris1111
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

 

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?

Link to comment
Share on other sites

×
×
  • Create New...