Although booting normally to the desktop now, I need to patch the system volume to get sound but no matter which way I set 5. Patcher Settings for SIP and Secure Boot (both disabled, or both enabled, or one or other enabled and other disabled,) I always get a message telling me that post install volume patch won't run because SIP and Secure boot are not set correctly.
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.
macOS 11 Big Sur on Unsupported Macs Thread
- Thread starter dosdude1
- WikiPost WikiPost
- Start date
-
- Tags
- 10.16 macos unsupported
- Sort by reaction score
- Status
Patcher Settings are for OpenCore building, you cannot magically have OpenCore update itself while running macOS ;p
You need to adjust the settings, rebuild your OpenCore build, install it to the desired drive and reboot. Then, OpenCore will overwrite the SIP and SecureBootModel variables correctly allowing you to run post-install patches
As a side note, I highly recommend not patching for AppleHDA support. You loose delta updates so every update will be ~12GB as well as no FileVault and SIP needs to be disabled. Best option is to simply buy a cheap USB Audio Adapter to have a native experience
Generally any generic USB Audio interface will work nicely, I own a "Sabrent USB External Stereo Sound Adapter" I bought years ago and it's nice for those times I need a small adapter quickly.
There's a large variety to choose from, I'd just take a peak at amazon and find one you like
I see that FireWire is working and I have an old M-Audio Firewire Audiophile I/F that the OS is seeing so I might try that too first.
This is nice and all, but I recently happened to do something for my next patcher version, v0.2.0.
No more need for the micropatcher, it's all on my own repo now, and all the stuff Patched Sur will use is managed by me. To be fair, I still use the same kext patches and a couple of things are still the same or are somewhat modified, but it's no longer the micropatcher, which technically makes Patched Sur its own thing.
It's all already tested by me (soon to be others) too, I used it to do a fresh install on a separate volume and it worked! (Also, yes I did have WiFi during setup because of a GUI, previously when you did clean installs you would have to manually run patch kexts in terminal if you wanted WiFi during setup.)
I'm not sure what else to say about it, but there it is. Patched Sur v0.2.0 will no longer use the micropatcher. (ETA for release is non-existant)
Other thing in v0.2.0: I'm trying to make it more user-friendly (the UI is going to be a lot better than the ugly mess it was before, I'm also trying to get rid of the weird limitations (not the Catalina only for now)), more documented, and hopefully easier to contribute to.
Hi, I'm writing about the audio (AppleHDA) OCLP just for experiments, the quality is very good for my MacBook7,1 (0.0.20 Main) and MacPro3,1 (Fix Mac Pro output issues CI # 266) We are waiting for AppleALC in OCLP
Thanks to khronokernel👍😊
Thanks to khronokernel👍😊
Did you by any chance create a short log of your changes or went everything according to the docs at the very end?
From my perspective I cannot see if it was a user error (happens) or a bug in the patcher (happens, too). The latter case I would like to fix...
It is basically the same Apple High Sierra extension the micropatcher uses. So the quality has to be the same. Nevertheless I would recommend to do no audio patching (if it is the only patch you need) because it breaks the delta updates.Hi, I'm writing about the audio (AppleHDA) OCLP just for experiments, the quality is very good for my MacBook7,1 (0.0.20 Main) and MacPro3,1 (Fix Mac Pro output issues CI # 266) We are waiting for AppleALC in OCLP
Thanks to khronokernel👍😊
This may not hurt during the first year of support but it becomes a major problem after the first year when Apple normally stops to deliver full installers with updates. Then you would have to play the ping (installing back the last full installer) and pong (applying the latest delta updates) and finally patch again the sound in to break updating, again.
With the upcoming legacy video support there will be no other way, of course.
I got Big Sur 11.2.3 to install with a different OpenCore 0.6.7 "easy install package" from here. I figured if it can natively boot the Catalina/Big Sur recovery volumes... it should be fine installing Big Sur from software update in Catalina. This is no longer my primary computer so I didn't have anything to lose. After creating a bootable USB installer the whole process took about 1.5 hours. I think it rebooted 6 times but the chime wasn't audible. There were points where there seemed to be no activity but the lights were flickering on my 2.5" SSD PCIe card. Mojave and Big Sur are 2 different volumes in the same APFS container. Catalina - Data still shows up in Disk Utility but not in /Volumes. From Disk Utility it links to /system/volumes/data but "data" is shown as Big Sur in the finder window.
The osxwifi.com upgrade was detected in the installer and ethernet works (Catalina had unstable ethernet/wifi connection). Computer is still shown as Mac Pro mid 2010 and serial numbers don't seem to have changed (system firmware looks to be spoofed as 9144.0.6.7.0 as shown in OC config). Not sure why but the computer boots faster than Mojave. Also, for some unknown reason Catalina was completely unable to reboot/shutdown but Big Sur does it almost immediately.
Not a fan of the new interface changes but it seems to run just fine so far. I do have 1 issue that I'll never get over... i've been using Sosumi since OS 7.5 and the "new" Sonumi just sounds wrong and I'll have to change that later. If Apple has a problem with that they can sue me.
The osxwifi.com upgrade was detected in the installer and ethernet works (Catalina had unstable ethernet/wifi connection). Computer is still shown as Mac Pro mid 2010 and serial numbers don't seem to have changed (system firmware looks to be spoofed as 9144.0.6.7.0 as shown in OC config). Not sure why but the computer boots faster than Mojave. Also, for some unknown reason Catalina was completely unable to reboot/shutdown but Big Sur does it almost immediately.
Not a fan of the new interface changes but it seems to run just fine so far. I do have 1 issue that I'll never get over... i've been using Sosumi since OS 7.5 and the "new" Sonumi just sounds wrong and I'll have to change that later. If Apple has a problem with that they can sue me.
Many thanks @BenSova.
Will
install-setvars.sh -e still be enabled? For those that don't know: option -e of BarryKN's micropatcher v0.5.1 installs the setvars version which enables setting SIP and ARV security; useful if you are installing Big Sur on a 2012 or 2013 Mac (mine is a rMBP mid-2012; 10,1) that has been upgraded with an 802.11ac WiFi card and therefore does not need a WiFi patch.
Hello!
IMHO you should finally give OCLP a try. It will do exactly this (leaves SIP enabled) and offers OTA upgrades for your (unofficially fully supported) system.
Since OCLP injects kernel extensions (instead of patches and modifies the system volume) all 2012/2013 may be able to run Big Sur in the same way as fully supported systems. It was a complete nonsense from the start to patch those new systems. So even MacBookPro10,1 with the stock BT/WiFi card can be used unpatched.
Long story short:
If you get Big Sur installed without (or with just a few) patches installed on disk your are better suited with OpenCore.
(just updated to 11.2.3 via Apple Software Update on my iMac Mid 2010 running an OCLP 0.0.18 adoption)
Last edited:
Last update .... Macpro 3.1 bigsur 11.3 beta6 .... I tried audio enabling and it works (only for tests) now I just hope to be able to enable the second monitor which is dead at the moment then for the rest OCLP works great ....
I tried OCLP a few months ago and the first OTA I did bricked my 2012 Air and I had to disconnect the battery to get going again. Has this been resolved yet? One thing nice about the Micropatchers is not worrying about taking it apart to fix a update.
That was resolved with v0.0.9 back in January
Thanks for your point by point instructions in post #7,069 and also many thanks for the considerable amount of work done by @jackluke!
Unfortunately I can’t get my MacBookPro4,1 (early 2008) to boot into Big Sur after installing, with the various patches.
The machine’s firmware is APFS ROM flashed (what works nicely with filesystems of Catalina 10.15.7, etc.) and SIP is disabled.
Creating the bootable installer drive with the BigSurBaseSystemFix method worked all fine.
Before running the main Big Sur installer, I did run "Hax3 installer fix". Installing took again 30 more mins after showing: "less than one minute to go ...". After auto-rebooting into the installed Big Sur system it kernel panicked.
After that I booted into the USB installer flash drive again, and selected "Stage 2 installer fix" and "Legacy USB patches". But it was of no help, still got kernel panics when trying to boot into Big Sur.
In one description I’ve read "Stage 2 installer fix" only is needed when intalling on non-APFS Macs and exernal USB drives. Is that right? I do install on an internal SSD (which already has a few other system partitions on it, but Big Sur APFS volume resides in its own container).
Along the way I must have missed something?!
Maybe I do try again the older jackluke method with the two patch commands: "BigSur BaseSystem legacy usb fix" and "BigSur BaseSystem legacy usb fix2". But IIRC created USB flash drive installer with that method only booted my MacBookPro4,1 with Big Sur releases that came before 11.1 or so.
Last edited:
Maybe I can try that NMVE efi driver if you attach it here. You can attach the entire bios if you don't have it separately.
HighPoint released (at December 2020) a dmg package of drivers and a WebGUI package for controlling fan speeds on the 7000 series of cards. The latter requires the driver package to be installed. When I tried yesterday on the Mac listed in the signature, one of two things happened 1. Either the system KPs at the package validation phase, or 2. The install completes but the Mac could not be booted afterwards. The driver package installs a kext in /Library/Extensions/HighPoinyNVMe.kext which had to be removed and the kext cache had to be rebuilt (sudo kextcache -i /) to restore booting.
Is there any reason related to OCLP why this is happening or is it just a bad package from HighPoint?
The company does claim it is for Big Sur 11.0. I don't really care about the driver package because the Mac with NVMe boots from the card fine without it but the drivers are necessary for card fan control which would be nice because it is a noisy little critter. I attach a zip of the dmg.
Is there any reason related to OCLP why this is happening or is it just a bad package from HighPoint?
The company does claim it is for Big Sur 11.0. I don't really care about the driver package because the Mac with NVMe boots from the card fine without it but the drivers are necessary for card fan control which would be nice because it is a noisy little critter. I attach a zip of the dmg.
This card does not require drivers to boot Mac—see more details in previous post #9500.
Just to put my heart in peace, does anyone have any idea why after installing 11.3.6 on macpro 3.1 with Nvidia Gtx680 I find myself with the display port dead? no possibility to connect a second monitor ufff.Thank's alot...ah forgot with OCLP...
No, if you are installing a non-APFS machine on the internal drive you don't need the stage2 fix. In fact the stage2 completed with the infamous "less than a minute..".
This is the sequence that worked on my MB5,1 late 2008, after stage2 and the following no-go panic. Maybe it works for you too.
Reboot to the USB installer and apply the patches:
-Snapshot booting fix
-Opencore reboot fix
-Legacy USB fix
-Graphic framebuffer fix
-Framework patch (for night shift, optional)
-Install OpenCoreAPFSLoader
-Update OC Config 4b1 ACPI fix.
Now reboot holding option Key, choose OpenCoreAPFSLoader, then the BigSur Volume (or the MacOS installer, I don't remember) and complete the installation.
The following reboots usually don't require to use OpenCoreAPFS, I mean you can reboot normally.
Hope I didn't miss anything, I wrote the steps by heart, here I don't have my summary table.
Good luck.
I am not talking about your card. The only thing I see different in your setup related to NVME compared to mine is
dosdude nVME rom flash. So the EFI NVME driver in the ROM is different than mine. That is why I wanted to test it.