Jump to content

OpenCore General Discussion


dgsga
8,887 posts in this topic

Recommended Posts

16 hours ago, mifjpn said:

Hello everyone.

Big Sur Beta 5 is out.

I succeeded in the upgrade installation from the USB memory using OpenCore.

Details are below.

BigSurBeta5, upgrade installation with USB memory

I don't understand. The procedure is simple. Download the latest BS version using: https://github.com/corpnewt/gibMacOS

Create a standard bootable USB stick just as you do with previous versions of macOS: https://support.apple.com/en-ca/HT201372

Mount the EFI partition from the USB stick and copy over your EFI directory

Reboot from the stick and then install to your chosen drive. If a previous version of macOS already exists, it will simply get updated.

  • Sad 1
Link to comment
Share on other sites

On 8/19/2020 at 2:16 AM, MacNB said:

 

I was asked the same question recently by someone else recently, and my answer was:

 

There are no settings in config.plist to set the SSD icons.

 

What I did was :

  1. Create the custom icons (based on the type of SSD/NVMe I have) using Photoshop.
  2. I used Image2Icon App to convert the .PNG file to .ICNS file. Actually, you can use OC's icnspack terminal command to convert the PNG to ICNS. That command is in OC's Utility folder.
  3. Mount the Preboot APFS partition. Copy the .icns file to the root of the partition and rename it .VolumeIcon.icns (NOTE there's a '.' in front of VolumeIcon.icns to make it a hidden file). If your partition HFS+, then simply copy the  .VolumeIcon.icns to the root of the HFS+ partition. If you wish to have custom NAME displayed for the OS then create a text file called .contentDetails at the root of the partition containing the required name (e.g. Windows 10 Pro).

If you are booting Windows then, you copy the Windows drive icon file (also called .VolumeIcon.icns) to the same folder as the bootmgfw.efi file. Typically, that file is the folder \EFI\Microsoft\Boot.

 

Currently you CANNOT set or change the background image of OpenCanopy.

You cannot add restart or shutdown icons at the bottom of the screen like clover.

Big Thanks Friend !

  • Like 1
Link to comment
Share on other sites

15 hours ago, Melab said:

I am away from my computer at the moment, but the only compiler commands that I saw in the build log (if I saw any at all) were for the BaseTools.

 

How do I change or specify build options? That hasn't been answered yet. If I want to build OpenCore with ENABLE_SECURE_BOOT set, how would I do that?

 

...and have you checked the Binaries folder to see what has been produced.

...where's the terminal output ?

 

...and where have you read/found that there's such a build flag as ENABLE_SECURE_BOOT ???

 

To enable secure boot with OC, it is not a matter of compiling it.

There's more to it. You need security keys.

 

Read the manual where you will find:
Note 1: While it may appear obvious, but you have to use an external method to verify OpenCore.efi and BOOTx64.efi for secure boot path. For this you are recommended to at least enable UEFI SecureBoot with a custom certificate, and sign OpenCore.efi and BOOTx64.efi with your custom key. More details on customising secure boot on modern firmwares can be found in Taming UEFI SecureBoot paper (in Russian).

 

it's work-in-progress. Read here.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Hi everyone. Is it possible to use Secure Boot with the latest OpenCore 0.6.1 commits?

 

Enabling it on my machine leads to a black screen on OpenCore.

But I noticed latest commits have stuff related to Secure Boot.

Link to comment
Share on other sites

On 8/19/2020 at 4:07 PM, meaganmargaret said:

 

Yea, me too.   I just backed off the latest version of 0.6.1 to see what workarounds there are.....

 

I have a syba aquantia 10g card and the latest version of 0.6.1 effectively disabled it....

I update openCore 0.6.1 still not work.I test now.

0.6.0 -worked

Edited by nmano
  • Like 1
Link to comment
Share on other sites

hi vit,

 

anything wrong on GIT ,  ./build_oc is asking for a password now ?

 

Quote

Building on Darwin

./build_oc.tool: line 386: iasl: command not found

Missing iasl!

Download the latest iasl from https://acpica.org/downloads

Install last tested version automatically?

Enter [Y]es to continue: Y

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100   151  100   151    0     0    545      0 --:--:-- --:--:-- --:--:--   545

100    24  100    24    0     0     55      0 --:--:-- --:--:-- --:--:--   303

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100   160  100   160    0     0    594      0 --:--:-- --:--:-- --:--:--   594

100  432k  100  432k    0     0   824k      0 --:--:-- --:--:-- --:--:--  824k

Password:


 

edit: seems it's too warm here and to answer myself :

compiing with a user account but the iasl installation requires admin permissions to access /usr/local/bin. 

 

So forget about my question above :)

 

Edited by texem
  • Confused 1
Link to comment
Share on other sites

51 minutes ago, texem said:

hi vit,

 

anything wrong on GIT ,  ./build_oc is asking for a password now ?

 


 

 

 

It was introduced since commit 9a0f1bc (I think) :) I type my user password (of course): no problem.

  • Like 1
Link to comment
Share on other sites

I have tried to update to Big Sur public beta 2 but am now facing a kernel panic.  Everything was working fine in public beta 1.  I have tried updating to the latest lilu 1.4.7 but that has not solved the issue.

Does anyone know what this error is in the pic attached?

IMG_2855 2.jpg

  • Sad 1
Link to comment
Share on other sites

Same here with Dev Beta 5 and OC 0.6.1, kernel panic. I've updated the kexts as well and I noticed that the most recent version of virtualsmc breaks my working setup with OC 0.6.0 on both Catalina and BS. 

 

Update 24/8/20:

Updated to nightly builds (24/8/20) of OC 0.6.1 and lilu, WG, virtualsmc and KP's are gone. Everything (10.15.6 and 11.0 Beta) without problems. 

Edited by Ron Lemmens
  • Like 1
Link to comment
Share on other sites

Hi all!

I have a weird issue with Big Sur.

The issue started with beta 1 and it was related to accessing the system preference panel --> Network: the panel opens soon but it took a long time (several minutes) to load the list of my two virtual networks (ethernet) on the left of the panel and nothing strange showed up in the mac os logs.

The network panel issue was there from beta 1 to beta 4.

In beta 5 the network panel and the list of networks loads faster, it's ok, but booting mac os takes a lot of time (like 4 to 5 minutes) with the following messages, that I think are related to this issue:

IOKit Daemon (kernelmanagerd) stall[0], (60s): 'ISA'
IOKit Daemon (kernelmanagerd) stall[1], (60s): 'ISA'
IOKit Daemon (kernelmanagerd) stall[2], (60s): 'ISA'
IOKit Daemon (kernelmanagerd) stall[3], (60s): 'ISA'

The same messages were displayed during installation and recovery but with stall time of 240s each.

I was using the latest versions of opencore and kexts (lilu, whatevergreen, applealc, virtualsmc), checked/updated every day.

I never had these problems with other versions of mac os.

I'm not really sure that this is related to the bootloader or to mac os, anyone with the same issue?

 

Here's a log from open core:
opencore-2020-08-23-093509.txt

Edited by ghost8282
Link to comment
Share on other sites

My Asus x99 pro won't boot OC BigSur install. I did manage to install Catalina and have tried to figure out what is blocking this install. In Dortania BigSir instructions there is an instruction for "some" Asus x299 boards to use a ssdt-rtco for areas Asus didn't write to, in the rtc, that might block booting. I have tried to figure out if my x99 is affected the same way, and I can't figure it out after days of trying and asking. If anyone has an idea of how I might proceed from my Catalina working OC 0.6.0 to BigSur , I appreciate it. It seems most all of us x99ers are stuck in the same spot. Thank you johnm

DSDT.aml

 

config.plist

Edited by jmacie
Link to comment
Share on other sites

On 8/22/2020 at 2:45 AM, nmano said:

I update openCore 0.6.1 still not work.I test now.

0.6.0 -worked

 

Agreed. 

 

I too reverted from 22 Aug v061 commit where Aquantia 10G Ethernet port was broken (SmallTree Ethernet was okay) back to final release of v060 and Aquantia working again. I need no kernel patches for Aquantia to work in Catalina with v060 (patches did not help in v061).

 

This is on TRX40 build, bare metal.

 

 

Edited by iGPU
  • Like 1
Link to comment
Share on other sites

45 minutes ago, iGPU said:

 

Agreed. 

 

I too reverted from 22 Aug v061 commit where Aquantia 10G Ethernet port was broken (SmallTree Ethernet was okay) back to final release of v060 and Aquantia working again. I need no kernel patches for Aquantia to work in Catalina with v060 (patches did not help in v061).

 

This is on TRX40 build, bare metal.

 

 

This kernel patch is working for my Aquantia 10Gb port on TRX40 BigSur beta 5 latest commit on OpenCore.

* com.apple.driver.AppleEthernetAquantiaAqtion
* Find: 0F84C002 0000
* Replace: 660F1F44 0000

 

Screen Shot 2020-08-23 at 7.49.25 PM.png

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

18 minutes ago, Pavo said:

This kernel patch is working for my Aquantia 10Gb port on TRX40 BigSur beta 5 latest commit on OpenCore.


* com.apple.driver.AppleEthernetAquantiaAqtion
* Find: 0F84C002 0000
* Replace: 660F1F44 0000

 

 

Ah, that's the difference: my latest patch was the same except Find was "0F84B003 0000". I will change and try again in Catalina. Thanks!

Link to comment
Share on other sites

Just now, iGPU said:

 

Ah, that's the difference: my latest patch was the same except Find was "0F84B003 0000". I will change and try again in Catalina. Thanks!

The patch I posted is for BigSur not Catalina.

  • Like 1
Link to comment
Share on other sites

24 minutes ago, Pavo said:

The patch I posted is for BigSur not Catalina.

 

Yes, I saw that you wrote for Big Sur, but thought I'd give it a try anyway. It does not work for Catalina (10.15.6). So OpenCore v061 is broken, at least for Catalina; and for v060 in Catalina, no patches are needed.

 

Thanks anyway.

 

BTW, does your TRX40 properly Shutdown? Mine does a panic reboot on Shutdown that I cannot seem to fix.

 

Edited by iGPU
  • Like 1
Link to comment
Share on other sites

10 minutes ago, iGPU said:

 

Yes, I saw that you wrote for Big Sur, but thought I'd give it a try anyway. It does not work for Catalina (10.15.6). So OpenCore v061 is broken, at least for Catalina; and for v060 in Catalina, no patches are needed.

 

Thanks anyway.

 

BTW, does your TRX40 properly Shutdown? Mine does a panic reboot on Shutdown that I cannot seem to fix.

 

Bare metal just is horrid on TRX40, yes it boots but the performance is not worth it in my opinion. It has a few issues and shutdown is one of them. I am sticking to VM setup.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

3 minutes ago, Pavo said:

Bare metal just is horrid on TRX40, yes it boots but the performance is not worth it in my opinion. It has a few issues and shutdown is one of them. I am sticking to VM setup.

 

I guess I've been lucky. Performance for me in Catalina (which I've not much liked until now) is almost identical to what I got in VM (both Cinebench 20 and LuxMark, for 2 GPUs, are identical, which makes me think the Geekbench scores are slightly lower for GPU is an artifact of the test).

 

Even the 2-Candle for Davinci Resolve was about the same: single GPU was identical for VM and bare metal (16 @ 64 nodes), the dual GPU was better in VM by ~15% (27 vs 33 @ 64 nodes), but I may have done the test poorly in VM (looking for peaks not steady state).

 

I've done no testing in Big Sur.

Link to comment
Share on other sites

Regarding the Acquantia issues. Which commit did it break? Could you provide a hash? Also, if you are trying to patch an injected kext, I do not believe it is expected to work (or has ever expected to to work before).

 

To get the first not working and last working commits please try the versions from here:

https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true

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

13 hours ago, vit9696 said:

Regarding the Acquantia issues. Which commit did it break? Could you provide a hash? Also, if you are trying to patch an injected kext, I do not believe it is expected to work (or has ever expected to to work before).

 

To get the first not working and last working commits please try the versions from here:

https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true

 

vit9696,

 

I just tested v061 ee7aaa3 Debug (top of list) in both Big Sur and Catalina (no kernel patch for Aquantia used for either macOS). Aquantia does not work in either macOS with this v061 debug (or release version). Attached is text file from debug version.

 

The last release that worked for Aquantia was Final v060 29 July (Catalina 10.15.6, no kernel patch needed; I did not test this v060 yet in Big Sur next section).

 

***

 

v061 459a769. Aquantia FAILED in Catalina. <--- FIRST failure

 

***

 

v061 0df1307. Aquantia works in Catalina. <--- Last successful

 

 

Edited by iGPU
sequential Aquantia testing of v061
  • Like 1
Link to comment
Share on other sites

I have been successfully running Big Sur Public Beta 1 for the last few weeks and it has been very solid and stable. Better than Catalina for me anyway. So I was confident to update to the new Public Beta 2. I read in the forums that it seemed the update went smooth as butter for everyone that tried. So I updated through system preferences. It proceeded normally until it got hung on a kernel panic on restart from the folder called Install MacOs made during the install. I then tried doing a clean install on the drive from my USB boot pen drive after downloading the full Beta 2 separately and transferring to my USB. That made no difference got the same kernel panic. I have also since tried updating Lilu to 1.4.7 as I compiled it myself. All my other kexts are the latest releases. I am on OC 0.6.0. I have attached photo of kernel panic. I apologize for the low quality of the photo.  Also my latest error log from Opencore bootlog.  and my latest config file.

Any assistance would be appreciated.

Also my SIP is locked. Not sure if that would cause a problem.

opencore-2020-08-23-103045.txt

config.plist

IMG_2855 2.jpg

Link to comment
Share on other sites

Right, if you installed Acquantia driver to /Library/Extensions, you will not be able to patch it when SecureBoot is enabled or on 11.0 at all.

- For 10.15 either set SecureBootModel to Disabled, or install patched Acquantia driver to OpenCore.

- For 11.0 your only option is to inject via OpenCore.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Hi Vit9696 and Download-Fritz

attached my open core debug log

 

I am using High Sierra 10.13.6 (17G14019) with all latest security fixes 

 

I have problem to activate my Nvidia web driver. All Nvidia kext are not loaded

One time I have had success but I can't reproduce because I have had to clear CMOS after trying OC 0.61 (22 august)

 

With this debug release system reboots early ( I haven't investigated why, but the weird thing is also restoring my old 060 working EFI system starts always in recovery mode (also selecting usual OSX booting icon)

Clearing CMOS solves this problem..but it destroys my previous working Nvidia web driver loaded
 

opencore-2020-08-24-065358.txt.zip

Link to comment
Share on other sites

7 hours ago, iGPU said:

 

I guess I've been lucky. Performance for me in Catalina (which I've not much liked until now) is almost identical to what I got in VM (both Cinebench 20 and LuxMark, for 2 GPUs, are identical, which makes me think the Geekbench scores are slightly lower for GPU is an artifact of the test).

 

Even the 2-Candle for Davinci Resolve was about the same: single GPU was identical for VM and bare metal (16 @ 64 nodes), the dual GPU was better in VM by ~15% (27 vs 33 @ 64 nodes), but I may have done the test poorly in VM (looking for peaks not steady state).

 

I've done no testing in Big Sur.

 

No you weren't lucky :)

Performance is worst only in some tests or games (much worst) but this is an old problem of Vanilla method for now unresolved

Pro app like BlackMAgic DaVinci or Premiere pro or rendering softwares (patched) work pretty the same

Cinebench15 (GPU part) and Firestrike or similar benchmark are worst

It is a great step forward to have both method working now in TRX40 system :)

 

Edited by Guest
Link to comment
Share on other sites

×
×
  • Create New...