OpenCore General Discussion

[mhaeuser]

4 hours ago, MacNB said:

Anyway to hide that (apart from deleting Clover) ?

If categorical filtering by ScanPolicy does not work for you, no... it's bootable, so it's shown as bootable

[eSaF]

6 hours ago, MacNB said:

 

Thanks @Download-Fritz for the clarification.

OpenCanopy still displayed an EFI disk icon:

 

But I figured out which drive that EFI was.

It was the EFI partition on the Mojave-SSD drive above that contains Clover 

 

Anyway to hide that (apart from deleting Clover) ?

 

I also have a disk containing Mojave plus one with Catalina and the other with Windows, I have no problem using OC to boot Mojave. Have you tried temporarily removing the Clover EFI folder and try booting Mojave with OC which would get rid of the extra EFI partition? Worked for me.

[koder]

On 5/23/2020 at 1:44 AM, koder said:

I need help make patch for making sleep/awake works. I post full info and they locked. It's hard to find someone who has experience with ACPI spec.

what am i going to do without RehabMan?

 

This is the problem everything here

https://github.com/acidanthera/bugtracker/issues/931

Help

[arsradu]

4 hours ago, koder said:

I need help make patch for making sleep/awake works. I post full info and they locked. It's hard to find someone who has experience with ACPI spec.

what am i going to do without RehabMan?

 

This is the problem everything here

https://github.com/acidanthera/bugtracker/issues/931

 

Sleep/wake issues are usually caused, in my experience, by misconfigured iGPU. Also, if you don't necessarily need a custom DSDT, I would recommend not using one and only working with SSDTs (the ones mentioned on the Dortania OpenCore page). Looks like you're using the HD4600 (same as mine, by the way), which should be pretty easy to configure using Lilu + WEG + config -> Device Properties (AAPL,ig-platform-id). More info on that here.

 

Also, if I may suggest, try not to spam the forum. If people don't reply, more often than not, they don't know how to fix your issue. Or expect a bit more details. Also, please add your hardware information to your signature. That helps a lot.

Edited May 24, 2020 by arsradu

[arsradu]

Not sure why you changed your username instead of adding the model of your laptop to your signature. But sure, whatever works. :)) 

 

Let's continue on the thread you created.

[SavageAUS]

If I wanted to switch from clover to oc on my desktop would a fresh install be best or just clear nvram is enough?
 
 
Sent from my iPhone using Tapatalk

I think clearing nvram is enough but I keep getting stuck on
[EB|#LOG:EXITBS:START] or something alike.
I have unlocked my msr to see if that helps but still no joy.
Any suggestions?
I’ll upload config after.


Sent from my iPhone using Tapatalk

If I wanted to switch from clover to oc on my desktop would a fresh install be best or just clear nvram is enough?
 
 
Sent from my iPhone using Tapatalk

I think clearing nvram is enough but I keep getting stuck on
[EB|#LOG:EXITBS:START] or something alike.
I have unlocked my msr to see if that helps but still no joy.
Any suggestions?
I’ll upload config after.


Sent from my iPhone using Tapatalk

[Matgen84]

28 minutes ago, SavageAUS said:

I think clearing nvram is enough but I keep getting stuck on
[EB|#LOG:EXITBS:START] or something alike.
I have unlocked my msr to see if that helps but still no joy.
Any suggestions?
I’ll upload config after.


Sent from my iPhone using Tapatalk
I think clearing nvram is enough but I keep getting stuck on
[EB|#LOG:EXITBS:START] or something alike.
I have unlocked my msr to see if that helps but still no joy.
Any suggestions?
I’ll upload config after.


Sent from my iPhone using Tapatalk

 

Take a look Here for this troubleshooting.

[MacNB]

10 hours ago, Download-Fritz said:

If categorical filtering by ScanPolicy does not work for you, no... it's bootable, so it's shown as bootable

 

Thanks. 

Actually, I made a mistake. That EFI drive displayed was not Clover but ANOTHER OpenCore on the Catalina-HD drive.

Let me explain.

I have seen a worrying problem with OC (which I will explain in another thread) so I removed Clover from my Mojave-SSD and installed OC.

So now I have OC on the the Catalina-HD ESP AND OC on the Mojave-SSD.

Then I switched the BIOS default boot priority from Catalina-HD ESP to Mojave-SSD ESP.

That screenshot above is what happens when I boot.

 

So OpenCanopy is displaying second OC EFI.

Of course it Halts with Critical Error when I try to boot that EFI (since OC Image has already started).

 

If I select either Catalina-HD or Mojave-SSD they both boot fine.

 

I know we should not have more than one OC instance but how should OC scan policy handle more that one instance of OC ESP ?

[MacNB]

8 hours ago, eSaF said:

I also have a disk containing Mojave plus one with Catalina and the other with Windows, I have no problem using OC to boot Mojave. Have you tried temporarily removing the Clover EFI folder and try booting Mojave with OC which would get rid of the extra EFI partition? Worked for me.

 

Thanks eSaF. Actually I don't have a problem booting any of the four displayed OS's (even when Clover was on the Mojave drive).

The question was about the displayed EFI drive icon (now that HideSelf setting is removed).

That displayed icon is for a second OC on another drive (see my explanation above to Download_Fritz).

[eSaF]

29 minutes ago, MacNB said:

 

Thanks eSaF. Actually I don't have a problem booting any of the four displayed OS's (even when Clover was on the Mojave drive).

The question was about the displayed EFI drive icon (now that HideSelf setting is removed).

That displayed icon is for a second OC on another drive (see my explanation above to Download_Fritz).

Ah ok - Understood

[vit9696]

@MacNB, currently OpenCore has no ways to hide discovered entries on request. We do not see a valid reason to, since in our eyes these are valid bootable entries. Even if you boot a second OpenCore copy, it should no longer cause boot failure (unless the second copy is very old) but return to the UI with no issues.

 

With or without HideSelf (i.e. regardless of the OpenCore version — 0.5.8 or 0.5.9) you will always see all OpenCore versions installed but the one you booted from. There was no change here in 0.5.9, and I do not believe we will change it in the future mainly due to performance reasons of doing extra I/O.

 

Finally, if you believe that seeing EFI Boot is not intuitive in regards to your second OpenCore copy, you could always provide a custom .disk_label and/or .VolumeIcon.icns to make it clear. If desired, as an alternative you can also remove the other installation entirely.

[SavageAUS]

3 hours ago, Matgen84 said:

 

Take a look Here for this troubleshooting.

Yeah I checked there, that’s why I unlocked my msr but I’ll check again and upload my config when I get a chance.

 

Attached config

 

Sent from my iPhone using Tapatalk

config.plist

Edited May 24, 2020 by SavageAUS
Added config.plist

[mhaeuser]

4 hours ago, MacNB said:

I know we should not have more than one OC instance but how should OC scan policy handle more that one instance of OC ESP ?

Which version of OC is the secondary instance? If it's older than the 0.5.9 revision that dropped HideSelf (remember BOOTx64 and OC must always be in sync here), it will be shown no matter what. Once you upgrade that instance to the latest version, it should disappear too.

 

EDIT: Turns out I remembered incorrectly and only the boot partition is "filtered" for OC booters, looks like you're out of luck.

Edited May 24, 2020 by Download-Fritz

[codeVerine]

How to ACPI Debugging in OpenCore ? ACPIDebug patch requires patching of DSDT which is not supported by OpenCore AFAIK. Any help would be much appreciated.

[Matgen84]

1 hour ago, SavageAUS said:

Yeah I checked there, that’s why I unlocked my msr but I’ll check again and upload my config when I get a chance.

 

Attached config

 

Sent from my iPhone using Tapatalk

config.plist

 

What do you mean by unlock your msr (config.plist or BIOS)?

 

Your config.plist:

<key>AppleCpuPmCfgLock</key>
<false/>
<key>AppleXcpmCfgLock</key>
<true/>

 

 

Dortania guide:  needed when CFG-Lock can't be disabled in BIOS

<key>AppleCpuPmCfgLock</key>
<true/>
<key>AppleXcpmCfgLock</key>
<true/>

 

[SavageAUS]

 
What do you mean by unlock your msr (config.plist or BIOS)?
 
Your config.plist:

AppleCpuPmCfgLockAppleXcpmCfgLock

 
 
Dortania guide:  needed when CFG-Lock can't be disabled in BIOS

AppleCpuPmCfgLockAppleXcpmCfgLock

 

Yeah CFG lock. I used modified grub shell to change the var to unlocked.
I also uploaded config.plist to check for errors.


Sent from my iPhone using Tapatalk

 
What do you mean by unlock your msr (config.plist or BIOS)?
 
Your config.plist:

AppleCpuPmCfgLockAppleXcpmCfgLock

 
 
Dortania guide:  needed when CFG-Lock can't be disabled in BIOS

AppleCpuPmCfgLockAppleXcpmCfgLock

 

Yeah CFG lock. I used modified grub shell to change the var to unlocked.
I also uploaded config.plist to check for errors.


Sent from my iPhone using Tapatalk

[MacNB]

3 hours ago, vit9696 said:

@MacNB, currently OpenCore has no ways to hide discovered entries on request. We do not see a valid reason to, since in our eyes these are valid bootable entries. Even if you boot a second OpenCore copy, it should no longer cause boot failure (unless the second copy is very old) but return to the UI with no issues.

 

With or without HideSelf (i.e. regardless of the OpenCore version — 0.5.8 or 0.5.9) you will always see all OpenCore versions installed but the one you booted from. There was no change here in 0.5.9, and I do not believe we will change it in the future mainly due to performance reasons of doing extra I/O.

 

Finally, if you believe that seeing EFI Boot is not intuitive in regards to your second OpenCore copy, you could always provide a custom .disk_label and/or .VolumeIcon.icns to make it clear. If desired, as an alternative you can also remove the other installation entirely.

 

 

2 hours ago, Download-Fritz said:

Which version of OC is the secondary instance? If it's older than the 0.5.9 revision that dropped HideSelf (remember BOOTx64 and OC must always be in sync here), it will be shown no matter what. Once you upgrade that instance to the latest version, it should disappear too.

 

EDIT: Turns out I remembered incorrectly and only the boot partition is "filtered" for OC booters, looks like you're out of luck.

 

Guys, thanks for the clear explanation.

I agree there's no valid reason to hide discovered entries on request as it's a very unusual situation in general use (specially multiple instances of OC).

I had an older version of OC on the Catalina-HD vs. current version (compiled last last night) on Mojave-SSD.

 

Just for testing, I've copied that latest OC build to Catalina-HD EFI and put .contentsDetails with name = OC-NVMe in the Boot folder.

I put a .contentsDetails file with the name = OC-P120 on the Mojave-SSD EFI Boot folder.

So now both EFI's are the same.

 

If I boot Mojave-SSD EFI via BIOS F12 (on the P120 drive), I see this in OpenCanopy:

 

If I boot Catalina-HD EFI (on the NMVe drive), I see:

 

 

Now if I select either OC-NMVe or OC-P120, it no longer crashes and gets me back into OpenCanopy.

Actually, it's kind of handy to have a secondary OC EFI has a backup while testing bleeding edge versions 

So all cool. Keep up the great work.

 

Now to my next discovery/problemo....

[MacNB]

OpenCore Debug logs corrupting EFI partition ?

 

So recently in the last couple of days my boot times are slowed down even after removing AudioDxe.efi.

The Apple logo appears and the loading bar starts (slower than before) and around half way it's starts to stutter and halts for a couple of seconds  and screen goes black and the loading bar continues and boots normal.

I think ~ 8-10 seconds have been added.

 

Anyway, leaving that problem to one side for the moment, I discovered potentially another.

In order to track down that issue, I first ran diskutil verifydisk command and discovered another problem.

The OpenCore EFI partition is getting corrupted:

 

macnb@My-iMac OpenCore % diskutil verifydisk disk1
Started partition map verification on disk1
Checking prerequisites
Checking the partition list
Checking the partition map size
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Problems were found with the partition map which might prevent booting
Error: -69766: The partition map needs to be repaired because there's a problem with the EFI system partition's file system
Underlying error: 8

macnb@My-iMac OpenCore % 

 

I most have been boot with Debug Builds with Debug->Target=0x43 which creates OC log files on every boot.

Over the past few weeks, I must have restarted 100's of times (with logs created on each restart).

I normally delete the older log files as they start taking space. 

 

next I ran fsck command:

macnb@My-iMac OpenCore % sudo fsck_msdos /dev/disk1s1
Password:
** /dev/rdisk1s1
** Phase 1 - Preparing FAT
** Phase 2 - Checking Directories
Invalid long filename entry for /opencore-2020-05-23-170943.txt
Remove? [yn] n
** Phase 3 - Checking for Orphan Clusters
Found orphan cluster(s)
Fix? [yn] n
Found 8 orphaned clusters
1436 files, 57752 KiB free (115505 clusters)
** Phase 1 - Preparing FAT
** Phase 2 - Checking Directories
Invalid long filename entry for /opencore-2020-05-23-170943.txt
Remove? [yn] n
** Phase 3 - Checking for Orphan Clusters
Found orphan cluster(s)
Fix? [yn] n
Found 8 orphaned clusters
Free space in FSInfo block (115505) not correct (231010)
Fix? [yn] n
1436 files, 115505 KiB free (231010 clusters)
** Phase 1 - Preparing FAT
** Phase 2 - Checking Directories
Invalid long filename entry for /opencore-2020-05-23-170943.txt
Remove? [yn] n
** Phase 3 - Checking for Orphan Clusters
Found orphan cluster(s)
Fix? [yn] n
Found 8 orphaned clusters
Free space in FSInfo block (115505) not correct (346515)
Fix? [yn] n
1436 files, 173257 KiB free (346515 clusters)
macnb@My-iMac OpenCore %

Lots of orphaned clusters and also see:

Invalid long filename entry for /opencore-2020-05-23-170943.txt

 

I backed up the EFI folder onto the my Home folder.

I fixed the EFI partition by running diskutil repairdisk disk1 and luckily nothing was lost.

 

So I installed OC onto one of the other drives in my system and booting off that fine.

After a few days (lots of restarts and OC log files), that drive's EFI partition was also corrupted with similar errors.

 

I have now turned OFF debug (Target=0) and have not seen any corruptions.

 

Both drives are new (one NVMe and the other SSD).

 

Anyone else seen this ? or verified their Disks recently after logging OC ?

 

[mhaeuser]

@MacNB This has nothing (directly) to do with OC, some garbage (cough AMI cough) FAT drivers do corrupt the FS when writing, yes.

[MacNB]

24 minutes ago, Download-Fritz said:

@MacNB This has nothing (directly) to do with OC, some garbage (cough AMI cough) FAT drivers do corrupt the FS when writing, yes.

 

That's what I was thinking. Are any external FAT.efi that can be loaded by OC to override the firmware ?

Thanks.

[arsradu]

Hi guys,

 

What's the difference between "layout-id" and "alc-layout-id"?

 

The reason why I'm asking is because the Configuration pdf mentions "layout-id" as the key we need to use in Device Properties. Same thing for the sample.plist. But...in ioreg, the value I enter as "layout-id" gets displayed under "alc-layout-id". And I get another value displayed as "layout-id". So...I'm confused.

 

For example:

I want layout-id 15, so I enter layout-id 0F000000 (reversed bytes) in Device Properties.

However, when I check the ioreg (HDEF section), the "layout-id" is 07000000 and the "alc-layout-id" is actually the one with value 0F000000.

 

I'm a bit confused. I do have sound either way, by the way. Just wanted to know more about this, if possible. Cause it seems strange. And I'm sure there's something I'm missing here.  

Edited May 24, 2020 by arsradu

[MacNB]

26 minutes ago, arsradu said:

Hi guys,

 

What's the difference between "layout-id" and "alc-layout-id"?

 

The reason why I'm asking is because the Configuration pdf mentions "layout-id" as the key we need to use in Device Properties. Same thing for the sample.plist. But...in ioreg, the value I enter as "layout-id" gets displayed under "alc-layout-id". And I get another value displayed as "layout-id". So...I'm confused.

 

For example:

I want layout-id 15, so I enter layout-id 0F000000 (reversed bytes) in Device Properties.

However, when I check the ioreg (HDEF section), the "layout-id" is 07000000 and the "alc-layout-id" is actually the one with value 0F000000.

 

I'm a bit confused. I do have sound either way, by the way. Just wanted to know more about this, if possible. Cause it seems strange. And I'm sure there's something I'm missing here.  

 

My IOREG shows alc-layout=<07 00 00 00> and layout-id=<07 00 00 00>.

In my Device Properties = 07 00 00 00

 

Not sure why yours are different.

May AppleALC driver is alc-layout-id ?

But different ? Hmmm

 

A lot folks used to add layout id's via boot-args. 

May be check yours if you had it in the past forgot to take it out...just thinking out loud.

[vit9696]

There currently is no way to install a custom FAT driver without flashing it into the firmware. This quite uneasy, and since the issue is resolved with APTIO V (Broadwell+) we will unlikely ever work on it.

 

The correct way to inject the layout is to use layout-id. alc-layout-id is an internal thing AppleALC uses, and it is correct that AppleALC then renames your value to alc-layout-id. The internal kitchen behind the values is that different layout-id values may have different predefined DSP properties in AppleHDA userspace libraries. To avoid a conflict AppleALC always uses a constant value of layout-id 7 for all the libraries. Your injected value on the other side becomes only relevant to AppleALC itself (as it chooses the layout based on it). This value remains present in I/O Registry under the name of alc-layout-id for debugging reasons.

[insanefrancis]

1 hour ago, arsradu said:

Hi guys,

 

What's the difference between "layout-id" and "alc-layout-id"?

 

The reason why I'm asking is because the Configuration pdf mentions "layout-id" as the key we need to use in Device Properties. Same thing for the sample.plist. But...in ioreg, the value I enter as "layout-id" gets displayed under "alc-layout-id". And I get another value displayed as "layout-id". So...I'm confused.

 

For example:

I want layout-id 15, so I enter layout-id 0F000000 (reversed bytes) in Device Properties.

However, when I check the ioreg (HDEF section), the "layout-id" is 07000000 and the "alc-layout-id" is actually the one with value 0F000000.

 

I'm a bit confused. I do have sound either way, by the way. Just wanted to know more about this, if possible. Cause it seems strange. And I'm sure there's something I'm missing here.  

 

This might help you. https://dortania.github.io/OpenCore-Desktop-Guide/post-install/audio.html#making-layout-id-more-permanent

[arsradu]

6 minutes ago, vit9696 said:

The correct way to inject the layout is to use layout-id. alc-layout-id is an internal thing AppleALC uses, and it is correct that AppleALC then renames your value to alc-layout-id.

 

The internal kitchen behind the values is that different layout-id values may have different predefined DSP properties in AppleHDA userspace libraries. To avoid a conflict AppleALC always uses a constant value of layout-id 7 for all the libraries. Your injected value on the other side becomes only relevant to AppleALC itself (as it chooses the layout based on it). This value remains present in I/O Registry under the name of alc-layout-id for debugging reasons.

 

All clear. Thank you!  

 

Also, funny you said "internal kitchen". We actually have an identical version of that in RO. You can translate it word by word and it would mean the exact same thing. :))

 

Once again, thank you!  

 

Edited May 24, 2020 by arsradu