STLVNUB Posted August 1, 2022 Share Posted August 1, 2022 (edited) I would dearly love to get Snow Leopard running with latest OpenCore ,Any tips? Edited August 1, 2022 by STLVNUB Link to comment Share on other sites More sharing options...
deeveedee Posted August 2, 2022 Share Posted August 2, 2022 Upgrade to OpenCore 0.8.3 was smooth and painless. Well done, Developers! Thank you! My upgrade steps from OC 0.8.2 to OC 0.8.3 are here. 3 Link to comment Share on other sites More sharing options...
macq Posted August 2, 2022 Share Posted August 2, 2022 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 Link to comment Share on other sites More sharing options...
deeveedee Posted August 2, 2022 Share Posted August 2, 2022 (edited) @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 Link to comment Share on other sites More sharing options...
macq Posted August 2, 2022 Share Posted August 2, 2022 @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 Link to comment Share on other sites More sharing options...
deeveedee Posted August 2, 2022 Share Posted August 2, 2022 (edited) @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 1 Link to comment Share on other sites More sharing options...
Guest 5T33Z0 Posted August 2, 2022 Share Posted August 2, 2022 (edited) 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 Link to comment Share on other sites More sharing options...
1Revenger1 Posted August 2, 2022 Share Posted August 2, 2022 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. 2 Link to comment Share on other sites More sharing options...
Guest 5T33Z0 Posted August 2, 2022 Share Posted August 2, 2022 (edited) @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 Link to comment Share on other sites More sharing options...
deeveedee Posted August 2, 2022 Share Posted August 2, 2022 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: System locates BOOTx64.efi on your OpenCore USB under EFI/BOOT/ 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! 1 Link to comment Share on other sites More sharing options...
1Revenger1 Posted August 2, 2022 Share Posted August 2, 2022 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: System locates BOOTx64.efi on your OpenCore USB under EFI/BOOT/ 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. 3 2 1 Link to comment Share on other sites More sharing options...
deeveedee Posted August 2, 2022 Share Posted August 2, 2022 @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. Link to comment Share on other sites More sharing options...
1Revenger1 Posted August 2, 2022 Share Posted August 2, 2022 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. 1 1 Link to comment Share on other sites More sharing options...
rafale77 Posted August 2, 2022 Share Posted August 2, 2022 @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. 1 Link to comment Share on other sites More sharing options...
Moviemakergr Posted August 5, 2022 Share Posted August 5, 2022 (edited) 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 Link to comment Share on other sites More sharing options...
ndungu6678 Posted August 5, 2022 Share Posted August 5, 2022 (edited) 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 5 Link to comment Share on other sites More sharing options...
Moviemakergr Posted August 6, 2022 Share Posted August 6, 2022 (edited) 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 3 Link to comment Share on other sites More sharing options...
gorans Posted August 6, 2022 Share Posted August 6, 2022 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? Link to comment Share on other sites More sharing options...
eSaF Posted August 6, 2022 Share Posted August 6, 2022 18 minutes ago, gorans said: 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? If you're feeling it is in relation with 0.8.3, you can always try 0.8.4 nightly version and see if the behaviour is the same. 3 Link to comment Share on other sites More sharing options...
deeveedee Posted August 7, 2022 Share Posted August 7, 2022 @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. 5 Link to comment Share on other sites More sharing options...
gorans Posted August 8, 2022 Share Posted August 8, 2022 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. Link to comment Share on other sites More sharing options...
Stefanalmare Posted August 13, 2022 Share Posted August 13, 2022 (edited) 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 Link to comment Share on other sites More sharing options...
miliuco Posted August 14, 2022 Share Posted August 14, 2022 @Stefanalmare Supposedly it is not essential although it is recommended, do you have OpenVariableRuntimeDxe.efi? 1 Link to comment Share on other sites More sharing options...
Stefanalmare Posted August 14, 2022 Share Posted August 14, 2022 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. Link to comment Share on other sites More sharing options...
miliuco Posted August 14, 2022 Share Posted August 14, 2022 @Stefanalmare This is a different macOS version but did you read it? https://github.com/acidanthera/bugtracker/issues/2106 2 Link to comment Share on other sites More sharing options...
Recommended Posts