Jump to content

OpenCore General Discussion


dgsga
8,887 posts in this topic

Recommended Posts

On 4/2/2020 at 4:29 PM, Morpheus NS said:

I have working Clover installation, but I am trying to get Opencore (0.5.6) working with my setup. But there is a problem, I get a very non-descriptive kernel panic if I try to boot without Cpuid1Mask and Cpuid1Data (Clover somehow works without it):

 

IMG_0189.png.c9daa06f91ac8780dfa87ec82e3d8172.png

 

If I try any FakeCPUID, the only thing I get is a black screen after boot picker.

 

Am I doing the FakeCPUID wrong?

For example, if I try FakeCPUID 0x0306A0 that would be:

A0060300 00000000 00000000 00000000

FFFFFFFF 00000000 00000000 00000000 ?

 

This is my config:

config.plist

 

Any ideas/suggestions? Thanks in advance.

 

Your black screen problem might be related to VBoxHfs.efi, takes time to kick in.(15-20s) I'd recommend switching to HfsPlus.efi, try from OcBinaryData(which gives me black screen, but might work for you), or try mine. You might also find helpful info here.

CPU.png.52b0455b52e946a0fecd599d968735af.png

HfsPlus.efi.zip

  • Like 2
Link to comment
Share on other sites

2 hours ago, hardcorehenry said:

Your black screen problem might be related to VBoxHfs.efi, takes time to kick in.(15-20s) I'd recommend switching to HfsPlus.efi, try from OcBinaryData(which gives me black screen, but might work for you), or try mine. You might also find helpful info here.

 

HfsPlus.efi.zip

 

OK, I've now tested every possible scenario (I think)...

 

 

1. Your HfsPlus.efi and VBoxHfs.efi give me exactly the same results:

a) no FakeCPUID - boot picker - choice of partition - kernel panic from the picture below

b) with ANY FakeCPUID (most of the time 0x0306A0 and 0x0106E0 (which is the only one that ever worked for me), but others too) - boot picker - choice of partition - black screen no matter how much time I wait

 

2. HfsPlus.efi that I was using previously (from OCBuilder, much larger in size):

a) with OR without FakeCPUID it gives me my motherboard logo on a dark background and nothing else, no picker

 

This is the kernel panic I get with your HfsPlus.efi and VBoxfs.efi without FakeCPUID:

151582818_Screenshot2020-04-05at15_02_55.thumb.png.b676a261e9ec9f13621c85afcc6181b4.png

 

I've included bootstrap and AVX patch from the link you provided, tested with and without them but nothing changes. This is the current version of my config.plist, I switched to OpenCore 0.5.7: config.plist (I enable/disable patches depending on whether I use FakeCPUID or not, but I tried othe combinations as well).

 

Everything works with Clover, even Power Management is fine without FakeCPUID

 

1628784496_Screenshot2020-04-05at15_15_45.thumb.png.b262cc9fc7f84e765697e4312f1ca4a3.png

Edited by Morpheus NS
additional info
  • Like 1
Link to comment
Share on other sites

38 minutes ago, Morpheus NS said:

 

OK, I've now tested every possible scenario (I think)...

 

 

1. Your HfsPlus.efi and VBoxHfs.efi give me exactly the same results:

a) no FakeCPUID - boot picker - choice of partition - kernel panic from the picture below

b) with ANY FakeCPUID (most of the time 0x0306A0 and 0x0106E0 (which is the only one that ever worked for me), but others too) - boot picker - choice of partition - black screen no matter how much time I wait

 

2. HfsPlus.efi that I was using previously (from OCBuilder, much larger in size):

a) with OR without FakeCPUID it gives me my motherboard logo on a dark background and nothing else, no picker

 

This is the kernel panic I get with your HfsPlus.efi and VBoxfs.efi without FakeCPUID:

151582818_Screenshot2020-04-05at15_02_55.thumb.png.b676a261e9ec9f13621c85afcc6181b4.png

 

I've included bootstrap and AVX patch from the link you provided, tested with and without them but nothing changes. This is the current version of my config.plist, I switched to OpenCore 0.5.7: config.plist (I enable/disable patches depending on whether I use FakeCPUID or not, but I tried othe combinations as well).

 

Everything works with Clover, even Power Management is fine without FakeCPUID

 

1628784496_Screenshot2020-04-05at15_15_45.thumb.png.b262cc9fc7f84e765697e4312f1ca4a3.png

hi you have to use ssdttime to produce oc.plist which you have to add to your regular plist to get some of those ism files to work properly also when you get there you will find out that  you python is not setup prperly so good luck with that

Link to comment
Share on other sites

Has anyone else had any problems with Windows drive detection with recent commits of Opencore? With commit eceb36f (OcBootManagementLib: Rename BOOTCAMP Windows to Windows, on 13th March) everything works fine but if I upgrade to the latest commit and then select the Windows drive I get the blue recovery screen with a message saying 'the PC needs to be repaired, an unexpected error has occurred'. If I boot the same drive direct from the bios boot selector the system loads fine. I have windows 10 installed on a separate drive so it doesn't pollute the Mac side of things. Reverting back to the old OC version corrects this issue. Any ideas?

Edited by dgsga
Link to comment
Share on other sites

Unfortunately, it didn't help. I've tried using debug version of OpenCore and every time it halts at the same place:

 

73:704 00:099 OCSMC: SmcReadValue Key 4D535463 Size 1
73:795 00:090 OCSMC: SmcReadValue Key 4D534163 Size 2

 

From Google search, it seams to have something to do with KASLR, so I tried adding slide=0 (should be the correct value) to my boot arguments, it didn't help either.

 

I am too stubborn to give up, but I am running out of ideas... thank you for your help so far. :)

Link to comment
Share on other sites

2 hours ago, texem said:

this is fixed since today, read here .

 

@texem, still can’t get it to work here with the latest commit. Would you mind posting a screenshot of your booter quirks? Thanks.

Link to comment
Share on other sites

@vit9696 I have been following bugtracker #491 to try to solve my Windows 10 boot failure and have found that if I revert commit f963012 (the 4K section alignment in Open Runtime) it fixes the failure on my rig. I did try the latest commit with the latest version of mtoc (949.0.1) but couldn't get past the BSOD with any combination of booter quirks. Am I missing something here?

Edited by dgsga
Link to comment
Share on other sites

21 minutes ago, dgsga said:

but couldn't get past the BSOD with any combination of booter quirks. Am I missing something here?

If you are compiling as of now, after the check for correct mtoc has been enforced, and are still experiencing issues with Windows booting, please confirm this, and if it is the same case, follow vit's debug instructions for this problem and post the resulting files in the GitHub issue. Thanks!

Edited by Pene
  • Like 2
Link to comment
Share on other sites

Why would you guys bloat this thread with OpenCore 0.5.7 issues "of work in progress stuff" when you all "crystal" clearly see that commits are being added constantly during the day like in minutes and they are working on that  ?

 

They have been working hard most of the day as i followed the commits, Let them do their valuable work that they do for free for all of us, show them some respect.

 

No offence but it's really getting hard to also see valuable posts/solution to real problems, having to scroll pages and pages everyday for such repeated things over and over again.

  • Like 8
Link to comment
Share on other sites

14 hours ago, Matgen84 said:

 

Take a look to  configuration.pdf

I took a look and it says to edit the contentDetails file for the boot entries. Unfortunately still doesn't tell me where to look for it or as another user said to create it but I dont' know where this should be put in after it's created nor is there a sample somewhere I think.

Link to comment
Share on other sites

@telepati Look I/we get pinged on several channels several times a day. And the more of those are disposable things like "bug reports" about explicitly development branches literally during active development (talking about minutes, not even hours or days), the more appealing it is to not react to pings of any sort at all. I do not want to hear any more "bug reports" about OpenCanopy, especially not of its development branch, until it's mature for daily use.

Link to comment
Share on other sites

×
×
  • Create New...