OpenCore General Discussion

[macq]

Hi all,

 

Been away fro the scene for while, have got my ventura beta 4 working alright.

But with latest opencore 0.8.3 and newer 0 .8.4 dev builds , I loose my touch pad and the rest all works fine. This has started from the last 3 build of opencore 0.8.3, while earlier build were doing ok. No touchpad problems with them,

all I have to do is to replace the opencore.efi with an earlier build and touchpad works again. no other issues with the system.

Thing I have tried include:

1.Updating lilu, whatsgreen, voodooi2c, voodo2ps2, kexts. Removed touchpad and mouse plugins from voodops2 kext

3. Fiddle around with the order of these kexts in config.plist. If that sort of modification is needed  and mine is still not correctthen please advise. OC validation is ok. But nothing helps. I have updated kexts to latest as needed by my system.

3.Rest nvram when rebooting.

 

Could anyone take a look and advise or help as to how to get touchpad working with the latest opencore builds.

My dsdt and config.plist attached.

 

Was active in 10.x times, nor familiar with repairing permission and gen troubleshooting with macos  these days.

 

Thanks in advance.

System Specs in Signature.

 

Thanks in advance.

 

 

 

 

 

 

macq plist and dsdt.zip

[deeveedee]

@macq Just to clarify, are you saying that you can upgrade OC without changing any kexts and you observe the trackpad issue?  When you say "replace opencore.efi with an earlier build," what is the specific version of the earlier build that works? If I were attempting to diagnose this problem (and the fix is as simple as replacing opencore.efi), I would find the specific incremental build where your issue is resolved and then look at the OC change log.

Edited August 2, 2022 by deeveedee

[macq]

@deeveedee,

 

Last build that work fully is OC 0.83 dev build from  7-13th July, but have touchpad function loss with builds after that. Every thing apart from touchpad works as expected. That means every thing else remains and works well apart from tochpad loss. If i replace only he opencore.efi file from that date and the rest of EFI folder remains same then touchpad works again.

I have updated the kexts as they are released  from Dortania build repo page for all the builds as per documentation. That is all voodoo, Lilu , virtualsmc  ecenabler etc are updated as they appear on the repo page along with OC updates

 

How to proceed ?

 

Thanks

 

 

[deeveedee]

@macq If you're confident that you have isolated the two consecutive OC incremental builds where your rig 'breaks,' look at the OC change log to see what changed from one OC build to the next. The changes might offer a clue. 

Edited August 2, 2022 by deeveedee

[Guest 5T33Z0]

Uhh, they are restructuring the install guide so it will be easier to keep it up-to-date: https://dortania.github.io/hackintosh/updates/2022/08/02/acidanthera-dortania-august.html

 

Edited August 2, 2022 by 5T33Z0

[Avery B]

38 minutes ago, 5T33Z0 said:

Uhh, they are restructuring the install guide so it will be easier to keep it up-to-date: https://dortania.github.io/hackintosh/updates/2022/08/02/acidanthera-dortania-august.html

 

We are looking for feedback on it from users, though it would be way easier to maintain. Much less copy and pasting.

[Guest 5T33Z0]

@1Revenger1 I think it's a great idea. One suggestion I would make is to no longer use screenshots for quirk settings. I think there's less room for errors when using tables instead.

Edited August 2, 2022 by 5T33Z0

[deeveedee]

On 7/31/2022 at 9:22 PM, rafale77 said:

 

And if you want to dig deeper 😁, my EFI also no longer has a "Boot" folder. At some point (I can't remember when) OpenCore became independent from the bootx64.efi as well. I see a lot of people still carrying it in their EFI but it is no longer being used.😉

 

Learn something new every day.  How does this change affect the OC/macOS boot process described here which includes the following steps:

1. System locates BOOTx64.efi on your OpenCore USB under EFI/BOOT/
2. BOOTx64.efi is loaded which then chain-loads OpenCore.efi from EFI/OC/

Is the "new" boot process simply that System loads OpenCore.efi without first locating and loading BOOTx64.efi?

 

 

Thanks!

[Avery B]

8 minutes ago, deeveedee said:

 

Learn something new every day.  How does this change affect the OC/macOS boot process described here which includes the following steps:

1. System locates BOOTx64.efi on your OpenCore USB under EFI/BOOT/
2. BOOTx64.efi is loaded which then chain-loads OpenCore.efi from EFI/OC/

Is the "new" boot process simply that System loads OpenCore.efi without first locating and loading BOOTx64.efi?

 

 

Thanks!

Bootx64.efi is initially needed as it's a default, discoverable, location for bootable media. Once OpenCore boots, it inserts a boot entry into NVRAM which directly points to OpenCore.efi (Believe it's the LauncherOptions setting which dictates this behavior). When you boot using this entry, you don't need BootX64.efi.

[deeveedee]

@1Revenger1 Thanks for the quick response!  So if we want to create a single EFI that can be used for a fresh install and for an already-running system, Bootx64.efi is still necessary ... correct?  I'm asking because I post my baseline EFI in my guide here and only want to provide a single EFI that satisfies use cases for new and existing users.

[Avery B]

2 minutes ago, deeveedee said:

@1Revenger1 Thanks for the quick response!  So if we want to create a single EFI that can be used for a fresh install and for an already-running system, Bootx64.efi is still necessary ... correct?  I'm asking because I post my baseline EFI in my guide here and only want to provide a single EFI that satisfies use cases for new and existing users.

Yes, you still need it if you don't have an entry yet in the system's NVRAM. If your goal is to ship an EFI, you should be including Bootx64.efi.

[rafale77]

@1Revenger1, Thanks! It was my understanding as well that it is needed for initial install of OC.

Regarding feedback/suggestion on the dortania guide, not so much in regards to format but more on content, there are a lot of recurring issues/ support request which I feel  are related to lack of documentation or insufficient emphasis of important points in the documentation of opencore in general.

 

Some examples

1. See these WEG question which @vit9696 finally answered and have puzzled me for quite some time. Options are displayed in the documentation but nothing explains what they fix and what configuration they apply. I will likely submit a github PR as suggested but it would be great if it could be somewhere in dortania. https://github.com/acidanthera/bugtracker/issues/2036#issuecomment-1201307152

2. Another example is the confusion around shiki after Big Sur which is very grey, "Support is not planned after MacOS 11", but the code is very clear: It is completely disabled based on kernel recognition. I submitted a PR which was more black and white but it was modified and watered down to some extent and at least the shiki part of it didn't make it.

3. A lot of people use the brcmpatch and BT firmware injectors on native Apple Airport cards and end up coming here or on reddit asking for help... I know we can't do anything if people don't read the doc but maybe it could be emphasize a bit more that these patches are not needed.

[Moviemakergr]

Hello guys..

On opencore 8.3 - 8.4 needs entrys on legancyThema ?

i have this on boot screen

OCS:No scema for legacyEnable at 2 index content nvram etc,,

can fix it ?

Thanks

Edited August 5, 2022 by Moviemakergr

[ndungu6678]

11 hours ago, Moviemakergr said:

Hello guys..

On opencore 8.3 - 8.4 needs entrys on legancyThema ?

i have this on boot screen

OCS:No scema for legacyEnable at 2 index content nvram etc,,

can fix it ?

Thanks

Read below-( on milliuco's method on how to fix this)-You will need to delete this entry (LegacyEnable )from NVRAM in your config.plist -(you can use PlistEdit Pro) : 

 

(NB:  courtesy of  milliuco)

 

Important! Latest 0.8.3(0.8.4) commit has changed UEFI >> Drivers: changed Enabled (true / false) to Load (Early / Enabled / Disabled), we must update config.plist if using this build.

 

EDIT: NVRAM >> removed LegacyEnable key also.

Edited July 28 by miliuco

This worked for me!🙂

 

Build 1: iMac20,2, i5-9400F, Samsung 16GB DDR4 RAM, MSI Z390 Gaming Plus , Radeon RX 580 8GB, OC 0.8.4

Edited August 6, 2022 by ndungu6678

[Moviemakergr]

15 hours ago, ndungu6678 said:

Read below-( on milliuco's method on ho how to fix this)-You will need to delete this entry (LegacyEnable )from NVRAM in your config.plist -(you can use PlistEdit Pro) : 

 

(NB:  courtesy of  milliuco)

 

Important! Latest 0.8.3(0.8.4) commit has changed UEFI >> Drivers: changed Enabled (true / false) to Load (Early / Enabled / Disabled), we must update config.plist if using this build.

 

EDIT: NVRAM >> removed LegacyEnable key also.

Edited July 28 by miliuco

This worked for me!🙂

 

Thanks bro .. SOLVED

 

 

 

Edited August 6, 2022 by Moviemakergr

[gorans]

After updating to 0.8.3, fans are behaving differently. They spin on full power for longer time after waking up from deep sleep or powering up.

Any ideas what to check?

[deeveedee]

@gorans  If you are certain that your fans issue is not present with 0.8.2 [RELEASE] and If eSaF's suggestion to try an O.8.4 [DEV] nightly build doesn't address the fan issue, I'd experiment with O.8.3 [DEV] incremental builds to see if I could find the 0.8.3 [DEV] build where the fans behavior was introduced.  Then I'd look at the 0.8.3 change log to find what changed between the working and non-working incremental builds.  You'll want to minimize changes with each experiment, which means you will not change any kexts, ACPI or config.plist as you test each incremental OC 0.8.3 [DEV] build.

[gorans]

21 hours ago, deeveedee said:

@gorans  If you are certain that your fans issue is not present with 0.8.2 [RELEASE] and If eSaF's suggestion to try an O.8.4 [DEV] nightly build doesn't address the fan issue, I'd experiment with O.8.3 [DEV] incremental builds to see if I could find the 0.8.3 [DEV] build where the fans behavior was introduced.  Then I'd look at the 0.8.3 change log to find what changed between the working and non-working incremental builds.  You'll want to minimize changes with each experiment, which means you will not change any kexts, ACPI or config.plist as you test each incremental OC 0.8.3 [DEV] build.

 

Thanks guys for Your suggestions. (Un)fortunately, after couple of restarts I'm not able to replicate the problem. If it resurfaces, I'll do this step-by-step updating method.

[Stefanalmare]

Hi! I'm trying to make emulated NVRAM working on my HP XW4600, Monterey 12.5. Emulated NVRAM was OK with the former LogoutHook.command. Now, I saw no results. I ran: ./Launchd.command status and I received this: 
"Daemon pid = 1530
Agent pid =
LogoutHook = /Library/Application Support/Clover/CloverDaemon-stopservice"
I deleted /Application Support/Clover/ and all /etc/rc....., rebooted, reinstalled, but I get the same result.
What should I do?

Edited August 13, 2022 by Stefanalmare

[miliuco]

@Stefanalmare

Supposedly it is not essential although it is recommended, do you have OpenVariableRuntimeDxe.efi?

[Stefanalmare]

36 minutes ago, miliuco said:

@Stefanalmare

Supposedly it is not essential although it is recommended, do you have OpenVariableRuntimeDxe.efi?

I use Duet and: 
"Provides in-memory emulated NVRAM implementation. This can be useful on systems with fragile (e.g. MacPro5,1,
see discussion linked from this forum post) or incompatible NVRAM implementations. This driver is included by
default în OpenDuet". 
But I'll try. My feeling is that I need a command to break the link to CloverDaemon-stopservice.

[miliuco]

@Stefanalmare

This is a different macOS version but did you read it?

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

[Stefanalmare]

2 hours ago, miliuco said:

@Stefanalmare

This is a different macOS version but did you read it?

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

Same in my Snow Leopard, EeePC project. Not the same with HP XW4600, Monterey 12.5.

[Henties]

I am presently trying OC 0.8.4 nightly 19.08.2022 and configured the new entries in accordance with the documentation that accompanied the nightly download, with everything, at least as I can tell, working properly.

 

What I am lacking is a basic understanding what these new config.plist entries are actually meant to achieve, I feel like configuring the many new sections like a "stooge" which is aimlessly meandering in complete darkness.

 

Would appreciate somebody knowledgeable to enlighten me, as the available documentation has thus far not been able to provide an insight into the latest OC changes and additions.

 

Greetings Henties

Edited August 20, 2022 by Henties

[MacNB]

Opencore ConnectDrivers taking a long time at boot.

Questions for the Devs: why does it take so long ?

 

Recently fired up one of my ageing hacks (Dell Inspiron 530 Legacy BIOS) to help someone with Legacy config.

It has OC 0.8.3 DEBUG installed (with latest OpenDuet).

I remember the slow startup after the BIOS POST screen clears and before Opencore debug messages come up on the screen (about 10 seconds).

 

Looking at the debug log, I see:

...
00:427 00:002 OC: Connecting drivers...
12:735 12:307 OC: Connecting drivers done...
...

So it's actually taking OC over 12 seconds to connect these drivers.

 

Questions for the Devs: why does it take so long ? What's actually happening in these 12 seconds ?

 

As a test, in the config.plist I set

ConnectDrivers=FALSE

This made the boot time longer and the log file showed:

...
06:165 00:048 OC: Connecting drivers...
18:282 12:117 OC: Connecting drivers done...
...

 

It's taking over 12 seconds NOT to connect drivers.

Obviously, I lost Snow Leopard in the Boot Picker list since HfsPlusLegacy.efi driver was not connected.

 

I was expecting that by setting ConnectDrivers=FALSE, that would speed up the boot process by saving ~12 seconds but it makes it worse.

 

So, what's happening with ConnectDrivers setting ?

Edited September 2, 2022 by MacNB