Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
I thought I'd give OpenCore a try on my 4,1 flashed to 5,1. It seemed to work well, the only issue being not being able to get into my BootCamp parition. Until I install Windows on a separate drive, I decided to uninstall OpenCore using Martin Lo's instructions on his YouTube video. Now when I try to use BootChamp to boot into my BootCamp partition I get a Bless error. Any idea why this is happening?
I appreciate any help.
Thanks!
-Rich
I appreciate any help.
Thanks!
-Rich
Did you try the alternative method of using Startup Disk preferences panel, or holding option key at boot? Or is there something preventing you from using those methods (lack of boot screen?)
Hello,
I have installed Catalina and OpenCore (with an advanced configuration) according to the guide here. To update to Big Sur, can I just turn VMM on and update natively? Are there any extra steps? E.g. Do I need to update OpenCore (and reinstall the advanced configuration) before updating OS?
Piecing together answers from previous posts is convoluted. Perhaps the answer to this post could be added to the original guide to help others.
Thanks!
I have installed Catalina and OpenCore (with an advanced configuration) according to the guide here. To update to Big Sur, can I just turn VMM on and update natively? Are there any extra steps? E.g. Do I need to update OpenCore (and reinstall the advanced configuration) before updating OS?
Piecing together answers from previous posts is convoluted. Perhaps the answer to this post could be added to the original guide to help others.
Thanks!
I'm probably a poor candidate for this, but I couldn't resist. I've been following this thread since its inception over a year ago, but only managed to find time to install OpenCore this week. I'm no expert, so maybe some actual experts could enhance or correct any details I got wrong. I banged this out over lunch, so please forgive any typos, etc.
With that said, were you looking for something like this?
(The following explanation assumes the reader is a computer novice; if you have more expertise and simply want an overview of OpenCore, skip to the 5th paragraph, which starts with the word "OpenCore." NOTE: The wording of this introduction assumes you're running an Apple Mac, loading MacOS, but the concepts generally apply to compatible systems and other operating systems, such as Linux or Windows, although the details may differ.)
When a general-purpose computer like a Mac is powered on, it knows almost nothing about what it's capable of, or what's attached to it. The first thing it needs to do is take inventory - for example, see what sort of CPU it is and how fast it's running, figure out how much RAM is available and where it is, see how many disks there are, see if there's a keyboard and/or mouse attached, etc. Part of that process usually involves testing and initializing each of those items - for example, the system might send a message to the keyboard asking "are you there? and if so, what are you?", the keyboard might respond with some details about itself, then the system might send another message to the keyboard instructing it to set its repeat rate, turn on/off the LEDs, etc. For disks, the system needs to first figure out what sort of disk controllers are installed (e.g. SATA, SAS, SCSI, IDE, NVMe, etc.), then get those controllers to ask what disks are attached to them, how big they are, how quickly they can communicate, etc. After all of the devices on the system are accounted for and initialized, the computer can locate and load the operating system (such as MacOS or Windows) and actually get something done. The process of testing, taking inventory, initializing the devices, loading an operating system, and passing control to it is referred to as "bootstrap loading," or just "booting" the computer. (It's also sometimes referred to as Power-On Self-Test, or POST, although that term really just applies to the first phase of booting.)
Early personal computers used a Basic Input/Output System, or BIOS, for the boot process. Most of the BIOS was embedded in a ROM or EPROM on the computer's motherboard, and was tightly tied to that particular hardware - if the hardware changed more than a trivial amount, the BIOS wouldn't work properly. Some add-on cards had BIOS ROMs of their own, and the motherboard's BIOS would transfer control to the cards to initialize themselves (which sometimes went very badly, since the card had no knowledge of the system it was plugged into, and programmers sometimes make bad assumptions). There were several problems and shortcomings to the BIOS approach. Because the BIOS methodology dates back to the 1980s, it runs in 16-bit mode, which severely restricts how much memory it can access, and it can only understand disks using Master Boot Record (MBR) partitioning, which limits the size of the disk to about 2TB. And, as previously mentioned, the BIOS only understands the hardware for which it was designed, so it could fail to properly initialize a newly-installed device, or fail to boot at all. All of these various issues could be (and often were) worked-around, but that made the BIOS code even more complex, error-prone, and difficult to deal with.
Intel's solution to this problem was the Extensible Firmware Interface, or EFI. It's like a tiny operating system of its own, with well-defined protocols for devices to talk to one another, and the ability to run specialized programs for more complex setups. EFI can handle extremely large disks, and is flexible enough to handle the testing and initialization of almost any hardware. When EFI began to be more widely adopted, Intel ended development of EFI; control of the standards and specifications passed from Intel to a new group, the UEFI Forum, and Unified Extensible Firmware Interface (UEFI) was born. UEFI is largely a superset of EFI. A computer using EFI or UEFI only needs to know how to load EFI itself; after that, EFI handles the whole boot process. (From here on, I'll use the term "EFI" to mean either EFI or UEFI, and use "UEFI" only when discussing something specific to UEFI.)
Intel-based Macs use an Apple-specific version of EFI, with capabilities somewhere between EFI and UEFI. For compatible graphics cards, Apple's EFI includes a graphical boot-picker, which allows you to choose which disk you'd like to boot from. However, if you use a non-Apple graphics card, this boot-picker is invisible to you, as are the progress bars and other messages that display while MacOS is loading. Apple's EFI is embedded in the Boot ROM in the Mac. The Boot ROM can be upgraded; for the Mac Pro 5,1, at least 12 versions of the Boot ROM have been released by Apple, adding support for things like the APFS filesystem, NVMe drives, and Intel CPU microcode updates.
OpenCore is a set of EFI programs designed to run on Macs (or compatible) computers. OpenCore runs on the EFI platform, it doesn't replace it. OpenCore is still evolving, and it has many facets, but broadly speaking, it's useful for three things: (1) it will display a boot-picker and progress screens on non-Apple graphics cards, (2) it allows you to fine-tune the initialization of the hardware, even to the point of "spoofing" (making one piece of hardware appear to be a different piece of hardware, or to disappear altogether), and (3) it allows you to "inject" code into MacOS to accomplish things that would otherwise be impossible, or prohibited by MacOS itself.
During the initial boot, when the EFI is initializing the hardware, the OpenCore boot-picker can run (if it's enabled). This is just an EFI program the looks for bootable partitions, then presents them, either graphically or as a list; once you choose one, it passes control to the boot loader and exits. The boot-picker runs and exits entirely before MacOS loads. It uses EFI drivers that can communicate with both old-style EFI Universal Graphics Adapter (UGA) graphics cards, or new-style Graphics Output Protocol (GOP) graphics cards. (The Apple EFI only includes support for the older UGA cards, and even then some cards won't work properly without an add-on like OpenCore.)
The goal of EFI/UEFI is to discover and initialize the hardware, then locate and load an operating system. Having discovered the hardware, EFI creates a "device tree," which is a description of all the hardware it found. Think of it as a dictionary, with an entry for every device that the computer could identify; each of these entries contains a list of all the details about the device. For example, a graphics card entry might contain the addresses of its I/O ports, the addresses of its on-board video memory, information about what interrupts it uses, who the manufacturer is, an identifier of what type of device it is, and many other details. However, the computer doesn't communicate directly with the graphics card - the card is attached to the computer via what's called a "bus" (which is just a common set of connections between things - if you picture a long hallway with rooms branching off of it to the left and right, the hallway could represent a "bus," being the path that allows you to move from room to room). In the case of a Mac, this is a Peripheral Component Interconnect Express (PCIe) bus, which ties most of the system together. Your computer's CPU, graphics card, disk controllers, USB controllers, network adapters, and other devices all communicate over the PCIe bus. The PCIe bus itself has entries in the device tree, as does the CPU itself. This is what gives us the "tree" structure. An oversimplified example might look something like this:
Code:
|-Core0
|-CPU-|-Core1
| |-Core2
| |-Core3
|
| |-Port0-Mouse
| |-USB-|-Port1-Keyboard
| | |-Port2-Flash Drive
| |
| | |-Monitor0
Computer-|-PCIe-|-GPU-|-Monitor1
| |
| | |-Disk0
| |-SATA-|-Disk1
| | |-Disk2
| |
| |-(...other PCIe devices...)
|
|-RTclock
|-(...other system devices...)Once EFI has created this tree, with all the details for all the hardware (and there are a lot of details; the example above is grossly oversimplified), it loads whatever operating system it has found (or you have selected) and passes this tree to the operating system (let's assume MacOS from here on). When MacOS loads, it's in the same boat that EFI was when it first loaded - it knows almost nothing about its environment. Rather than repeat the process of discovering and initializing the hardware, though, MacOS uses the device tree that EFI passed to it, and "hits the ground running" - all the hardware is already set up and ready to go, and MacOS now has a list of all that hardware and the details of how it's configured and how to access it.
Since MacOS relies on the EFI device tree to understand the hardware, a program like OpenCore has the opportunity to "spoof" the hardware - effectively, to misinform MacOS about what's installed. For example, if you're installing MacOS on a laptop that has an unsupported GPU, and MacOS crashes when it tries to initialize or use that GPU, you can have OpenCore simply tell MacOS that the GPU isn't there (i.e. delete it from the device tree that OpenCore passes to MacOS). Changes to the EFI device tree that gets passed to the operating system occur while EFI is still running, but they (and their effects) persist after EFI (and OpenCore) exit. So, in the trivial example above, OpenCore takes the EFI device tree, removes the offending GPU entry, loads MacOS, passes MacOS the modified device tree, then exits. OpenCore is no longer running, but MacOS proceeds under the belief that the problematic GPU doesn't exist, so it doesn't try to use it.
Some parts of OpenCore can continue to operate after MacOS has taken control. For example, OpenCore can intercept calls from MacOS to get or set variables in the Non-Volatile RAM (NVRAM), and present whatever values it wants, or prevent changes from being made. OpenCore can also "inject" kernel extensions (kexts) or other code patches - since OpenCore has control of the system before MacOS does, it can load MacOS into memory, then make modifications to that memory before passing control to MacOS. An example of this would be CPU spoofing - MacOS has some code that sets up the CPU, effectively asking the CPU "what are you, and what are your capabilities?" and creating a table of those details; once that's done, MacOS never needs to directly ask the CPU again, it just looks in the table to find out what it needs to know. OpenCore can modify that code before MacOS starts, so instead of asking the actual CPU "what are you, and what are your capabilities?", it skips that part and just uses the tables - which OpenCore has conveniently filled out with whatever details it wants. This is how the VMM flag (which tells MacOS that it's running in a virtual machine, even if it's not) can be set or reset by OpenCore. This mechanism can also be used to allow unsupported CPUs to be used by telling MacOS that it's a supported CPU, or to allow features that are missing from a CPU (such as SSE 4.2 on Penryn-class CPUs) to be implemented externally, yet have MacOS believe that the feature is available on the CPU itself.
OpenCore can also "inject" kernel extensions that might be needed for a successful boot on unusual hardware, or that would be difficult or impossible to load otherwise. By loading MacOS into memory, then loading the kext into memory and performing a kernel link in place, MacOS will boot the modified kernel without ever knowing it was modified. OpenCore itself is no longer running at this point, but the kext that OpenCore injected is.
For more details about how OpenCore operates, or how to configure OpenCore, see the OpenCore documentation.
Thoughts? Anyone with any inclination is welcome to take the above and modify it, include it in the first post, or use it as you will. (Or just roll your eyes because I've totally missed the mark, which is a real possibility here...)
Hey everyone
I currently have Big Sur running on my 5,1 dual bay. Currently following the steps to get windows 10 on a separate "Samsung 860 evo 500gb", but I'm a bit confused on this step. I don't know what it means by "open config.plist in your home folder" where is that file located? Do I have to mount my drive that has "Big Sur" installed?
Open the configuration file
I currently have Big Sur running on my 5,1 dual bay. Currently following the steps to get windows 10 on a separate "Samsung 860 evo 500gb", but I'm a bit confused on this step. I don't know what it means by "open config.plist in your home folder" where is that file located? Do I have to mount my drive that has "Big Sur" installed?
Open the configuration file
- Navigate to /Volumes/EFI/EFI/OC and copy config.plist to your home folder
- Open config.plist in your home folder with TextEdit
Last edited:
@Syncretic ... Great effort but there is a reason why such a section is not in the first post and why it should not be.
The simple reason is that despite the requester thinking the matter can be dealt with in one or two paragraphs, it simply cannot without sowing confusion. You have bascially had to write an epistle (I have not read it and believe very few will ever read such - another reason why it ends up being a waste of time) but I am sure there are unavoidable gaps in it.
In my time dabbling in open source stuff, there is always someone that comes up with such a request and always saying how they think it is a simple thing to do and something that can be done in a few words. These requests are understandable but the only answer to give them is to get familiar with the subject and come back to write the item in one or two paragraphs themselves.
The instructions deal with implementing the tool. Anyone that wants details of the inner workings needs to go out and learn them. If they have the chops to distill this into a couple of paragraphs afterwards, then great. Invariably never happens though ... because the matter invariably can't be so distilled.
All said though, looks like a wonderful effort. Maybe Post 1 can link to it instead of embed it. I will link to it from the MyBootMgr post actually.
The simple reason is that despite the requester thinking the matter can be dealt with in one or two paragraphs, it simply cannot without sowing confusion. You have bascially had to write an epistle (I have not read it and believe very few will ever read such - another reason why it ends up being a waste of time) but I am sure there are unavoidable gaps in it.
In my time dabbling in open source stuff, there is always someone that comes up with such a request and always saying how they think it is a simple thing to do and something that can be done in a few words. These requests are understandable but the only answer to give them is to get familiar with the subject and come back to write the item in one or two paragraphs themselves.
The instructions deal with implementing the tool. Anyone that wants details of the inner workings needs to go out and learn them. If they have the chops to distill this into a couple of paragraphs afterwards, then great. Invariably never happens though ... because the matter invariably can't be so distilled.
All said though, looks like a wonderful effort. Maybe Post 1 can link to it instead of embed it. I will link to it from the MyBootMgr post actually.
Last edited:
I definitely think it should go to the first post. Thanks.
I have no great ambition to get this added to the first post, I was just trying to address the request - which I think is a valid one. I had the same questions - "What exactly is OpenCore? Why do I want it? In simple terms, how does it do what it does?" I agree that if one wants actual details, the real documentation (and, ultimately, the source code) are the only way to learn. But if one is approaching this without a programming background, or with little or no foreknowledge of what OpenCore is, a "30,000 foot view" is helpful to know if it's worth pursuing it further.
Yes, what I wrote is probably overly long, but I felt that some background was needed for the non-programmers who don't have any notion of what EFI is or what the computer is doing between the chime and the login prompt. Someone may want to make it more concise, if anyone cares that much. Based on some of the questions and requests I've seen in this thread and elsewhere, a bit of simplified explanation would be helpful, since some folks seem to have a substantial misunderstanding of what OpenCore is, what it can (and can't) do for them, and why they do (or don't) want to try using it.
It's not a "for dummies" tool, and there is no "for dummies" guide. I just wanted to provide a simple introduction. Perhaps I failed, which comes with the territory.
The background which is always needed is why it invariably HAS to be longish which can then be a distraction in the main post.
You did a great job in summarising the subject (I had a quick skim after all) and as said, I will be linking to it.
I want to applaud your effort. Thanks for investing the time.
For the purpose of what I was asking for, it's a bit verbose and camp fire-y as far as stories go. Let me re-post it from my perspective and we'll see where we end up.
Martin Lo suggested I check the SIP and sure enough it was re-enabled. I disabled it and it's working again!
Thanks!
-Rich
In fact, a computer might need to start with no OS at all, such as when installing a new hard drive, which is why they come with a "mini OS" built into a chip—a Boot ROM—that sits on the montherboard. This Boot ROM or firmware contains the necessary instruction set to identify the computer it is on and what components are connected to it.
With no other input, this software allows the computer to start up and it hands the computer over to the main OS which loads into memory and presents the graphical user interface.
Here, a connection should be made how we make the jump from Apple controlled Boot ROM EFI to the files on the EFI partition where we copy the Open Core files.
Common modifications to NVRAM are: XXX for the reason of YYY...
Common .kext modifications are: XXX to support YYY...
Control over modifications to the Open Core configurations is done via a config.plist file that can be found in the OC folder. This file can be opened in Xcode (recommended) or a normal text editor where adjustment to NVRAM, spoofing of hardware or loading of external .kext files can be easily made.
Pre-configured Open Core packages are available for Catalina at: XXX (including instructions and user friendly install videos), or a slimmed down version for Big Sur (that needs fewer files to work in some situations) at: YYY (including instructions and user friendly install videos).
----------------
The above is meant to be read as a single text and not quotes with "objections" or "comments" about them.
To enable Night Shift on Macs that do not support it, it was once done as indicated here https://pikeralpha.wordpress.com/2017/01/30/4398/. I assume, NightShiftEnabler.kext works on the same principle so, it needs to be updated to activate Night Shift with Big Sur and Lilu / OpenCore don't hit for that problem: In your opinion and for those who are better than me, could a system like the one indicated in https://pikeralpha.wordpress.com/2017/01/30/4398/ also be made manually for Big Sur?
A short version for the Mac Pro forum:
Abstract: Open Core for legacy Mac Pros comes in pre configured packages (links and instructions below) for Catalina and Big Sur. Open Core bridges unsupported hardware with Apple's latest MacOS and offers support like hardware accelerated encoding/decoding of HEVC on supported GPUs.
To install, copy two folders and included files to an EFI partition that you mount according to instructions. When the computer reboots, Apple's preinstalled Boot ROM EFI will have been instructed to read the new Open Core files, which in turn will configure and present a boot picker so that the user can choose which MacOS to boot. During boot, Open Core loads the necessary files and hands the computer over to MacOS and exits the process. Once booted, the user is running a normal MacOS, in some cases with a few additional .kext files to solve specific hardware problems that is totally transparent to the user.
After a one time installation of Open Core, the user can upgrade MacOS as per normal via Software Update.
Detailed instructions below. Read carefully.
Abstract: Open Core for legacy Mac Pros comes in pre configured packages (links and instructions below) for Catalina and Big Sur. Open Core bridges unsupported hardware with Apple's latest MacOS and offers support like hardware accelerated encoding/decoding of HEVC on supported GPUs.
To install, copy two folders and included files to an EFI partition that you mount according to instructions. When the computer reboots, Apple's preinstalled Boot ROM EFI will have been instructed to read the new Open Core files, which in turn will configure and present a boot picker so that the user can choose which MacOS to boot. During boot, Open Core loads the necessary files and hands the computer over to MacOS and exits the process. Once booted, the user is running a normal MacOS, in some cases with a few additional .kext files to solve specific hardware problems that is totally transparent to the user.
After a one time installation of Open Core, the user can upgrade MacOS as per normal via Software Update.
Detailed instructions below. Read carefully.
User space patching is broken in Big Sur , so are Lilu and the plugin kexts performing user space patching, if/when such an obstruction is overcome the kexts will operate as designed.
Only the first part of the guide, I don't need more according to my hardware.
Does anyone know if there is any way to configure OC to only accept one specific volume in its scanning policy? It seems that it always scans all volumes (the scan policy can limit which TYPES of volumes to include, but there doesn't appear to be a way to explicitly specify volumes as included or excluded, that I can find. Is that true?
As I'm understanding now, the only way to know which volume will be booted will be the NVRAM values saved when using System Preferences Startup Disk.
But I'd really like to be able to constrain a particular OC configuration to only work with one well known volume using it as the one and only default...or behave like it can't find any boot volume if that particular one can't be found.
Is there a way?
As I'm understanding now, the only way to know which volume will be booted will be the NVRAM values saved when using System Preferences Startup Disk.
But I'd really like to be able to constrain a particular OC configuration to only work with one well known volume using it as the one and only default...or behave like it can't find any boot volume if that particular one can't be found.
Is there a way?
Not sure this is the right place to ask this but I have a problem in Big Sur on 5,1/0.63 that has happened 3 times now, no real trigger I can figure out. Basically USB input died. No mouse (logitech with dongle plugged into wired apple keyboard, in turn into back panel usb port) thought at first it was mouse battery - but then no keyboard response either and its wired.
Tried to wait it out for about 40 minutes, no go, mac went to sleep, woke up on power key press. Mac seems fine. Plugged in a second keyboard and mouse into front panel usb, nothing.
Eventually force shutdown and restarted. It booted itself back into Mojave. USB now working again no problem. Went to startup options, no Big Sur! Just Catalina, my CCC backup of Catalina (which shares an APFS drive with my Big Sur backup and which wasn't showing either) and of course Mojave.
Diskutiliy listed no sign of Big Sur volumes on the APFS it is on (NVMe on PCI) - just a dimmed out name like in terminal - disk3S6 or something (Can't remember what but it would not mount) and another volume which was actually mounted (but not a startup/system disk).
Restarted to Catalina, no problem again, but now still no Big Sur. Tried restarting again with ESC to get bootpicker but nothing, Mac booted into Catalina again. Tried restarting with OPT key, again, no boot picker (I have it set not to appear in config but thought ESC key overrode that and called it up?) and into Catalina again.
Did a full shutdown and left the mac for half an hour or so and came back. Tried the ESC again with no luck but now when it booted back into Catalina, I had a Big Sur volume on the desktop. In Diskutility the same disk3s6 dim drive was still there, but now another volume called Untitled was there too and mounted. I ran First Aid and success reported.
But now - In startup items I had the disc called "Untitled" as an option - I tried that and voila - I'm back in Big Sur!
All well for a couple days then again. Same thing. No mouse/keyboard, nor any spare ones working either.
Went through pretty much the exact same thing as above when I hard restarted. No Big Sur, and eventually it came back as 'Untitled'.
3rd Time happened today. Now this time I had done some googling but found nothing except some stuff about someone having a similar problem and they plugged the keyboard and mouse into a third party USB card and it worked. Since I have two of those I got down to try that. Before I plugged into the card I plugged the original keyboard USB into the port next to it (back panel) and boom! Mouse and keyboard working!
Any explanation for this? 3 times is definitely a trend and not a glitch.
Also - if I have turned off the Bootpicker display can I not get it back without altering the config? I am using the HW Accel config with 2 changes - UIscale for 4K and switch off the bootpicker.
Sorry so long! Thx
Tried to wait it out for about 40 minutes, no go, mac went to sleep, woke up on power key press. Mac seems fine. Plugged in a second keyboard and mouse into front panel usb, nothing.
Eventually force shutdown and restarted. It booted itself back into Mojave. USB now working again no problem. Went to startup options, no Big Sur! Just Catalina, my CCC backup of Catalina (which shares an APFS drive with my Big Sur backup and which wasn't showing either) and of course Mojave.
Diskutiliy listed no sign of Big Sur volumes on the APFS it is on (NVMe on PCI) - just a dimmed out name like in terminal - disk3S6 or something (Can't remember what but it would not mount) and another volume which was actually mounted (but not a startup/system disk).
Restarted to Catalina, no problem again, but now still no Big Sur. Tried restarting again with ESC to get bootpicker but nothing, Mac booted into Catalina again. Tried restarting with OPT key, again, no boot picker (I have it set not to appear in config but thought ESC key overrode that and called it up?) and into Catalina again.
Did a full shutdown and left the mac for half an hour or so and came back. Tried the ESC again with no luck but now when it booted back into Catalina, I had a Big Sur volume on the desktop. In Diskutility the same disk3s6 dim drive was still there, but now another volume called Untitled was there too and mounted. I ran First Aid and success reported.
But now - In startup items I had the disc called "Untitled" as an option - I tried that and voila - I'm back in Big Sur!
All well for a couple days then again. Same thing. No mouse/keyboard, nor any spare ones working either.
Went through pretty much the exact same thing as above when I hard restarted. No Big Sur, and eventually it came back as 'Untitled'.
3rd Time happened today. Now this time I had done some googling but found nothing except some stuff about someone having a similar problem and they plugged the keyboard and mouse into a third party USB card and it worked. Since I have two of those I got down to try that. Before I plugged into the card I plugged the original keyboard USB into the port next to it (back panel) and boom! Mouse and keyboard working!
Any explanation for this? 3 times is definitely a trend and not a glitch.
Also - if I have turned off the Bootpicker display can I not get it back without altering the config? I am using the HW Accel config with 2 changes - UIscale for 4K and switch off the bootpicker.
Sorry so long! Thx
Last edited:
That is not true and IMO using a preconfigured EFI package should be avoided by end-user. Yes, you can fix this easy by deleting the EFI partition. For example, my OC setup and many other's is different than what you find publicly available. You will probably say that most people will just copy an EFI folder and be done with it. I'm going to answer this, what will happen if these people who built the EFI package disappear and they don't update it anymore? Note how many people ask questions into this thread, having no clue what is wrong with their setup. Why do you think this is happening?
I'm personally a supporter of Acidanthera philosophy which suggests that in order to get the most out of OpenCore, it is important to read the manual and understand its settings. All my related OC tools adhere to that philosophy and @cdf shares the same beliefs.
It was more of a forward looking statement.
I'm totally fine with you having a differing opinion. And as you mention further down, I'm sure you're not alone thinking like that. There is obviously nothing wrong with taking the long road and digging deep.
It's pretty typical that, given enough people involved, you'll end up with various groupings that share a mindset. I think the key is to not projects one's own feelings and needs onto others.
The wheel has been reinvented a 1000 times in this thread because the documentation isn't exhaustive && || clear enough.
I fell into the trap myself of not realising that I was actually already done, following @h9826790 quick install. So I had a detour of jumping through hoops of "enabling hwaccel" that was already done. And it was this unnecessary work and reading a bit conflicting/outdated information that prompted me to suggest the "abstract" section to provide context for anyone that just wants to get up and running. Not for myself, because it was already behind me.
To be honest, I think the best solution for most people would be if @h9826790 had another thread that only focused on his patches. And he could maybe have one patch for Catalina and one for Big Sur. If he would then just provide a little context on what his mods are doing and proactively point out the main switches one might want to change—that would work for a lot of users.
It's a bit messy now with lots of jumping around to posts buried among a thousand other posts.
That sounds reasonable. No objections to that.
But it's my guess that a lot of people just want a skeleton install to be able to move forward with a more current MacOS and a few goodies. @h9826790 patches have been very popular for a reason. It's a no fuss 15 min project (not counting the time to download the installer and so on).