texem Posted September 7, 2021 Share Posted September 7, 2021 Hi all, still alive 😇 fiddling with 12.0 beta 6 and now i have issues with bluetooth after wake from sleep. I have to disable/enable BT getting mouse and kbd re-connected. Seems the driver behaves different now. Never had any issue(s) with BT since using my BCM PCIe card which is natively supported but now ... Couldn't find a kext fixing this, always tried some promising tweaks. For my taste it has something to do with power-management, possibly the card is now fully offline cos wake via BT doesn't work as well. Anyone ? Cheers Link to comment Share on other sites More sharing options...
pkdesign Posted September 7, 2021 Share Posted September 7, 2021 I've updated to OC 0.7.3 with no issues. Just had to add one quirk and redo "Drivers" section to match new formatting. UEFI>ForceOcWriteFlash = NO Sample of new Drivers section. You can have all drivers present (in OC>Drivers) now, just change key to "Disabled" is you don't use. I keep mine clean and only have what I need: <dict> <key>Arguments</key> <string></string> <key>Enabled</key> <true/> <key>Path</key> <string>HfsPlus.efi</string> </dict> <dict> <key>Arguments</key> <string></string> <key>Enabled</key> <true/> <key>Path</key> <string>OpenRuntime.efi</string> </dict> <dict> <key>Arguments</key> <string></string> <key>Enabled</key> <true/> <key>Path</key> <string>OpenCanopy.efi</string> </dict> <dict> <key>Arguments</key> <string></string> <key>Enabled</key> <true/> <key>Path</key> <string>AudioDxe.efi</string> </dict> Link to comment Share on other sites More sharing options...
juan e. jot Posted September 7, 2021 Share Posted September 7, 2021 56 minutes ago, pkdesign said: I've updated to OC 0.7.3 with no issues. Just had to add one quirk and redo "Drivers" section to match new formatting. UEFI>ForceOcWriteFlash = NO Sample of new Drivers section. You can have all drivers present (in OC>Drivers) now, just change key to "Disabled" is you don't use. I keep mine clean and only have what I need: <dict> <key>Arguments</key> <string></string> <key>Enabled</key> <true/> <key>Path</key> <string>HfsPlus.efi</string> </dict> <dict> <key>Arguments</key> <string></string> <key>Enabled</key> <true/> <key>Path</key> <string>OpenRuntime.efi</string> </dict> <dict> <key>Arguments</key> <string></string> <key>Enabled</key> <true/> <key>Path</key> <string>OpenCanopy.efi</string> </dict> <dict> <key>Arguments</key> <string></string> <key>Enabled</key> <true/> <key>Path</key> <string>AudioDxe.efi</string> </dict> This is a great start! Linux multi-booters, read on for a warning! Unfortunately, these steps haven't worked for me yet, as I triple-boot with one of the options being Linux. Since acidenathera have just overhauled how GRUB & systemd-boot* are expected to work with OpenCore (and it looks like it's an offshoot of acidenathera's expectation to use efibootmgr from within Linux rather than the older BlessOverride entry in config.plist; but we as yet have no corroboration from Dortania, whose guide still covers 0.7.2), I have some more tinkering to do. In fact, trying the method above while retaining my BlessOverride entry in config.plist & NOT yet installing or referencing the new OpenLinuxBoot.efi under Drivers as you have other drivers above, the OpenCanopy boot graphics go away (though I have yet to see an update to Resources from OcBinaryData), and any mention of my macOS boot drive by name goes away, too; I'm left with "Windows" and two "NO NAME" entries (one probably being macOS & the other probably being Linux, but who knows which is which), and I can't seem to space out of there to reset NVRAM. In any event, I'll try to post whatever was successful, once it is! *Weird point for Linux users & acidanthera, if they see it: Differences.pdf for 0.7.3 asserts that if your Linux distro uses systemd-boot, it's likely Arch. Um, not so; I recognize the irony of saying "BTW, I don't run Arch…," but various non-Arch distros I've tried & in fact run on various machines, use systemd-boot. Even across bases, the boot manager differs; among Ubuntu-based distributions, for example, elementary OS (currently) uses GRUB by default, but Pop!_OS (currently) uses systemd-boot by default. So getting one or another BootLoaderSpec/[ByDefault] way of booting to Linux consistently, with either consistency or a clear delineation between GRUB & systemd-boot in the instructions, will be great, moving forward. Thanks for reading this far! 1 Link to comment Share on other sites More sharing options...
unknownharris Posted September 7, 2021 Share Posted September 7, 2021 Hello there folks and hope you are all well 😇 I was wondering if someone could provide an update as to what will happen from Monterrey and further. I mean I am trying to piece together how to set-up a successful EFI now that AG has departed and zip is provided but cannot really comprehend how because you are talking in a higher expert level. Will someone be able to compress EFIs for us less simple-minded on the subject of Hackintoshing that carry the same AG original build moving forward? P.S: Don't take this as a hostile post or anything, just noting that there might be other people here as well that might be new to Hackintoshing (like me) and cannot successfuly make it work on their own as the macOS moves forward so we might need a boilerplate. Link to comment Share on other sites More sharing options...
xtddd Posted September 8, 2021 Share Posted September 8, 2021 i updated to 0.7.3 but it break its boot GUI..how to fix it? Link to comment Share on other sites More sharing options...
eSaF Posted September 8, 2021 Share Posted September 8, 2021 (edited) @xtddd and @unknownharris - Guys follow my example in this EFI Folder. Everything is updated including all kexts, I have removed all my personal data so you'll have to furnish it with your own. The changes in the released .0.7.3 is as shown and must be enabled for the GUI to be shown and the Boot to be successful. One more thing do not use any files from your previous EFI Folder apart from your personal data. Good luck. Just to add and to avoid confusion, Your SSDT Files can be carried forward, your Mapped USB kext can be carried forward all other kexts should be updated to the latest versions. Spoiler EFI.zip Edited September 9, 2021 by eSaF 3 1 Link to comment Share on other sites More sharing options...
xtddd Posted September 8, 2021 Share Posted September 8, 2021 (edited) @eSaF thank you very much! i have a try and GUI can be shown...but the 10.15.7 cant be shown in the GUI menu Edited September 8, 2021 by xtddd Link to comment Share on other sites More sharing options...
Anto65 Posted September 8, 2021 Share Posted September 8, 2021 (edited) 1 hour ago, xtddd said: @eSaF thank you very much! i have a try and GUI can be shown...but the 10.15.7 cant be shown in the GUI menu Set in UEFI> APFS for CATALINA MinDate = 20200306 MinVersion = 1412101001000000 Here are some options available recommended in UEFI / APFS AUTO 0 Currently set to allow macOS Big Sur and later (16000000000000000) ANY -1 Allows any version to be loaded (strongly discouraged) DEFAULT MinDate = 20210101 MinVersion = 1600000000000000 HIGH SIERRA MinDate = 20180621 MinVersion = 7480770080000000 MOJAVE MinDate = 20190820 MinVersion = 9452750070000000 CATALINA MinDate = 20200306 MinVersion = 1412101001000000 BIG SUR MinDate = 20210508 MinVersion = 1677120009000000 Edited September 8, 2021 by antuneddu 2 Link to comment Share on other sites More sharing options...
xtddd Posted September 8, 2021 Share Posted September 8, 2021 @antuneddu thank you very much! i got it 2 Link to comment Share on other sites More sharing options...
WizeMan Posted September 8, 2021 Share Posted September 8, 2021 (edited) 10 hours ago, unknownharris said: Hello there folks and hope you are all well 😇 I was wondering if someone could provide an update as to what will happen from Monterrey and further. I mean I am trying to piece together how to set-up a successful EFI now that AG has departed and zip is provided but cannot really comprehend how because you are talking in a higher expert level. Will someone be able to compress EFIs for us less simple-minded on the subject of Hackintoshing that carry the same AG original build moving forward? P.S: Don't take this as a hostile post or anything, just noting that there might be other people here as well that might be new to Hackintoshing (like me) and cannot successfuly make it work on their own as the macOS moves forward so we might need a boilerplate. Fool-proof guide: Every time a new OpenCore version is released: Download the RELEASE tag from their GitHub repo Read the Dortania post that accompanies the release because if there are any changes that need super attention it will be stated there as well. Keep a backup of your current EFI on a USB Stick's EFI partition so you can boot if things go south. Copy EFI/BOOT/BOOTx64.efi from the downloaded zip to your EFI/BOOT folder. Copy EFI/OC/OpenCore.efi from the downloaded zip to your EFI/OC folder. Copy the drivers you are using on your EFI/OC/Drivers folder from the downloaded zip. Copy the tools you are using on your EFI/OC/Tools folder from the downloaded zip. Read Docs/Differences.pdf Double check that the Resources folder structure has not changed on the new version (from Differences.pdf) Apply changes on your config.plist stated on the Differences.pdf file (if any). Open a terminal, go to the OpenCore folder from the downloaded zip then /Utilities/ocvalidate. Type "./ocvalidate " then drag and drop your EFI's config.plist on the terminal window and press enter. This tool will let you know if something's wrong with your config.plist. Open your Kexts folder Go one by one on your kexts -> Go to the acidanthera GitHub page and visit the repo of each kext, download the latest release from the Tags tab. Unzip and copy the kext to your EFI/OC/Kexts folder. Reboot PS1: I prefer first deleting the files that I am about to copy over to my EFI folder. So I do not replace the files, but add them fresh. PS2: If you read the Dortania OpenCore guide MANY MANY times then you will start understanding how to create an EFI by yourself, and this will lessen the possibility of doing mistakes when updating as well. Edited September 8, 2021 by WizeMan 8 Link to comment Share on other sites More sharing options...
eSaF Posted September 8, 2021 Share Posted September 8, 2021 AudioGod maybe absent doing other things but the Thread is still alive and well for members with queries. Big thanks to @ntuneddu and @WizeMan nice one Guys, much appreciated I am sure. 5 Link to comment Share on other sites More sharing options...
unknownharris Posted September 8, 2021 Share Posted September 8, 2021 38 minutes ago, eSaF said: AudioGod maybe absent doing other things but the Thread is still alive and well for members with queries. Big thanks to @ntuneddu and @WizeMan nice one Guys, much appreciated I am sure. 3 hours ago, WizeMan said: Fool-proof guide: Every time a new OpenCore version is released: Download the RELEASE tag from their GitHub repo Read the Dortania post that accompanies the release because if there are any changes that need super attention it will be stated there as well. Keep a backup of your current EFI on a USB Stick's EFI partition so you can boot if things go south. Copy EFI/BOOT/BOOTx64.efi from the downloaded zip to your EFI/BOOT folder. Copy EFI/OC/OpenCore.efi from the downloaded zip to your EFI/OC folder. Copy the drivers you are using on your EFI/OC/Drivers folder from the downloaded zip. Copy the tools you are using on your EFI/OC/Tools folder from the downloaded zip. Read Docs/Differences.pdf Double check that the Resources folder structure has not changed on the new version (from Differences.pdf) Apply changes on your config.plist stated on the Differences.pdf file (if any). Open a terminal, go to the OpenCore folder from the downloaded zip then /Utilities/ocvalidate. Type "./ocvalidate " then drag and drop your EFI's config.plist on the terminal window and press enter. This tool will let you know if something's wrong with your config.plist. Open your Kexts folder Go one by one on your kexts -> Go to the acidanthera GitHub page and visit the repo of each kext, download the latest release from the Tags tab. Unzip and copy the kext to your EFI/OC/Kexts folder. Reboot PS1: I prefer first deleting the files that I am about to copy over to my EFI folder. So I do not replace the files, but add them fresh. PS2: If you read the Dortania OpenCore guide MANY MANY times then you will start understanding how to create an EFI by yourself, and this will lessen the possibility of doing mistakes when updating as well. 6 hours ago, eSaF said: @xtddd and @unknownharris - Guys follow my example in this EFI Folder. Everything is updated including all kexts, I have removed all my personal data so you'll have to furnish it with your own. The changes in the released .0.7.3 is as shown and must be enabled for the GUI to be shown and the Boot to be successful. One more thing do not use any files from your previous EFI Folder apart from your personal data. Good luck. Reveal hidden contents EFI.zip 50.82 MB · 3 downloads Thank you very much for all your help, it is deeply appreciated! It's good to know that we still have people here that can support us On another note has anyone been experimenting with Monterrey? I mean are there major changes that may keep out build out of the specific OS version? 3 Link to comment Share on other sites More sharing options...
eSaF Posted September 8, 2021 Share Posted September 8, 2021 28 minutes ago, unknownharris said: On another note has anyone been experimenting with Monterrey? I mean are there major changes that may keep out build out of the specific OS version? The EFI Folder I posted above is definitely good enough to boot run latest Monterey version and BS with no problem, as a matter of fact, although Monterey still in Beta stage, I use it as my daily driver but just incase I also have latest version of BS as well. Spoiler 1 Link to comment Share on other sites More sharing options...
xtddd Posted September 8, 2021 Share Posted September 8, 2021 thanks for all the members on this thread. 4 Link to comment Share on other sites More sharing options...
xtddd Posted September 9, 2021 Share Posted September 9, 2021 i have installed big sur 11.5.2 but the system informance shows unknown about mac.. the below is my setting in the config.plist. hwo to fix it? / Link to comment Share on other sites More sharing options...
eSaF Posted September 9, 2021 Share Posted September 9, 2021 2 hours ago, xtddd said: i have installed big sur 11.5.2 but the system informance shows unknown about mac.. the below is my setting in the config.plist. hwo to fix it? Hi - I have attached two examples from my machine for you to look at and follow that may possibly help if you've just using an example EFI Folder that was posted. You need to tweak it to cater for your specific machine to get the desired results. When you make the changes, reboot, clean NvRAM which will induce another reboot before going on to the Desktop to see the results. In one of the Section of your config.plist, you need to fill in ROM data unless you removed by desire. Good luck. Spoiler 1 Link to comment Share on other sites More sharing options...
xtddd Posted September 9, 2021 Share Posted September 9, 2021 @eSaF i set customsmbiosguid to NO and now it can shows system information about mac..thanks 1 Link to comment Share on other sites More sharing options...
panosru Posted September 9, 2021 Share Posted September 9, 2021 (edited) I just upgraded to v0.7.3, I compared my config with the config @eSaF provided and I made the necessary changes (with slight differences for my particular setup). Thanks @eSaF! @unknownharris, I believe there is another topic discussing what follows after Monterey for Hackintosh community, but I will just express my opinion in a few words. I don't believe that the Hackintosh community will die, but I also don't believe that it will continue having such success. We, most likely, will return to the pre-Intel era, and the emulators that will claim to support new macOS versions will be either very buggy, or many features won't work or the hardware will be very limited, as it was when Apple was using her own silicon, before moving on with Intel chips. I hope of course to be proven wrong. Me personally, I might stick with Monterey since it will be the last macOS that will support Intel chips (partially since not all its features will support Intel chips). After that, when I feel the need to upgrade, I will evaluate my options depending on the Apple prices and where the Hackintosh community stands at that point. I might be moving to a Mac mini (I guess), but I haven't given a lot of thought on that yet. I have a five monitor setup and I don't want to make any compromises on that, if any, I would like to add more What I'm sure though, is that I won't be switching to Windows, even though I like Windows 11 a lot, and I am a C#/.Net developer (lol), I haven't used Windows as my main OS since 2006, and I don't have any plans to return. I dislike Apple a lot as a company, but I absolutely love macOS as an operating system. Edited September 9, 2021 by panosru 3 Link to comment Share on other sites More sharing options...
AudioGod Posted September 9, 2021 Author Share Posted September 9, 2021 @panosru 12.0 will not be the last version of MacOS with Intel support by a country mile. You have at least 4 or 5 more years of OS support before they do something like that or you would find a lot of Intel Mac users in the court rooms suing over there Intel Mac that they bought in 2021. As much as Apple would love to do it they simply can’t…lol…Hackintosh is safe for a fair few years yet. 7 Link to comment Share on other sites More sharing options...
unknownharris Posted September 9, 2021 Share Posted September 9, 2021 (edited) On 7/26/2021 at 10:18 AM, benjiolino said: I made a EFI with open core 0.71 and it works with MacOS 11.5 with my specs. Z390 Aorus Pro - Radeon VII. If anybody needs it please don't forget to put your serial numbers and reset NVRAM. EFI.zip 8.93 MB · 55 downloads I just tried to update my EFI using @benjiolino EFI. I changed all the MLB, Serial, UUID and ROM details and also added the pikera boot argument for my Navi GPU. Everything seems to work but now on boot I get this text on my left side before the boot menu shows up. Any ideas what is wrong? (Sorry for the bad quality was trying to capture it before it disappeared.) Edited September 9, 2021 by unknownharris Added image. Link to comment Share on other sites More sharing options...
eSaF Posted September 9, 2021 Share Posted September 9, 2021 (edited) 1 hour ago, unknownharris said: Any ideas what is wrong? I suspect the config.plist is not of the latest OC 0.7.3 and needs updating or you carried forward old settings/files from your previous. The first error on your readout pertains to Platforminfo/Generic/AdviceFeatures the default should be no. That is the reason I suspect your config.plist is out of date - see my example of the new data and how it should be. As always when updating, do not carry forward files from your previous EFI Folder apart from the SSDT files and the USB mapped kext. Use only the files from the Updated OC version and all kexts should be updated as well. I reckon if you update the entire folder and follow as mentioned above, these errors will also disappear. When done run the ocvalidate app that is in the OC Folder to check for errors before going forward. Good luck. PS - Look at the EFI Folder I posted above and do a comparison to yours. The folder is of the latest OC version 0.7.3 and all kexts are also updated. Edited September 9, 2021 by eSaF 1 Link to comment Share on other sites More sharing options...
juan e. jot Posted September 9, 2021 Share Posted September 9, 2021 On 9/7/2021 at 12:39 PM, juan e. jot said: This is a great start! Linux multi-booters, read on for a warning! Unfortunately, these steps haven't worked for me yet, as I triple-boot with one of the options being Linux. Since acidenathera have just overhauled how GRUB & systemd-boot* are expected to work with OpenCore (and it looks like it's an offshoot of acidenathera's expectation to use efibootmgr from within Linux rather than the older BlessOverride entry in config.plist; but we as yet have no corroboration from Dortania, whose guide still covers 0.7.2), I have some more tinkering to do. In fact, trying the method above while retaining my BlessOverride entry in config.plist & NOT yet installing or referencing the new OpenLinuxBoot.efi under Drivers as you have other drivers above, the OpenCanopy boot graphics go away (though I have yet to see an update to Resources from OcBinaryData), and any mention of my macOS boot drive by name goes away, too; I'm left with "Windows" and two "NO NAME" entries (one probably being macOS & the other probably being Linux, but who knows which is which), and I can't seem to space out of there to reset NVRAM. In any event, I'll try to post whatever was successful, once it is! *Weird point for Linux users & acidanthera, if they see it: Differences.pdf for 0.7.3 asserts that if your Linux distro uses systemd-boot, it's likely Arch. Um, not so; I recognize the irony of saying "BTW, I don't run Arch…," but various non-Arch distros I've tried & in fact run on various machines, use systemd-boot. Even across bases, the boot manager differs; among Ubuntu-based distributions, for example, elementary OS (currently) uses GRUB by default, but Pop!_OS (currently) uses systemd-boot by default. So getting one or another BootLoaderSpec/[ByDefault] way of booting to Linux consistently, with either consistency or a clear delineation between GRUB & systemd-boot in the instructions, will be great, moving forward. Thanks for reading this far! UPDATE: Got 0.7.3 working with 11.5.2 & a previous Linux (and Windows, but no issue there… so far 🤜🪵) install. Had to do as @pkdesign had suggested in his previous 0.7.3 success post, and even with a bit of experience, backed up & reviewed @WizeMan's fool-proof guide of yesterday; it brought me to ocvalidate, which I hadn't used before (and is newer and probably more secure than https://opencore.slowgeek.com/). In a nutshell, pkdesign was right, and properly applied, his steps were all I needed. Compare your config.plist to Sample.plist from the latest OC package, paying particular attention to the tabbed-toward-the-right (how many tabs?) placement of "<array>", "<dict>", etc. I was finding things placed at all sorts of tab levels that were allowing OC to boot, but not offer services for which it couldn't find the drivers, in its new "Drivers" layout. Nothing special was needed for me to select and successfully boot to my pre-installed Linux installation on a separate physical drive from macOS. A separate computer stuck using OC 0.7.1 for various reasons, with macOS & Linux sharing a drive, still needs BlessOverride properly pointed at Linux's boot .efi file, as in option one of https://github.com/dortania/OpenCore-Multiboot/blob/master/oc/linux.md. But at least since OC 0.7.2 (maybe earlier but I can't test), just the separate Linux drive with its properly-configured EFI being installed & powered on, allows OC's GUI to see & allow boot to Linux (just as it does with zero configuration to WIndows). You can definitely follow option two at the link above in this bullet point; just be aware that like selecting macOS as default boot from within System Preferences, whatever you set with efibootmgr will be wiped out if you reset NVRAM. In my experience (YMMV), you'll still be able to boot to any of your OSes installed on separate drives, provided you can get to the OpenCanopy GUI. So lastly regarding Linux; if inclined, check out & fiddle with acidanthera's new setup for Linux boot selection; it will likely help with dual/multiple OS installations on a shared single drive if/when BlessOverride support goes away or changes its focus. But for the moment, my multi-boot installation with a separate drive for each OS is working well without BlessOverride or the new Linux selection setup debuted in 0.7.3. Speaking (above my last Linux point) of getting to the OpenCanopy GUI, I was having the darnedest time doing just that! I had re-downloaded the entire archive of OcBinaryData to see if my EFI needed an update to Resources, and that did not help me get past the text UI of the OC booter; once drivers were set up properly in config.plist, it let me boot up fine, just didn't look like the GUI I'd come to expect. Luckily, a full swap of the EFI/Resources folder from @eSaF's sample EFI above on this page, worked to restore OC booter GUI access. This brings up a final point; sometimes things get corrupted. I dunno what was wrong with the previous Resources folder I had brought over from 0.7.2, but a full, not file-by-file, replacement fixed it. That also happened with the reference to one of the .kexts from my updated 0.7.3 (based on my previous 0.7.2) config.plist; one of the references to a .kext there had somehow gotten lines removed and the order of other lines scrambled. So I rebuilt the reference, in the image of other such .kext references nearby, and ocvalidate approved my efforts. I now have a full suite of .kexts working for my install; yay! Thanks for hanging on through the blow-by-blow of "this is what I screwed up, and this is how I fixed it." It's no TED Talk, to be sure. But hopefully it helps for any experiencing similar issues. 3 Link to comment Share on other sites More sharing options...
eSaF Posted September 9, 2021 Share Posted September 9, 2021 @texem Hi Bro long time, welcome back! Yea on the introduction of Monterey my WIFI/B-Tooth card was not recognised specially the B/T which worked fine in BS so I started to mess with it and damaged it in the process. Don't tell @AudioGod knowing how much he hates Fenvi Cards but I bought a T-919 card and the B/T side was not recognised. I sent that card back to Amazon and they sent me another which worked OOB instantly. Meanwhile AG sent me an Apple Card that needed a little soldering which I managed to do and I fitted that in my brother-in-law's hackingtosh so at the moment the T-919 is still working ok for me in Monterey. 2 Link to comment Share on other sites More sharing options...
texem Posted September 9, 2021 Share Posted September 9, 2021 hi buddy, i deleted my text but you have already replied 😉 thanks for that ok, my problem is not the recognition of the PCIe BT-card, but since the transition from beta 5 to beta6 the bluetooth daemon is bugging around. After wake from sleep, the devices are gone. If I restart the BT daemon via commandline with "sudo kill -HUP bluetoothd", everything re-connects again. In addition, the BT mouse in the OC menu is dead after rebooting the system . So there is something wrong and I am curious to see if it will get worse in the next beta. Greetings to you and everyone here 1 Link to comment Share on other sites More sharing options...
panosru Posted September 10, 2021 Share Posted September 10, 2021 @AudioGod, I hope you are right, Apple said that they will continue Intel support for two more years, therefore, I'm not sure about next macOS releases, but even if they will, many of the new features won't be available for Intel based machines. Link to comment Share on other sites More sharing options...
Recommended Posts