Jump to content

OpenCore General Discussion


dgsga
8,887 posts in this topic

Recommended Posts

6 hours ago, MacNB said:

 

Thanks @Download-Fritz for the clarification.

OpenCanopy still displayed an EFI disk icon:IMG_1779.thumb.jpg.38b87d901893be6a1db3ca855e7e4c7f.jpg

 

But I figured out which drive that EFI was.

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

 

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.

Link to comment
Share on other sites

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

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

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by SavageAUS
Added config.plist
Link to comment
Share on other sites

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

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

 

Link to comment
Share on other sites

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

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:

IMG_1784.thumb.jpg.8259b3c1b21861aef1e73c9f43d7dbb3.jpg

 

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

 

IMG_1785.thumb.jpg.3ff42089831b55fcbcb2895582feaeb5.jpg

 

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....:dev:

  • Like 2
Link to comment
Share on other sites

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 ?

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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.

Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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

×
×
  • Create New...