Beginners Guide to using OC Auxiliary Tools App (Also known as OCAT)

[trs96]

Every config contains comments which you can only see if you open it in a plist editor.

The presets are located in the App itself: /OCAuxiliaryTools.app/Contents/MacOS/Database/BaseConfigs

Looks like the baseconfigs are also in a hidden ocat folder inside my User folder. What is the purpose of that ?

 

[5T33Z0]

This folder was introduced later to manage different variants of OpenCore. It contains all the files that the OpenCore Package has – but for all 4 variants: Release builds, Debug builds and "Dev" versions of both. "Dev" are basically the nightly builds from Dortania's repo - kexts included.

If you ask me: the dev should just have created a regular folder for it under "Documents". For all things regarding the app you would have to ask the dev about "purposes". I am just a user who had some input on the design of thes sync window, made some feature suggestions and created some content for the database and Quirk dropdown menus.

 

[1Revenger1]

I recently tried it out and it did not appreciate the structure of my Kexts folder lol. OpenCore allows kexts within folders in the Kext directory, and OCAT seems to recognize it mostly fine. When adding kexts from the EFI though, OCAT just duplicated the Kext and put it at the root instead of using the nested copy in my EFI. It also didnt give me the option to update those kexts as it couldn't find the available versions. What was even weirder is that it got the correct current version.

It also gets the order of kexts wrong when adding VoodooRMI and VoodooSMBus at the same time. Easy to fix by hand, but sort of annoying since it does attempt to fix kext ordering (by just putting Lilu and VirtualSMC first). I'd rather OCAT either not mess with order, or do it right for every kext by checking Kext dependencies. Only giving the right output in certain circumstances can be a bit confusing if people say that OCAT does give the correct order. ProperTree handles both the nested folders and Kext dependencies pretty well, so hopefully some of that logic can be carried over. I did submit a bug report so hopefully some of this can be fixed.

Edit: oh, it did also zero out my ApECID value. Turns out that OpenCore+ProperTree accepts a 64 bit unsigned value when most other Plist editors expect a 64 bit signed value. The unsigned value ended up being greater than the max signed value, causing issues. Partially my fault but still annoying. Was fortunately just messing with an EFI on my desktop.

 

[esafeddie]

I recently tried it out and it did not appreciate the structure of my Kexts folder lol. OpenCore allows kexts within folders in the Kext directory, and OCAT seems to recognize it mostly fine. When adding kexts from the EFI though, OCAT just duplicated the Kext and put it at the root instead of using the nested copy in my EFI. It also didnt give me the option to update those kexts as it couldn't find the available versions. What was even weirder is that it got the correct current version.

It's amazing you found those negative aspects within OCAT. I can say hand on heart I have never experience those as you described, albeit I run it to fetch and update Nightly OC versions and Dev release kext versions, if newer kext versions are found, they are always placed in the kext folder, never otherwise.

You reported you didn't get the option to update the kexts as it couldn't find the available versions, check the Source (as shown) for possible correction. I don't know about it changing the kext order as I have never experienced that happening personally.

This is my EFI Folder and I try to run it as clean and clutter free as possible and I alway use OCAT to update all aspects of it but I do check the process each time, plus it does has the ability to make and keep a recent working EFI copy before all the changes were made.

 

[trs96]

Here's a simple tip for @c-o-pr or anyone else worried about losing or corrupting their working (GM) EFI folder for whatever reason. Create a folder in documents for just your EFI backups. You can even drag it to the Finder sidebar for easy access. Put a copy of just your working EFI in there, don't clutter it up with other EFI folders for different sytsems. Zip it up so that no app used for EFI/config.plist editing can ever "mess" with it. Sleep well at night with no worries.

Keep one copy on a USB flash drive as well if your hack ever becomes un-bootable for whatever reason.

 

[c-o-pr]

Per previous few posts:

• Is it true that Acidanthera kext order in config.plist no longer matters? What version of OC changed this?

• Anyone who is learning to apply OC using OCAT will of course develop a working style which protects their config.

• OCAT might help a new user jump-start awareness of common OC chores. Nothing wrong with it as an intro learning aid—as long as you don't ask yourself the question Why do I want to be learning any of this at all Lol!

• The value proposition of a tool is its leverage divided by its hazards. OCAT offers leverage by hiding some maintenance chores for sake of convenience. But it's not complete enough to truly abstract away the inner details of the tools it hides. It introduces many new hazards. To understand what to expect and how to cope with pitfalls, the OCAT user must know the details of the underlying tools. So OCAT creates a contradiction. To use it properly, I need to know how to use what it hides, but if I know about what it hides, why do I need OCAT?

Push-button convenience is one big justification! As long as the buttons makes sense.

If the buttons create hazards that can only be resolved by end-running the tool, the convenience will not be worth it.

So, what buttons does OCAT offer and what are some hazards? Thence my long previous report.

The genius of Dortania Guide is that its creators realized that the solution space was too complex to offer a configurator, so they wrote down a science of hack config in a way that anyone can follow to learn and deal with common contingencies. They made it as simple as they could, but not too simple. That's Democratic. It encourages others in to learn and participate.

OTOH OCAT is more about capturing some pseudo-scientific lore into an ill-conceived configurator which gets ministered by a priesthood who instruct acolytes as to how many our-fathers and hail-marys they should recite to receive the blessing of a working hack. Because it hides details without offering a dependable mechanism, it becomes a trap. This is totalitarian and repressive. It might be worth it if God favors your hack through powerful prayer. But I didn't find any evidence of divine inspiration. Maybe my faith is lacking.

I suggest considering what you expect when you try a new text editor. First there's usually nothing new under the sun with XYZ text editor. No one offers or recommends text editors based on the expectation that by typing into it with a certain pattern you can expect you write cogent essays...

Yet!

That's why I joked about ChatGPT in my report. I heard Microsoft is adding prose generation to Office.

Maybe a chatbot will soon be able to contrive at record speed a working OC config from tonymacx86-user build summary. Forum users no longer need to know how anything about how to do it themselves? Srsly: Github Pilot for Acidanthera.

We are standing on this precipice.

But OCAT is not an ML config generator. It's a one-off plist editor with some OC build scripts grafted onto it. To know whether and how to use it, you already need to know how to plist edit, and run OC build scripts. Maybe new users should just keep learning how to do this with the generous guidance of mods.

As to learning config numbers by reading Preselections, It might be better than nothing?! But why should anyone trust the boilerplate that's embedded in OCAT? Who curates it? How do they ensure it's correct and appropriate? How is it updated? I would assume boilerplate config will be curated about as well as OCAT integrates OC scripts and a plist editor.

I like OCAT as a demo that config.plist editing can be married to a build configurator. And it offers a learning experience as such.

 

[Edhawk]

As long as the kext dependencies are ordered correctly, then the kext order doesn’t matter.

Lilu.kext doesn’t need to be first and VirtualSMC.kext doesn’t need to be second in the Kernel > Add section of the config.plist. This happened July 2021, the kexts are now ordered by CFBundleIDs and OSBundleLib. See the closed issue I raised with Corpnewt regarding this issue.

Incorrect kext sorting in config.plist with Clean Snapshot · Issue #94 · corpnewt/ProperTree

Using the latest version of ProperTree, with Python 3.9.6 installed. I created the ProperTree application using the buildapp-python3.command. When running the OC Clean Snapshot option from the Prop...

github.com

 

[5T33Z0]

@1Revenger1: What do you mean by nested kexts exactly? Do you mean actual sub-folders in the kext folder – thi would be new to me – since it's undocumented . Or do you mean kexts which contain additional kexts as plugins within it? Detecting the latter usually works, but what I've learnd from the dev is that there are some canndidates which it has issues with. ProperTree handles that better when you just throw kests at it. But in my tests, Puttin Lilu and VirtualSMC at the top always resulted in better boot times.

@trs96 As far as backups are concerned: there's a button for it. Klicking it saves a zipped copy of the EFI folder (with date) on the desktop. Having a zipped folder of the EFI in your ESP doesn't really help you if the system won't boot unless you're real good with the shell. And there's always the 200 MB limit.

 

[Edhawk]

Corpnewt added Nested folders for the /EFI/OC/Kexts folder to his ProperTree script/app, but I can't recall when this happened exactly.

 

[Nodarkthings]

@1Revenger1: What do you mean by nested kexts exactly? Do you mean actual sub-folders in the kext folder – thi would be new to me – since it's undocumented . Or do you mean kexts which contain additional kexts as plugins within it? Detecting the latter usually works, but what I've learnd from the dev is that there are some canndidates which it has issues with. ProperTree handles that better when you just throw kests at it. But in my tests, Puttin Lilu and VirtualSMC at the top always resulted in better boot times.

@trs96 As far as backups are concerned: there's a button for it. Klicking it saves a zipped copy of the EFI folder (with date) on the desktop. Having a zipped folder of the EFI in your ESP doesn't really help you if the system won't boot unless you're real good with the shell. And there's always the 200 MB limit.

I'm using specific versions of some kexts that I put in /Kexts/10.9/ and /Kexts/10.11/. I think even on my first trials (back in 0.6.7), this was working (provided you set config.plist accordingly). Those kexts are RealtekRTL8111.kext and AppleALC.kext in my case.