Leaderboard

Enter shell from picker: fs0: cd EFI/OC edit config.plist You'll figure out rest.

It works in Mojave

it works!! thanks vector

@Sherlocks try this: buildpkg.sh.zip

@darthsian That point does not relate to ACPI, which there is no good point for such a quirk, but only to SMBIOS. The thing with SMBIOS is, we consider OpenCore to be an environment, where we expose Mac information to seamlessly boot macOS. Now, if you do not want Windows to be part of that environment, the most intuitive solution is to just not boot Windows through this environment. Why do you want to boot Windows via OpenCore "so badly" if it causes trouble?

Regarding the external GUI part, as @Download-Fritz mentioned, it had been here for quite some time already. When @n.d.k first appeared with the changes that did not line with the primary project architecture, we immediately suggested him to use this option. For unknown reasons on our side, there was no subsequent dialogue and eventually this fork appeared in entire silence. Not to sound salty, but to me, as an Acidanthera lead, it looks like just another example of an intentional move driven by egos/money/lack of culture/megalomania/alike. Basically it is very similar to the situation with bootloader configurators, where the developers ignore any attempt of a constructive dialogue, or Clover/Chameleon forks in older days. Sometimes the need for forking can be justified, but in general it is just a case of everyone pushing the load forward with a sudden person starting to push it sideways, who eventually gets tired of it and leaves a mess that confuses everyone. This of course is counterproductive, but somewhat unavoidable. By making our projects opensource we make it possible for adequate determined people to push things forward, either with us, or after us.

Motherboard: ASRock Fatal1ty Z370 Gaming ITX/AC CPU: i7-8700 Cooler: Noctua NH-L9i Black Ram: 2 x 16GB Crucial 2666 PSU: Pico PSU 250W with Dell 12v 18A Brick HDD: 1TB Intel 660p Nvme SSD WIFI/BT: BCM943224PCIEBT2 on M.2 NGFF adapter Case: Chinese "Aluminium" ITX Cost is about 1/3 of similar spec Mac mini Edit. Final look: Edit 2 Changed Led to green as Apple would do Original case:

if no patch works, see if there is this option in the bios, and disable it

1) certo che non lo so. Manco pe niente! 2) Il bios credo sia giusto con alcune cose disattivate come da varie guide lette, forse anche in questo forum. Comunque ricontrollerò tutto in base al tuo link. difinisci "affiancare" Scaricherò i due test ma prima devo capire bene come muovermi, come caricare al volo. La GUI penso si debba entrare in clover config e caricare questi config ed usare il computer... giusto? (Risp quando puoi, mi hai dedicato fin troppo tempo per oggi). Grazie di cuore

Change commited. If there will be problems we can revert the commit, but I don't think

I am confident (ok not 100% sure ..as I'm in 10.15.3 and not in 10.15.4 beta..) that this will work: buildpkg.sh.zip

What about value 00010000? Also, what's the value by default if you don't inject it?

Sherlocks it is difficult to imaging what's going on if you don't post the installer log:

EFI/Clover/Drivers/UEFI

ah! No xar ??? This is going to be problematic. I think it expect to use the pbzx instead on newer OSes. The big problem is that without xar Installer.app will not be able to run the pkg. If this is confirmed in the final release ....this is the death of the pkg, unless we sobstitute xar with pbzx, but in any cases compatibility with 10.10 and older (?) is lost.

yes. after update 10.15.4 beta1, it is happen

hello try this config, only one patch has been added to the kernel config.plist

Usually before doing a "release" the code must be tested. Only when developers decide it is stable enough you will see the product under "Releases" at github. For now you can find the app to be tested (as per title of this topic) at the first post.

OK, I think I may have discovered the problem. I know this is affecting zero other people right now, but if anyone else ever tries to hackintosh a X11DAi-N with the latest firmware, they'll (hopefully) find this post helpful. So it looks like Supermicro is using the LoadTable() function to selectively load several additional SSDTs based on BIOS options (specifically, those relating to power management for the CPUs). LoadTable(), according to the ACPI 6.x spec, is supposed to load an additional DefinitionBlock containing .aml file into the ACPI namespace. Of course, to allow these tables to be selectively loaded, they cannot be declared as DSDT or SSDT types, as the OS would load them automatically, removing any ability to only load certain ones. These tables are, in fact, SSDT tables, but they're named with nonstandard table types, specifically OEM1, OEM2, OEM3 and OEM4. Any OS will see those types and simply ignore the tables, unless one of them is forced to load via either a DSDT or SSDT table invoking LoadTable(). Therein lies the problem: LoadTable() is an AML function, and inside AML code. That means it happens at run time, when the OS is actually executing the AML code contained in the DSDT and SSDTs. It is important to remember that AML is a combination of hardware/device descriptions, but also executable code that lets the OS interact with said hardware. macOS appears to perform the table loading and AML code execution separately, as based on my BIOS settings when I took that screenshot in my last post, tables OEM2 and OEM4 should have been loaded. Yet, at the bottom, it says 5 tables were successfully loaded. There is the DSDT of course, plus 4 SSDTs, which is 5. If tables OEM2 and OEM4 (remembering that these are secretly just SSDTs) were being loaded by macOS, that count would be 7. The specific point where LoadTable() is called is upon executing various standard ACPI functions on the CPU device descriptors. Supermicro's intention was to selectively load things like HWP SSDT tables or legacy P-state tables depending on certain BIOS switches (ACPI variables that it checks with an if statement). I think macOS must only support static loading and not dynamic table loading, and then when it tries to execute the loaded DSDT and SSDTs, it reaches a LoadTable() call and can't find the requested table (since, being of a type other than DSDT or SSDT, were never loaded upon initialization), it just hangs. I'll hopefully test this theory later today, I have to rework the Supermicro SSDTs a bit. I'd rather not drop the table entirely if at all possible.

Wow, this got heated, all I did was a nap! Vit's team knows what they are doing and the community appreciates their efforts in the project. if NDK wants to folk his own and not listen to recommendations from the people that put the work into the project from the beginning, and also people want to use this version. then that's their choice. Of course i have tested it and a GUI would suit some people, I'm more interested in the functionality and stability of it. Amen.

I know of 100s of users that are using different chipset of Asus motherboards and none of them are having any issues. Myself including with my "Asus z9pe-d8 ws".

So... I assume you are representing "those large number of users". I have been using OpenCore since it was in 0.0.1 one 3 different system configs, with and without UEFI and most importantly AMD setup with out any issues at all. All features work that are described in the documentation. I am not sure of what "design decisions" that does make some motherboards not work properly in Opencore. You also have to remember that OpenCore is still in the "beta" phase of its development cycle. If you have the knowledge and skill to fix some of these "motherboards not work properly" I would assume @Download-Fritz and @vit9696 would always appreciate a PR.

Those "large number of users" simply do not take the time to delicately read the configuration documentation, which will result in them not being able to use Opencore. It has nothing to do with "design decisions".

I have not defamed anyone. Claims were made that the design is flawed, and I countered the claim with the fact that the design is not understood. If you know how bless works, and how the boot path must be determined dynamically every boot to account for edge-cases like macOS upgrade (I used the wrong term in my previous post), you know that hardcoding is not a good idea. I did not check the exact implementation, but from the snippets I saw, in case of an upgrade, just like with Clover, you will probably end up with two separate boot entries (normal and installer boot, because the bless-detected installer path will no longer be matched with the custom entry path), while normal is prefered for being a custom entry (which have been moved to the *front* of the boot priority in the fork). Ergo, normal OS will boot as default. Of course that can be hacked around by detecting this case somehow, but you get the idea - hacks break. If my wording seems like I have tried to insult someone for being stupid or such, I'll apologise for that. I was strictly speaking about a lack of knowledge and insight into the Apple boot concept, which has nothing to do with IT experience or such at all - it is a specific model. Clover, its friends and this fork break this model, and we do not agree with this based on the factual situation. Once again, I do not mind @n.d.k's work at all and respect his decision to maintain a fork (though I agree, a custom GUI driver or app would have covered most if not all changes in the fork without emerging two products doing mostly the same). I do not respect @meaganmargaret's attempt to make justified and well reasoned design decisions look like ignored defects. Certainly, I'm not the one claiming things are "beyond" people. Please provide a mean of proof, and I will handle the rest.

Am I not allowed to find it amusing how people who do not understand the core design decisions for lack of knowledge and experience keep acting like we are blind and deaf, carrying most obvious ideas to us, things that have been done this way in Clover for years, thinking that we have not spent even a second of thought on it because we do not agree with the practice? Believe whatever you want to believe is flawed - when a macOS upgrade hits, we'll see where things like overriding custom entries will get you... probably not seamlessly into the installer, unless arbitrary hacks are implemented.

Even better solution! email tech support. I just emailed asrock and said i was doing a linux box and needed those options for some proprietary hardware and they sent me a unlocked bios within 2 days. Pretty amazing support actually.

This guide describes how to remount an NTFS partition using native read/write support without requiring any third party software. Online resources indicate the Apple NTFS drivers have had this "experimental" feature or some time and my experience with it has been it's effective for temporary access. Create a folder called "Mount" inside your user profile folder and enter the following commands in Terminal: diskutil list (Identify the NTFS drive or partition ID diskXsX) sudo umount /dev/diskXsX sudo mount -t ntfs -o rw,auto,nobrowse /dev/diskXsX ~/Mount You now have full access under "/Users/username/drivename" but not on the desktop or in Finder toolbar which aren't supported. Later in Windows you may need to set the NTFS permissions under the security properties tab when you try to access any files and folders you added to that drive. Extended attributes on some files can cause them to be grayed out when the drive is mounted in macOS/OSX again. If so open Terminal change to the NTFS drive or subfolder and enter the command below to correct this problem: xattr -d com.apple.FinderInfo * Unmount or eject the drive when finished. You must eject the drive in Windows using the Safely Remove Hardware icon in the task try otherwise it won't mount as read/write in Mac. There is also a tool called Mounty that automates this process and covers most of this info on it's website.

Posts about Nvidia graphics go in graphics -> nvidia Posts about laptops -> laptops (duh, right? You'd be surprised) Posts about power management (sleep/wake, CPU states) go in power management The "Desktops" section is for pre-built desktop systems, not for motherboards in a desktop PC that you built yourself. And so on. The entire DSDT section has just undergone a thorough spring cleaning (it's spring now down here in Brazil). If you can't find a topic that was here or in the "General Discussion" section (which is now gone), it's because I have moved it to where it should have been posted in the first place. What was "General Discussion" is now "Ethernet, WiFi and Sound" and all related posts have been moved there. All posts in "General Discussion" were moved here. I have moved hundreds upon hundreds of posts today. This involves boring chores such as googling whether HP Proliant Optiplex Acer Bazillion SLY3245DLH US is a laptop or a desktop computer. Please try to post in the right place and help us stay organized. If everybody posts in the right place, it'll be easier to find the information you're looking for, this serves everybody's interests, not just those of volunteer moderators. Now for something different, yet related to what I've been doing here today: We had many topics here with non-descriptive titles, which I have been painstakingly renaming out of pure unadulterated love for this community. lol Please consider that "I need help with DSDT plz" is not a very good title for your topic. Of course you need help with your DSDT, if you didn't, you wouldn't be posting here in the first place. Try to come up with a descriptive topic title that includes at least the manufacturer and model of your motherboard or your laptop/pre-built desktop, or something that briefly describes the issue that you need help with. This helps to attract the attention of those why might know exactly how to help you, as well as others who have the same issue and arrived here by using search engine (It also makes moderators happy when they are cleaning up forums). InsanelyMac is not just a place where you post and ask for help, it is also a vast library of information. Descriptive topic titles and posting in the right place are two things that make it easier to find specific information. Thank you on behalf of future users and the entire insanelymac.com staff!