Contribute
Register

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

@van7one No, but it runs OC Validate each time you save and merges new keys from the latest sample.plist into the config automatically and point's you towards errors. So the best practice would be to generate a snapshot ProperTree once after building an EFI and then you're good.
 
Hello there,

If I enable launcher option in OC's plist to launch OC directly from BIOS without the need of BOOTx64.efi can I still update OC using OCAT or do I need to disable launcher and add BOOTx64.efi back before doing so?

Thanks!
 
No name yet :)
Z87 MPOWER |  i7 4770K |  GeForce GTX 760
You can still update OC using OCAT. There is no need to disable launcher option in your config.plist.
 
I am hoping the monthly OpenCore updates stop soon, as it needs to find a balance and possibly move to quarterly updates. Unless something urgent needs to be addressed.
 
Working Broadcom WiFi in Sonoma is a Kext issue, not a boot loader issue. An update to AirportBrcmFixup.kext is required for the previously native Broadcom WiFi to work in Sonoma.

I keep expecting the OpenCore developers to push out version 1.0.0 or 1.0.1. I have done for about a year, but I’m still waiting. The last few OC updates have been mild in comparison to some of the previous releases. With little changing in respect of Hackintosh systems. These updates have been more about Hacking a real Mac to run a newer version of macOS. Hardly surprising really as they are also developing OCLP.
 
Well lucky for me I did not have to wait that long to test LauncherOption; OC 0.9.4 is out.
After a successful reboot, I went into BIOS, picked the newly created OPENCORE boot option, disabled the others (MacOS and Windows), went back to MacOS and deleted BOOTx64.efi as it is no longer needed.

Updated as usual using OCAT but unticked BOOTx64.efi as it's not needed anymore. After rebooting the pc went straight into Windows, I had to go into BIOS and pick the OPENCORE boot option again as it somehow reverted to Windows.

Is this normal when using launcher option, did I miss something in the config? Here is what I did according to OC guide:

Enable LauncherOption
  • config.plist settings:
    • Misc -> Boot -> LauncherOption = Full
      • Use Short for Insyde based firmwares, commonly found on laptops
    • UEFI -> Quirks -> RequestBootVarRouting = True
Thanks!
 
No name yet :)
Z87 MPOWER |  i7 4770K |  GeForce GTX 760
No, that is correct according to the guide. Although I have never bothered deleting the BOOTx64.EFI when I use the LauncherOption to provide a BIOS entry for OpenCore.

You also need to remember to use the ResetNvramEntry before booting in to macOS after making these changes to your config.plist, so the old NVRAM entries are not used.
 
Hadn't looked at this thread for a while but got a reaction bump so checking back to see how things played out...

OCAT might hav value to new hacintoshers helping them gain a sense of the lay of the land of config structure, but no one seems to be treating it as such, maybe because typical OC users just want to get their specific kit to work, not become build experts.

The Sonoma release got me looking at OCLP again simply because the OCLP post-install for Broadcom quickly became the goto solution to wifi compatibility.

I was grateful to find that Dosdude1's great work years ago on macOS-on- Unspported patchers has taken on a new life under Dortania with OCLP.

I used OCLP to put Ventura on an old Macbook 9,1, and the experience went great: starting with excellent documentation at the right level of abstraction, it makes the process of building and installing easy and effective.

The OCLP approach has coalesced into a patcher app that does exactly what most users need:
- Gather and assemble a bootable macOS installer for a given build.
- Slipstream key support into the installation process (a traditional Windows admin approach).
- Patch the installation via a post-install step to deal with contingencies.
- Run an updater in the background to track improvements to patches.

This is an example of "recipes" that I was trying to explain in previous posts reviewing OCAT: OCLP exposes configuration options appropriate to the build task at hand while hiding as much underlying configuration detail as possible.

The olde dayz of the Beasts were a valiant stab at this, but various factors worked against it in the long run:
- Pre-Github. While I lament the business-model of Github, the site is super smart and it's taken the world by storm. And not only that but Dortania is an excellent use of Github.
- Uni/multi nomenclature never made sense to the uninitiated, and maybe never made sense to anyone.
- Hid too much detail.
- Config evolution got too complex for tool owners to keep up.
- Clover was not the future.

Well, nothing went wrong, it's just that history is always messy. But as progress grinds on, talented hard-working people continue to make progress. In case of OCLP, it so happened that just keeping actual macs working has substantial overlap with hackintosh. And the focused objective of unsupported Macs has helpfully guided the course of development.

Now, could OCLP be taken to the verge of hack config?

Imagine if OCLP was template driven: it might accept a characterization of a golden build and emit bootable drive for its parts list, reusing the essentially useful design of the OCLP patcher?

Then instead of lore being passed around on threads with Q/As being endlessly repeated in the forums and mods obsessing with categories for discussion (although paradoxically it's better here than at macrumors "unsupported" where all discussion is dumped into a single thread and everything is forgotten with each macOS release), the lore would get baked into the tool and the templates. This will free up forum energy to expand the catalog of golden builds and review experiences.

This is just rambling at the moment.
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top