OpenCore General Discussion

[Pavo]

@SavageAUS the APFS seal can also effect updates not showing up, check your seal to see if its broken or not. Use diskutil apfs list to check if snapshot is sealed or not.

[SavageAUS]

[mention=1083558]SavageAUS[/mention] Hmm, still possible it's a sort of staged rollout, I don't know how Apple decides who gets which update when. As nobody else reported issues and afaik a few people upgraded already, I'd probably blame it and ask you to keep an eye in it (and wait a few days next time) in the future.

Yeah I was assuming the same thing, so I waited an extra day and it still did not appear in system preferences until I booted back to my old clover EFI. So within 5 minutes it was not appearing then it was....Coincidental? Perhaps. Error on my behalf? Perhaps. I was just reporting what was happening to my machine at the time.
I appreciate the responses.


Sent from my iPhone using Tapatalk

[HenryV]

csr-active-config change to 6708000 in OC made the difference when updates didn't show.

[ghost8282]

33 minutes ago, HenryV said:

csr-active-config change to 6708000 in OC made the difference when updates didn't show.

Sorry may be (and probably it is) a stupid question, but why we need this into opencore? can't we just disable or enable sip through terminal?

[1Revenger1]

8 minutes ago, ghost8282 said:

Sorry may be (and probably it is) a stupid question, but why we need this into opencore? can't we just disable or enable sip through terminal?

There are specifically a few bits being set within csr-active-util (thus disabling that part of SIP) that can cause issues.
Iirc, specifically CSR_ALLOW_UNAUTHENTICATED_ROOT (bit 11) and CSR_ALLOW_APPLE_INTERNAL (bit 4) I've heard can cause issues, though admittedly I haven't really looked into it.
You can find out what all the different SIP values do here. CSR_DISABLE_FLAGS looks like the flags that get set when you just disable SIP through terminal.
Note that these are all bitmasks - if you want to convert them more closely to a value your used to, use a calculator to set whatever bits you want to use (both Windows and macOS have a programmer mode which allows you to set each bit specifically).
You'll get a hex value out of it, and if you swap the endianness, you'll get a value you can put into OC.

For example, if you have 0x00000608, (bit 3, 9, and 10 set), swapping the endiannes makes it 0x08060000 (split it into pairs of digits - 00 00 06 08, then reverse the order of those pairs. 00 00 06 08 -> 08 06 00 00 -> 0x08060000)
 

[ghost8282]

Hi all!

today is test day

As my signature suggests, I'm running mac os big sur on qemu.

The hard drive of this virtual machine was a sparse image file, a vdisk.

Today I tried to passthrough to the virtual machine my Marvell sata controller, so to get rid of the sparse image file, and have mac os installed in a more native hackintosh.

Before switching, I added the 3rd party sata kext to opencore and booted from the sparse image file: my marvell 88SE9230 sata controller was recognized, without nothing attached, ok that's good.

I backupped the sparse image file, deleted the partition of the disk in which the sparse image file was, and restored the backupped sparse image file to this hard drive (ssd), connected to the marvell controller, with dd command.

Booted and forced the opencore bootpicker to show: all entries related to mac os were there: primary BigSur disk and recovery partition.

However,

1- if I select Big Sur the system doesn't boot, without verbose after some time I have the prohibited symbol with the link to apple support for startup: with verbose mode on I have the last lines with "CNTL Auth fail"

2- I can boot into recovery but utility disk doesn't show my sata disk...

 

I'm attaching the opencore debug log, last line is "AmiShimTimerBoostExit changed current period to 100000"

I cannot find why the disk isn't detected by mac os, maybe you can help me in fixing this.

 

Thanks and have a good day!

 

Nevermind! I solved it by changing the target of the sata controller in libvirt to Bus 0x01, before it was on bus 0x00 and it didn't start

opencore-2021-05-15-120302.txt

Edited May 30, 2021 by ghost8282

[jinbingmao]

Changed OpenCanopy preferred image set to `Acidanthera\GoldenGate`。 

 

PickerVariant   

• Default — Acidanthera\GoldenGate.

•  

[Guest 5T33Z0]

I had an idea for an ease of use configuration feature in OpenCore - a field called "CPU Family" or something like that. This should contain fixed rules/presets for booter and kernel quirks. For example you enter `CometLake`or `Skylake`and it automatically enables the necessary quirks for the chosen CPU family in th background.

[Matgen84]

40 minutes ago, 5T33Z0 said:

I had an idea for an ease of use configuration feature in OpenCore - a field called "CPU Family" or something like that. This should contain fixed rules/presets for booter and kernel quirks. For example you enter `CometLake`or `Skylake`and it automatically enables the necessary quirks for the chosen CPU family in th background.

 

Have a look to Pavo-IM/OC-Gen X ont Github.  I don't test or use it.

Edited May 15, 2021 by Matgen84

[STLVNUB]

1 hour ago, 5T33Z0 said:

I had an idea for an ease of use configuration feature in OpenCore - a field called "CPU Family" or something like that. This should contain fixed rules/presets for booter and kernel quirks. For example you enter `CometLake`or `Skylake`and it automatically enables the necessary quirks for the chosen CPU family in th background.

Actually the whole plist should work off SMBIOS selection, automatically,  comparing real HW to fit the selected SMBIOS Family Apple HW

Edited May 15, 2021 by STLVNUB

[STLVNUB]

23 minutes ago, STLVNUB said:

Actually the whole plist should work off SMBIOS selection, automatically,  comparing real HW to fit the selected SMBIOS Family Apple HW

Now lets sit back and watch my post get shot down in flames

[mhaeuser]

@5T33Z0 Cannot work because they vary based on device (board) vendor and sometimes even revision.

 

1 hour ago, STLVNUB said:

Now lets sit back and watch my post get shot down in flames

In that case, why do you not just refrain from posting to this thread and spare us from your "ideas"?

[MacUser2525]

6 hours ago, Matgen84 said:

 

Have a look to Pavo-IM/OC-Gen X ont Github.  I don't test or use it.

I do it works flawlessly, except the default language always being Russian... I posted the change needed for English (US) in the thread for it on here.

 

 

[deeveedee]

On 5/15/2021 at 1:03 PM, STLVNUB said:

Actually the whole plist should work off SMBIOS selection, automatically,  comparing real HW to fit the selected SMBIOS Family Apple HW

 

The idea of having OC auto configure based on @5T33Z0 's "CPU family" or your SMBIOS is an interesting suggestion and is somewhat consistent with the OC sanity checker; however, it's an idea that runs counter to one of the core OC principles: Don't "hide" anything from the user.  One of the challenges that OC developers had with CLOVER was the number of "hidden" and "automatic" operations performed behind the scenes by CLOVER.  In my own experience, a competent product management team continues to encourage new ideas and never shoots them "down in flames."

Edited May 17, 2021 by tonyx86
corrected typo

[eSaF]

7 hours ago, STLVNUB said:

Without ideas you have no progress

 

52 minutes ago, tonyx86 said:

a competent product management team continues to encourage new ideas and never shoots them "down in flames

All valid statements which that rings true 100 percent.  ridicule and condescending retorts discourages others from putting forward ideas for progress.

[STLVNUB]

1 hour ago, tonyx86 said:

 

The idea of having OC auto configure based on @5T33Z0 's "CPU family" or your SMBIOS is an interesting suggestion and is somewhat consistent with the OC sanity checker; however, it's an idea that runs counter to one of the core OC principals: Don't "hide" anything from the user.  One of the challenges that OC developers had with CLOVER was the number of "hidden" and "automatic" operations performed behind the scenes by CLOVER.

Good documentation to spell out in plain English what any "hidden" options do and when.

 

[HenryV]

On 5/14/2021 at 6:13 PM, ghost8282 said:

Sorry may be (and probably it is) a stupid question, but why we need this into opencore? can't we just disable or enable sip through termina

Have found that once the installation snapshot is altered and a new boot snapshot is created, Big Sur has KP'd without altering the csr-active-config in Open Core.  

[ghost8282]

6 hours ago, HenryV said:

Have found that once the installation snapshot is altered and a new boot snapshot is created, Big Sur has KP'd without altering the csr-active-config in Open Core.  

 

Thanks HenryV, I think I had that issue too at the first big sur betas when all was quite new about the seal and I had kp too after breaking the seal, which I solved by not breaking the seal  ; thanks for adding this, it may be useful in the future.

[Guest 5T33Z0]

I  had a look at this new HackinDROM App. Basically it's a Database for uploading/downloading/building/updating OpenCore EFI Folders with some settings that can be tweaked.

 

Just for fun, I downloaded the EFI Folder which is suposedly for my Z490 Vision G Board and had a good look at it. As expected, it was just another "rebranded" version of Schmocklords Vision D EFI folder – which most Vision G EFIs are. It even contained his comments in the ACPI section as well als the same minor config issues as his.

 

Not a fan of this app so far since all the EFIs are undocumented. But what do you guys think about this app?

[ghost8282]

Not a fan of any app outside opencore development, I prefer to follow the commits on github, compile the master myself and manually change/update my EFI manually, all I need is terminal and textedit.

I just saw a tutorial about that app on youtube, yes it seems simple to setup, but too much automated: this means that for the user, if it works it's a perfect app, if it doesn't, it's {censored}.

And since I have respect for all the developers I prefer to not use any app and blame them, but blame myself to be an idiot if something goes wrong

 

[Check-IN]

Hello,

i have a fully working Asus Prime Z390-a system, with only IGFX.

But in my OC log i have too many errors.

I'm not able to find any info about this errors, on Dortania i have not found useful info about it.

Can anyone tell anywhere how i can solve?

 

00:000 00:000 AAPL: [EB|#LOG:INIT] 2021-05-17T13:09:38

00:004 00:004 AAPL: [EB|#VERSION] boot.efi 422.140.3~2 (Official), built 2020-06-07T17:22:20-0700

00:009 00:004 AAPL: [EB|#BUILD] BUILD-INFO[298]:{"DisplayName":"boot.efi","DisplayVersion":"422.140.3~2","RecordUuid":"B6FD6584-F0DA-41E8-9542-FAD5E7448407","BuildTime":"2020-06-07T17:22:20-0700","ProjectName":"efiboot","ProductName":"boot.efi","SourceVersion":"422.140.3","BuildVersion":"2","BuildConfiguration":"Release","BuildType":"Official"}

00:016 00:006 AAPL: [EB|#H:IS] 0

00:022 00:005 AAPL: [EB|#WL:MODE] 0

00:028 00:006 AAPL: [EB|#CONFIG:SRC] <default>

00:034 00:006 AAPL: [EB|#CONFIG| 0] boot-save-log : 0x0000000000000002 (0x0000000000000002 < 0xFFFFFFFFFFFFFFFF) <default>

00:041 00:007 AAPL: [EB|#CONFIG| 1] wake-save-log : 0x0000000000000002 (0x0000000000000002 < 0x0000000000000002) <default>

00:049 00:007 AAPL: [EB|#CONFIG| 2] console       : 0x0000000000000001 (0x0000000000000001 < 0x0000000000000001) <default>

00:056 00:007 AAPL: [EB|#CONFIG| 3] serial        : 0x0000000000000000 (0x0000000000000000 < 0x0000000000000000) <default>

00:065 00:008 AAPL: [EB|#CONFIG| 4] embed-log-dt  : 0x0000000000000000 (0x0000000000000000 < 0x0000000000000000) <default>

00:073 00:008 AAPL: [EB|#CONFIG| 5] timestamps    : 0x0000000000000000 (0x0000000000000000 < 0xFFFFFFFFFFFFFFFF) <default>

00:083 00:009 AAPL: [EB|#CONFIG| 6] log-level     : 0x0000000000000001 (0x0000000000000001 & 0x0000000000000001) <default>

00:092 00:009 AAPL: [EB|#CONFIG| 7] breakpoint    : 0x0000000000000000 (0x0000000000000000 & 0x0000000000000000) <default>

00:103 00:010 AAPL: [EB|#CONFIG| 8] kc-read-size  : 0x0000000000100000 (0x0000000000100000 < 0xFFFFFFFFFFFFFFFF) <default>

00:113 00:010 AAPL: [EB|#H:IS] 0

00:124 00:010 AAPL: [EB|#WL|0] 0x01 0x01   0 0x00

00:139 00:015 AAPL: [EB|#BRD:NV] Mac-AA95B1DDAB278B95

00:150 00:010 AAPL: [EB|#WL|1] 0x01 0x01   2 0x00

00:161 00:010 AAPL: [EB|`BST:IDT] {

00:172 00:011 AAPL: [EB|`BST:IDT] }

00:183 00:011 AAPL: [EB|#WL|2] 0x01 0x01   3 0x00

00:194 00:011 AAPL: [EB|#WL|3] 0x01 0x01   4 0x00

00:206 00:011 AAPL: [EB|#BRD:NV] Mac-AA95B1DDAB278B95

00:217 00:011 AAPL: [EB|#WL|4] 0x01 0x01   5 0x00

00:229 00:011 AAPL: [EB|`H:CHK] BM: 0x0000000000000000

00:241 00:012 AAPL: [EB|`H:CHK] Err(0xE) @ GV boot-signature

00:253 00:012 AAPL: [EB|#WL|5] 0x01 0x01  23 0x0E

00:266 00:012 AAPL: [EB|`H:CPM] Err(0xE), (24, 24) @ GV Persistent-memory-note

00:279 00:013 AAPL: [EB|#SB:P] 0x0

00:292 00:012 AAPL: [EB|#LIMG:DP] Acpi(PNP0A03,0)/Pci(1D|0)/Pci(0|0)/?[ 0x83 0x17 0x10 0x0 0x1 0x0 0x0 0x0 0x0 0x1B 0x44 0x4A 0x46 0x76 0x36 0x6B ]/HD(Part2,Sig1C847B02-A8B6-4539-8777-625B17813684)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842)

00:306 00:014 AAPL: [EB|#LIMG:FP] \975FDB2B-1043-498F-8EC2-70737D521EFD\System\Library\CoreServices\boot.efi

00:320 00:014 AAPL: [EB|#LIMG:OPT] ()

00:335 00:014 AAPL: [EB|`OPT:LXF] 'LF (\\975FDB2B-1043-498F-8EC2-70737D521EFD\\System\\Library\\CoreServices\\com.apple.Boot.plist)

00:349 00:014 AAPL: [EB|`LD:LF] FIO: 0, DIR: 1, P: \\975FDB2B-1043-498F-8EC2-70737D521EFD\\System\\Library\\CoreServices\\com.apple.Boot.plist, DP: 0

00:365 00:015 AAPL: [EB|`LD:OFS] Err(0xE) @ OPEN (\\975FDB2B-1043-498F-8EC2-70737D521EFD\\System\\Library\\CoreServices\\com.apple.Boot.plist)

00:381 00:016 AAPL: [EB|`OPT:LXF] Err(0xE) @ 'LF

00:397 00:015 AAPL: [EB|`OPT:LXF] 'LF (Library\\Preferences\\SystemConfiguration\\com.apple.Boot.plist)

00:413 00:016 AAPL: [EB|`LD:LF] FIO: 0, DIR: 1, P: Library\\Preferences\\SystemConfiguration\\com.apple.Boot.plist, DP: 0

00:431 00:017 AAPL: [EB:#KF] ()

00:447 00:016 AAPL: [EB|#MBA:CL] ()

00:464 00:016 AAPL: [EB|#MBA:NV] (debug=0x100 keepsyms=1 alcid=1 igfxfw=2 igfxonln=1 swd_panic=1)

00:481 00:017 AAPL: [EB|#MBA:KF] ()

00:499 00:017 AAPL: [EB|#MBA:OUT] (debug=0x100 keepsyms=1 alcid=1 igfxfw=2 igfxonln=1 swd_panic=1)

00:516 00:017 AAPL: [EB|#OPT:BM] 0x84180

00:534 00:017 AAPL: [EB|`OPT:LXF] 'LF (\\975FDB2B-1043-498F-8EC2-70737D521EFD\\System\\Library\\CoreServices\\PlatformSupport.plist)

00:553 00:018 AAPL: [EB|`LD:LF] FIO: 0, DIR: 1, P: \\975FDB2B-1043-498F-8EC2-70737D521EFD\\System\\Library\\CoreServices\\PlatformSupport.plist, DP: 0

00:572 00:019 AAPL: [EB|#B:VAw]

00:592 00:019 AAPL: [EB|#P:CPR] N

00:611 00:019 AAPL: [EB|#P:MPI] N

00:630 00:019 AAPL: [EB|#P:BPI] N

03:204 02:574 AAPL: [EB|`CS:CSKSD] {

03:223 00:019 AAPL: [EB|`CS:CSKSD] Err(0xE) @ GV 8D63D4FE-BD3C-4AAD-881D-86FD974BC1DF:boot-info-payload

03:243 00:019 AAPL: [EB|#WL|6] 0x01 0x01   6 0x0E

03:263 00:019 AAPL: [EB|`CS:LFC] {

03:283 00:019 AAPL: [EB|`LD:LF] FIO: 0, DIR: 1, P: System\\Library\\Caches\\com.apple.corestorage\\EncryptedRoot.plist.wipekey, DP: 0

03:305 00:021 AAPL: [EB|`FS:AGSVH] Err(0xE) @ LocHB 59D76AE4-37E3-55A7-B460-EF13D46E6020

03:326 00:021 AAPL: [EB|`G:CS] } Ok(0)

03:387 00:061 AAPL: [EB|`LD:LF] FIO: 0, DIR: 1, P: <null string>, DP: 1

03:409 00:021 AAPL: [EB|`B:SBS] SZ: 621112

03:434 00:025 AAPL: [EB|#B:SHA] f4031e1840ae80899574cd5a1feedc6b106d0f87

03:456 00:021 AAPL: [EB|`WL:PWLFNV] Err(0xE) @ GV wake-failure

03:477 00:021 AAPL: [EB|`WL:DT] Err(0xE) @ WL:PWLFNV

03:499 00:021 AAPL: [EB|`WL:PWLFRTC] ! @ RTC:R

03:521 00:021 AAPL: [EB|`WL:DT] Err(0xE) @ WL:PWLFRTC

03:543 00:022 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.0

03:565 00:022 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.1

03:587 00:022 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.2

03:610 00:022 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.3

03:633 00:022 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.4

03:656 00:022 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.5

03:679 00:022 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.6

03:702 00:023 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.7

03:725 00:023 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.8

03:749 00:023 AAPL: [EB|`FS:AGSVH] Err(0xE) @ 'AGU.9

03:772 00:023 AAPL: [EB|`LD:LKC] BPDK -> (System\Library\PrelinkedKernels\prelinkedkernel.development)

03:799 00:026 AAPL: [EB|`LD:OFS] Err(0xE) @ OPEN (System\\Library\\PrelinkedKernels\\prelinkedkernel.development)

03:824 00:024 AAPL: [EB|`LD:LKC] BPDK,!R -> (System\Library\PrelinkedKernels\prelinkedkernel)

05:223 01:399 AAPL: [EB|`LD:LKFS] } Ok(0)

05:248 00:025 AAPL: [EB|`LD:LKC] } Ok(0)

05:275 00:026 AAPL: [EB|#FWFM] 0xFFDFFF7F

05:300 00:025 AAPL: [EB|#FWFT] 0xFD8FF576

07:886 02:585 AAPL: [EB|#CSR:IN] 0x00000677

07:912 00:025 AAPL: [EB|#CSR:OUT] 0x00000667

07:937 00:025 AAPL: [EB|`BST:FBS] {

07:964 00:026 AAPL: [EB|`BST:FBS] BA.ADSZ: 0

07:990 00:026 AAPL: [EB|`BST:FBS] BA.KSDSZ: 0

08:016 00:026 AAPL: [EB|`B:WFDW] Err(0xE), 0 @ LocHB 71B4903C-14EC-42C4-BDC6-CE1449930E49

08:043 00:026 AAPL: [EB|#LOG:DT] 2021-05-17T13:09:46

08:070 00:026 AAPL: [EB|#LOG:EXITBS:START] 2021-05-17T13:09:46

 

[mhaeuser]

@Check-IN None of them are erros.

Edited May 17, 2021 by Download-Fritz

[Check-IN]

3 minutes ago, Download-Fritz said:

@Check-IN None of them are erros.

really?? this is a beautiful news!

so what is it about? if you tell me where I can find some documentation to understand for myself why they are not errors, even if they start with ERR, I would be very grateful

[mhaeuser]

@Check-IN It's debug information from boot.efi (macOS bootloader), not OpenCore itself. "ERR" indeed does mean "ERROR", but it's different from a user-facing error. For example, a file, folder, or property not existing yields a "not found error" (0xE actually is the EFI code for "not found"), however that is not critical (i.e. not a user-facing error). Unfortunately there currently is not much documentation about the boot.efi output.

[deeveedee]

Asking this here, since I think this might be OC/config.plist related...

 

Cinebench R23 incorrectly reports my rig's i7-9700 (8C/8T) CPU as a 4C/8T CPU.

 

Spoiler

 

I suspect that this is purely cosmetic since About This Mac reports my hack as an 8C i7

Spoiler

 

but I'm curious about why Cinebench might detect the wrong core count.  I have tried setting OC's PlatformInfo>Generic>ProcessorType (currently set to 0) to various 8C CPU types, but changing ProcessorType did not change Cinebench's detected core count. Cinebench always detects 4C/8T regardless of OC's ProcessorType.

 

Any ideas?

 

EDIT:

The following commands report the correct number of CPU cores, so I suspect that this is a Cinebench R23 issue.

• sysctl -n hw.physicalcpu: 8

• sysctl -n hw.ncpu: 8

 

EDIT2:

Cinebench R23 correctly reports 6C/12T for i7-8700 on the same platform.

Edited May 22, 2021 by tonyx86
Added sysctl command results; Added note about i7-8700.