Follow up...
So once I chose 'Latest Version' the list of other recent OC versions was populated and I could get to work updating my build EFI from OC 0.8.3 to 0.8.8.
From there I decided to keep notes and post my experience.
* * *
WARNING
Please regard the following diatribe as one-layman's impressions of OCAT at first use. I will praise OCAT for what I see as its strengths and lament it for its failings. I am not an expert on hacks or OC. I have no skin in this game besides my one build. I'm just a simple man living at the edge of the galaxy trying to make his way by serving as a genetic template for of an army of clones contracted by Master Sifo-Dyas from planet Kamino.
* * *
Again my job was to update OC for an existing build. OCAT made this easy. Big thumbs up! I already know how to do this by hand, and OCAT made the work easier.
Along the way I got a clearer sense of what chores can be thought of as being within OCAT purview and what is outside. At the most basic level, OCAT is an OC-aware plist editor. It has a some of buggy hooks for working with EFIs, but these only go far enough to let you realize that everything about configuration mgmt is outside the purview of OCAT.
I'll start with its strength, then pick it apart.
The strength of OCAT is that it integrates the following tools:
- Retrieval of OC and boilerplace kexts at a given rev level from Acidanthera github.
- Local EFI editing of one copy of drive ESPs in any working folder you choose.
- Copy a EFI from a drive ESP to a statically named Desktop folder.
- Edit config.plist with UI awareness of OC config.plist structure, OC Configuration.pdf documentation, ocvalidate for the given rev, and keyword search.
- Generate and check of PlatformInfo > Generic serials (for new builds)
- "Preselection" of various config.plust data details from an internal build database.
- Access to an internal database of config.plists named by build form-factor and some boilerplate build ACPI .AML files.
- Some kind of aid for running "DEV" and "DEBUG" versions of OC. I don't know what DEV means in context, but I think DEBUG pertains to the DEBUG release version of a given OC. I didn't figure this out.
OC UPGRADE RECIPE:
To repeat— For hack builders, the obvious value of OCAT is that it truely eases updating OC releases as follows:
0. Get copy of EFI into a working folder. Due to OCAT bugs I couldn't use built-in Mount feature.
1. Choose OC rev in OCAT and pushbutton download OC + Acidanthera kexts at desired rev-level. OCAT only supports one OC rev at a time.
2. Open config.plist within an EFI and Sync downloaded rev with your chosen EFI folder.
3. Sync causes Autopopulation of new schema keys in config.plist UI.
4. Access the OC rev's Configuration.pdf via Help Menu. (PDF Opens in Preview)
5. Pushbutton generate ocvalidate report for your config.plist
6. Use OCAT Search box to look up keys in the ocvalidate report to find them in the config UI. (Search box is crucial to finding keys.)
7. Search within Configuration.pdf for tech details on new keys (new schema).
8. Edit new key values in config as needed according info in the doc. The new keys are included in the OCAT UI, so just need to set values—If OCAT automatically set new keys to safe values this would be even better this would be even more convenient.
9. Save your updated config.plist. Your EFI now includes all the OC boilerplate for your chosen rev, ready to be deployed into an ESP.
10. Deploy.
NOTES TO SELF
- This process assumes that you are upgrading OC. It's not clear if you can use the same process to downgrade to an earlier OC revision. Think about this as something ourside of OCAT.
- Kext list UI helpfully reports versions in use, unlike plist editor.
- OCAT does all its work on the EFI you select, which could be in-place on an ESP, or in a folder elsewhere. Use care.
- Always set aside in-progress versions of build EFI outside OCAT. OCAT is not a version manager or control system. It's only got hooks for merging a newer version of OC+Acidanthera kexts into a chosen EFI and manipluating config.plist, not for managing builds.
- At some point OCAT (Open? Sync?) saves a copy of the existing config.plist, When will this copy may be overwritten?
- OCAT may populate or depopulate config entries without notice...? Voodoo. - OCAT crashed and left my config in weird state.
- NEVER leave valuable config in the OCAT default area ~/Desktop/EFI
it will get clobbered!
MORE IMPRESSIONS:
- The above upgrade process is the essential value of OCAT.
- It could also help the creation of a new hack by starting from a Golden Build EFI.
- Assuming OCAT is consistently maintained on par with OC, it might reward anyone who takes the time to learn it with time savings on OC updates. But only if it's maintained at a better pace than OC.
- Forum mods might find OCAT handy, because it eases some routine aspects of EFI review and updating of regular-joe EFIs. A mod can dump an EFI into it, pull a version of OC, get an ocvalidate report and surf through looking for red flags. *** It looks like OCAT can only work on one build revisions at a time.
- The included build database and preselections suggest it could be become much more than this in the future, but such potentials are only hinted. Closer inspection suggests config mgmt is a mirage. If it has a future, it appears to be unwritten (Lawrence of Arabia).
- OCAT's "Database" is a total mystery. Where does this come from? What's in there and why? How is it maintained? Updated?
- The flip side of OCAT update conveience is that it becomes obvious that what's needed is builds mgmt, which OCAT doesn't actually offer. OCAT is a slippery-slope towards shakey dependencies on OC releases and build-specific config of unknown origins and quality.
- For new users, OCAT could be a step backwards because it increases the apparent steepness of the OC learniing curve. As OCAT provides more of an illusion of build assistance that actual support. OCAT build config is an unstructured mess of arcane details. A huge mess. If you have no expeirence you're goona be overwhelmed while being led down a primrose path. It could create epic disappointment in novice users.
REGARDING HOW TO BUILD — IMO, THE SINGLE BEST TOOL FOR NEW HACKINTOSHERS IS THE DORTANIA GUIDE. THE GUIDE IS A WORK OF ART AND REQUIRED READING FOR EVERY USER. LEARN IT. LIVE IT. LOVE IT.
OCAT USAGE EPHEMERA:
+ Unlike 0.7.8, the 0.8.8 ocvalidate report includes a version output which clarifies the report. Revision information is crucial to making sense of the ocvalidate report.
+ Re mounting EFIs, I changed the OCAT preference to enable "Show all volumes names when mounting ESP" and the next time I used "Mount ESP" OCAT hung. I had to force quit and lose my work. Disbaling the preferecnce stops the hang but list is incomplete.
+ The Desktop/EFI folder managed by OCAT is a trap! It's an overloaded working area. Anytime you choose a build template from the Database, it just overwrites the Desktop/EFI without warning, even if you have changed config.plist. Because it's name is fixed, there's no way to maintain context for what's being edited. It's a disposable scratch area.
+ When you choose "Browse Catalog" a Finder windows opens to Desktop/EFI... So I guess "Catalog" is another name for this working area?? If there is no Desktop/EFI, nothing happens when youo hit the "Browse Catalog" button.
+ There's no sense to many features if config.plist is not within an EFI, but OCAT doesn't care.
+ What's the relationship between OC revisions, Build Database, boilerplate ACPI .AMLs, and Preselections? OCAT only appears to integrate all these concerns, while actually creating a nightmare of uncoordinated resources that are pig-piled into whatever EFI OCAT has at hand. There's no harmonization of the currently loaded OC revision and the currently opened EFI (config.plist). For example, when you load a build using the "Database", there's no connection between that EFI the OC rev last loaded. None. But OCAT runs ocvalidate anyway, which lists errors of course. How to you figure out what OC rev goes with the chosen build from the Database?! Does the user really want to attack updating OC at the same time he is trying to assemble a new build? When you chose a build from the database, OCAT tells you to populate the EFI by hand, because the Database doesn't include needed support items. All these concerns must be managed outside OCAT but all the resources are within OCAT. Crazy-making!
+ The Desktop/BackupEFI folder is also a mess. It receives zipped copies of whatever ESP was mounted when you hit the "Backup EFI" button with no context for what ESP is mounted, no information reported about what is being backed up, and the zip files created are named with just dates and no other information. Again, If you want to make with these (assuming you can comprehend them) you have do it all outside of OCAT.
+ What's the relationship between "Preselections" and "Database"? This will boggle expeirenced OC users.
+ The OCAT UI is minimally organized by the structure of config.plist, but this is a long way from making sense of build config.
+ OC options (e.g., Quirks) are incomprehensibly splashed accross the editing pane. Scattered checkboxes are a horror. I wish that all OC keys were organized as lists, like in a plist editor.
+ The Serial generation and check seems convenient—sort of, assuming it is presented in context of a new build recipe. But even overlooking the lack of context, it's unclear from the button arrangements what will be generated. The 'Generate' button next to SMBIOS obviously looks like it generates SystemSerialNumber. But it also generates SystemUUID and MLB. However separate Generate buttons are included for SystemUUID and MLB. Unintelligle. Once you hit these buttons any previous config is lost — as is the case across the entire OCAT UI.
+ Sometimes the OCAT UI becomes unsyncronized and clicking tabs (Add, Edit, Force...) doesn't update the edit window pane. A huge bug. Sometimes clicking a selector on the left (ACPI, Booter, DP, etc) de-glitches the window. Sometimes you lose your edits.
+ Playing with the OCAT > Edit > Debug/Dev options caused my config to be lost (everything went blank), then OCAT crashed and all edits were lost. So I wasn't able to figure out what these Edit features do.
EVEN MORE THOUGhTS:
+ Preselections are not handy, they also are a trap! Let's say you've got an existing config with data in it— Most of us do. You start fooling around with Preselections and now that data is gone. If you made other edits before you tried a Preselection, maybe just see what it does, you're wrecked because there's no way back exept going outside of OCAT. Very bad.
ONE OF THE MOST PRECIOUS ASPECTS OF ANY HACK IS WORKING CONFIG, SO WHY IS OCAT SO DISRESPECTFUL OF EXISTING CONFIG?!
Reviewing all the OC config details exposed by OCAT it hits me how OC is insanely complex and pretty much totally inscrutable. As an OC user, I've been progressing a build and reading the forums regularly for 2 years. I don't know what 90% of the contents of config.plist mean. OCAT makes this situation even worse.
+ Running ocvalidate tells the user nothing about the appropriateness of a config.plist for any build. As a contrary example of ocvalidate, a config.plist might generates a woeful number of ocvalidate errors but still be considered correct and work just fine. Ocvalidate is like saying Our Father Hail Mary. It's not any insurance of correct config, nor even evidence that config.plist is minimally reasonable. There's no cross-checking of anything in config.plist with any other aspect of OC. ocvalidate is simple check of schema items syntax against release notes. That's all. OCAT itself should ensure correct syntax of config.plist, not graft on a button to ocvalidate.
+ Behind all these peculiar traits lies an enormous trap which I think will be biggest pitfall for any user of OCAT: losing track of edits. OCAT encourages users to make changes that will immediately result in config dependencies going out of sync with a build and there's no way back for the user but to throw away session and start over from a saved EFI. This integrity pitfall manifests in both small ways, such as uncoordinated checkboxs and edits, and in big ways, such as disharmonized EFI resource dependencies.
For the small stuff, it is much-needed that the OCAT UI prevents accidental or unwise changes of config data. Everything should require a select gesture before any data gets changed because you will never figure it out in the context of OCAT UI if you make a slip. As things stand, if you introduce an error, you will have to move outside OCAT UI and use tools like diff(1) to figure out what changed. Config mgmt is a bugaboo!
For the big stuff, let's consider some usage scenarios. How does an OCAT user think about maintaining multiple EFIs at different rev levels? Is someone on the forums going to write recipe posts for how to approach different chores? I imagine recipes like:
- New from Golden Build,
- Update working EFI with latest OC,
- USB Mapping from Catalina to Ventura,
- Switch From Iwlm to Broadcom,
- Thunderbolt: Where there's Maple Ridge There's a Way,
- 1,000 Edits to Address Broken Sleep,
- Windows Istaller Ate My EFI,
- Advanced Topics: Moderator Build Juggling 101.
Unfortunately, while OCAT provides an illusion build awareness, it provides no actual support for such recipes.
OCAT WORSENS CONDITIONS YOU HOPE SUCH A TOOL WILL MAKE BETTER.
+ It appears the OC download is stored in ~/.ocat. It populates this area with OC version and with a Database folder, which contains the OC boilerplate folders: kexts, ACPI, drivers, etc. While these folders are grouped together in an production EFI, they actually do not come from the same maintaniers and refect seperable concerns which are both interdependent and possibly mutually incompatible. For example, the ~/.ocat/Database/OC/ACPI folder is populated with boilerplate .AMLs for build details which Dortania Guide describes as created for specific HW generations. — Maybe this has all been sorted out since I last read the guide a year ago? Are all these .AMLs perfect boilerplate? I'm wary.
Similarly, the how does the ~/.ocat kexts folder work? It contains the Acidanthera kexts: Lilu, AppleALC, WhateverGreen, VirtualSMC. But it's not clear whether these always are the latest version, or if even if they are downloaded for the same release month as the chosen OC revision? I can see wanting these versions to be populated either way. While OC and Acidantera kexts work together, these are not quite a true bundle. Ask yourself: Is every release of OC/kexts a true step forward that carries forward all previously working cofig, or do OC/kexts have a support shelf life, just like every other kind of code? I would assume they have a shelf life. So there's a looming pitdall in the OCAT UI—a slippery slope of user config going out of date as OCAT update convenience pulls the user along to later releases.
+ The ~/.ocat folder, has naming for only one OC release (IOW you can only work with one OC release at a time in OCAT UI? So I wonder if you have to Get OpenCore <version> each time you want to work with a EFIs with different revs. Understanding the dependencies is not obvious. Forum mods will want to be able to look at many versions on the fly to help visitors.
The user will need to handle all this outside of OCAT, just like everything else regarding build mgmt.
To raise these concerns to a higher level: From the ground up, OCAT UI should make build boilerplate a separate mgmt chore from OC and keep its users directly imvolved with decision making in both areas. But to do so, you truly have to face a revision mgmt problem with complex interdependencies.
Again, OCAT is a plist editor with OC strings attached, not a hackintosh config manageer.
* * *
BIG ISSUES:
OCAT is at this time a slippery slope with major pitfalls.
The biggest pitfall is that it becomes irrelevant if it is not maintained at a more rapid pace than OC itself. Unfortunately, I doubt it is good enough at anything in particular to take the forums by storm, so what will motivate the progress?
Another pitfall is that it offers few aids to build correctness, while introducing copious new ways to reach epic build bogosity. While OCAT UI seems to promise a solid awareness of config.plist detail, in fact it has almost no awareness. It provides lots of leverage to haphazardly mix uncoordinated config. This is not good for anyone, esp new build makers.
Will OCAT be well enough maintained to justify mod adaption on the forums? Without maintenance, it will immediately become a boatanchor that drags the forums down to Davy Jones' locker.
(Yes I am mixing metaphors from Star Wars, Lawrence of Arabia, Bill & Ted's Excellent Adventure, and Pirates of the Caribbean).
Should a config.plist editor really integrate build mgmt? Yes! But it's really hard.
Build mgmt needs to be regarded as a completely separable concern from OC config editing. I think the creator of OCAT thinks this too, and has decided to prove it to himself.
Maybe ChatGPT of OC builds?!
I've blathered on almost too long.
Anyone promising to ease config mgmt is facing a very hard problem. I feel OCAT is worthwhile to review to warn the forums: Contrary to outward appearances, OCAT does not ease config mgmt.
For the tool to advance, the developer needs to step up to meet his user-base 1-on-1 offering clear support for use cases. (e.g., recipes).
So far what's happened is a 3rd-party forum mod is acting as a dev proxy with a simple Beginner's Guide and no commitment to even start understanding the problems at hand, much less design approaches to config mgmt. No amount of cheerleading and back scratching will overcome lack of design.
It seems within the range of dim possibility that OCAT might evolve to have merit for OC hack build developers, because it proves it can ease one chore: OC Update. OTOH anyone already doing solid OC dev work already has workflows for handling single-EFI OC updates.
OCAT might evolve to assist forum mods, if it is very carefully used according to recipies that are as yet undocumented.
"The desert is full of nothing, and no man needs nothing"
—Prince Fisel to T.E. Lawrence.
