A primitive USB patcher for installing macOS Big Sur on unsupported Macs
By the way, if you have a Mac Pro, Big Mac by StarPlayrX is another patcher worth considering. For 2008 Mac Pros (MacPro3,1) in particular, Big Mac is clearly a better option than this patcher (at least for now).
Thanks to the following people for their hard work to get Big Sur running on unsupported Macs:
--wifi=hv12v-old
and --wifi=hv12v-new
options for patch-kexts.sh
), as well as patches used for Metal GPU support on 2011 iMacs.In addition, thanks to Ben Sova, MachInit, johncaling40, and Travis Parker for their contributions to this patcher.
This documentation is more thorough than for previous versions of this patcher, but it may still be incomplete. Remember that you do this at your own risk, you could lose all your data (it's your responsibility to do a Time Machine backup first!), expect bugs and crashes, and this patcher is still under development.
I repeat, do a Time Machine backup before upgrading!! Big Sur changes how Time Machine backups are done, and I have heard that it is not possible to use previous versions of macOS to recover data from Big Sur's Time Machine backups. (I have created Time Machine backups with Big Sur, and I have restored them using Big Sur, but I have not yet tried to access Big Sur Time Machine backups using previous macOS releases.)
Keep in mind, Mojave and Catalina will probably receive security updates until roughly September 2021 and September 2022 respectively (give or take a month), so you can continue using Mojave or Catalina for now. If you are currently running High Sierra, it probably makes more sense to upgrade to Mojave (or maybe Catalina) for now, rather than Big Sur. This patcher definitely needs more time to mature, and considering that Big Sur is the first x.0 release of macOS in roughly 20 years, it would also be a good idea to give Apple more time to fix Big Sur bugs.
Note that this information is incomplete and may not be 100% correct yet, but I'll add more information over time and fix any errors as I learn about them.
Also, note that Macs without Metal GPUs (basically 2011 and earlier Macs, except for Mac Pros and iMacs with upgraded GPUs), "no graphics acceleration" is a tremendous, almost exponential, slowdown. For instance, consider a simple benchmark, simply minimizing a Safari window:
Mostly compatible Mac models:
Partially compatible Mac models:
--2010
option for patch-kexts.sh (step 15) installs fixes for Wi-Fi, sound, and Ethernet, as well as drivers that enable the GeForce Tesla (9400M/320M) framebuffer (thereby fixing sleep and display brightness control). The framebuffer driver does not provide acceleration; the lack of graphics acceleration plus the relatively slow Penryn CPU means performance is sluggish. On at least some of these models, step 6 may fail with errors.--2010
option for patch-kexts.sh (step 15) installs fixes for Wi-Fi, sound, Ethernet, and USB, as well as drivers that enable the GeForce Tesla (9400M/320M) framebuffer (thereby fixing sleep and display brightness control). The framebuffer driver does not provide acceleration; the lack of graphics acceleration plus the relatively slow Penryn CPU means performance is sluggish. Also, the installation has to be performed on a newer Mac first (basically a 2010 or newer Mac, or a 2009 or later Mac Pro), with patch-kexts.sh --2010 run on that same newer Mac, then moved over to the old Mac (via either a hard drive/SSD transplant or by using a USB enclosure or USB hard drive/SSD). Otherwise, the installer will boot because USB 2.0 works, but the keyboard and trackpad won't work because USB 1.1 doesn't work. USB support in the installer for these Macs is planned for a future patcher release.Potentially incompatible Mac models:
Incompatible Mac models:
Currently not supported by this patcher, but future support may be possible:
I strongly recommend that you create, and hold onto, an installer USB for an older version of macOS, ideally one that is supported on your Mac (so that it can run without the use of a patcher). Or, at the absolute minimum, practice booting into Internet Recovery (boot while holding down Command-Option-R) so that you know it actually works. Once it boots, try starting Safari and (as a test) see if it can visit GitHub.com. If not, then it may have booted into OS X Lion, which is also old enough that attempting to install it through Internet Recovery will fail. (Internet Recovery tends to be especially likely to boot into Lion if you have only 4GB of RAM. Also, if you have upgraded to an 802.11ac WiFi card, Internet Recovery will fail completely unless you plug into Ethernet. In addition, with the possible exception of flashed 2009 Mac Pros, Internet Recovery is not available on any Mac models prior to 2010.)
In any case, if you are unable to start Internet Recovery, or it has a version of Safari too old to visit GitHub.com, then it is vital that you create an installer USB for an older macOS version and hold onto it in case of emergency.
Once you create the patched installer USB for Big Sur, hold onto it as well. If you ever reset your Mac's NVRAM, then you will need to use the patched installer USB to repeat step 9 of the installation instructions.
If you have installed any 3rd-party antivirus program or security suite, make sure to uninstall it before installing Big Sur (or do a fresh installation instead of an upgrade). It is not sufficient to turn the antivirus program off -- it must be uninstalled. If you do not uninstall it, you may have no Internet connection after Big Sur is installed, and the Wi-Fi patch may fail to work.
On a Mac without a Metal GPU, several programs, including Maps and Photos, will not work. Perhaps there may be patches in the future to provide partial fixes, but upgrading to a Metal GPU is the only actual solution.
FileVault has been buggy throughout the entire Big Sur development cycle. For maximum stability, disable FileVault before upgrading to Big Sur. Once you upgrade to Big Sur, bugs may make it impossible to disable FileVault and may make it impossible to unlock your FileVault volumes when applying updates or booting from the installer USB. (Not to mention, FileVault bugs may also make it impossible to open Terminal on the installer USB.) The best way out of this conundrum is probably to back up the entire Big Sur installation using Time Machine (Time Machine encryption, unlike FileVault, appears to be stable), erase and reinstall Big Sur, and use the Setup Assistant to restore the Time Machine backup.
Upgrading from a Catalina installation which has been patched using dosdude's macOS Catalina Patcher results in an unstable system. The instability is not fixed by running the Big Sur installer again. So far, the only fix seems to be similar to the method for disabling FileVault: Back up the entire Big Sur installation using Time Machine, erase and reinstall Big Sur, and use the Setup Assistant to restore the Time Machine backup. In my testing, this appears to correct the instability.
Time Machine backups must be restored by first performing a fresh Big Sur installation and then doing the Time Machine restore from the Setup Assistant. Attempting to do the restore from the installer USB fails. I do not yet know if this is inherent to Big Sur, inherent to the patching process, or a bug in this patcher.
If you encounter "com.apple.DiskManagement.disenter error 49168" during installation, try rebooting and see if the installation process continues, or try erasing the volume and starting installation over. This appears to be an error that also happens sometimes on supported Macs. If all else fails, a possible workaround is to try formatting the volume as Mac OS Extended instead of APFS in step 8 or 11; it will still be converted to APFS during the installation process, but this may perturb the installation process enough to avoid the error.
createinstallmedia
in the next step. (If this USB stick already contains a patched Big Sur installer created using micropatcher v0.2.0 or later, and you are re-creating it with a newer version of the micropatcher or a newer version of Big Sur, you may skip this step.) createinstallmedia
as usual to create a bootable USB stick with the installer and recovery environment, as you would on a supported Mac. (This patcher is easier to use if the installer USB stick is not renamed after createinstallmedia
is used, but it can still work if the USB stick has been renamed.)micropatcher.sh
to patch the USB stick. If micropatcher.sh is unable to find the USB stick, then try specifying the pathname of the USB stick to micropatcher.sh. The easiest way to do that is to open a Terminal window, drag and drop micropatcher.sh into the Terminal window, go back to Finder, choose Computer from the Go menu, drag and drop the USB stick into the Terminal window, then press Return.install-setvars.sh
. If necessary, the same Finder/Terminal drag-and-drop instructions that work in step 6 for micropatcher.sh
will also work in this step for install-setvars.sh
.micropatcher.sh
, install-setvars.sh
needs root permissions (since it accesses the normally hidden EFI partition on the USB stick), so it uses sudo
to obtain root permissions. Typically this means it will ask for your user account password when it starts.install-setvars.sh -v
instead of just install-setvars.sh
. However, the "Verbose" in "Verbose Mode" is not a joke, and most users will want to avoid this.install-setvars.sh
will now install a version of setvars which enables Apple's System Integrity Protection (SIP) and Authenticated Root Volume (ARV) security features if it is run on a Late 2013 iMac, or a version of setvars which disables both of these features if it is run on any other model of Mac. You may add a -d
option to force the installation of the setvars version which disables these features (for instance, if you are creating the USB on a Late 2013 iMac but you will be using it on another Mac). You may also add a -e
option to for the installation of the setvars version which enables these features (for instance, if you are installing Big Sur on a 2012 or 2013 Mac that has been upgraded with an 802.11ac WiFi card and therefore does not need a WiFi patch)./Volumes/Image\ Volume/insert-hax.sh --seal
and quit Terminal. If you have no idea what any of this means, just skip this step. (Also, note that even though volume sealing is disabled by default with this patcher, snapshot root is still enabled. Just mentioning this because people sometimes confuse the two issues. If you have some need to disable snapshot root, that is beyond the scope of this README. Personally, I would suggest learning to live in harmony with snapshot root rather than declaring war on it; the section "Modifying the System volume yourself" at the end of this README may help in that regard.)--2010
option. That will fix the kernel panic.patch-kexts.sh
command to do post-install patching (such as fixing Wi-Fi). There are several ways of formatting this command. For example, for a system volume named Macintosh HD
, try one of the following:
/Volumes/Image\ Volume/patch-kexts.sh /Volumes/Macintosh\ HD
'/Volumes/Image Volume/patch-kexts.sh' '/Volumes/Macintosh HD'
"/Volumes/Image Volume/patch-kexts.sh" "/Volumes/Macintosh HD"
/Volumes/Image\ Volume/patch-kexts.sh "/Volumes/Macintosh HD"
/V<tab>/Im<tab>/p<tab> /V<tab>/Mac<tab>
at the command prompt -- that's much less typing than /Volumes/Image\ Volume/patch-kexts.sh /Volumes/Macintosh\ HD
!/Volumes/Image\ Volume/patch-kexts.sh --2010 /Volumes/Macintosh\ HD
.patch-kexts.sh
installs the mojave-hybrid
WiFi patch (used since micropatcher v0.2.1), but if you need to try a different WiFi patch for any reason, try adding the --wifi=hv12v-old
(same as v0.0.6-v0.0.20) or --wifi=hv12v-new
(same as v0.1.0 or v0.2.0) option.patch-kexts.sh
tries to automatically detect whether it should create a new APFS snapshot if it is running in a live system, and it defaults to creating a new snapshot if it is running from the patched installer USB. If you need to override this, there are now --create-snapshot
and --no-create-snapshot
command line options, as of micropatcher v0.3.0./Volumes/Install\ macOS\ Big\ Sur\ Beta/patch-kexts.sh
with any command line options if needed (such as /Volumes/Install\ macOS\ Big\ Sur\ Beta/patch-kexts.sh --2011
), but do not specify a volume name, and patch-kexts.sh will automatically default to the boot drive./Volumes/Image\ Volume/zap-snapshots.sh /Volumes/Macintosh\ HD
. (Or you can also do this if you are running low on disk space on an older beta of Big Sur.) This is basically the same as step 15, but with zap-snapshots
instead of patch-kexts
, and without any command line options like --2010
or --2011
.disable-animations.sh
from the patched installer USB to disable most animations. If you want to reenable them, run reenable-animations.sh
. (Thanks to johncaling40 for these contributed scripts.)If you reset your Mac's NVRAM, attempts to boot Big Sur afterward will fail with a prohibited/no-entry sign on the screen. To fix this, repeat step 9 (booting the "EFI Boot" partition of the patched installer USB). Likewise, if you transplant the hard drive with the Big Sur installation from one Mac to another, or you move an external hard drive/SSD with Big Sur from one Mac to another, you will need to repeat step 9 on the destination Mac before it can boot Big Sur.
To update from one beta to the next, you may create a bootable USB for the new beta (using createinstallmedia), patch it with this patcher, then follow the directions above (except skip Disk Utility, i.e. skip steps 8 and 11) to boot from the patched USB and install it on top of the previous beta. (Allow something like 1-3 hours for the update, even if it looks like it froze up at some point, especially on a 2011 or older Mac.) This will uninstall the Wi-Fi, etc. kexts that were installed in step 15 on the previous beta, so you will need to redo that step as well. There are other methods of updating using delta updaters, but they are more difficult (and you will need to run patch-kexts.sh -u
, described below, to remove all kext patches before attepting that type of update).
For what it's worth, patch-kexts.sh
has a -u
command line option for undoing the kext patches (such as 802.11n Wi-Fi). It can only undo kext changes applied through patch-kexts.sh
and not any kext changes applied through other means. (A more time-consuming but potentially more thorough alternative is to reinstall Big Sur on top of your existing installation, as if you were using the method described in the previous paragraph to update to a new Big Sur beta.)
If you want to undo the setvars EFI utility's changes to boot-args and csrutil settings, then boot from the USB stick, open Terminal, and run /Volumes/Image\ Volume/reset-vars.sh
. (Or you can just start your Mac while holding down Command-Option-P-R to reset NVRAM. That is probably a better way of doing it.)
The best way to remove the patch from the USB stick is to redo createinstallmedia
, but if you are working on patcher development or otherwise need a faster way to do it, you can run unpatch.sh
.
After you finish installation, you may want to modify the System volume yourself. For various reasons you may want to install kext patches other than those which are part of this patcher. Or there may be other changes you want to make to the System volume. However, Big Sur normally boots from a read-only snapshot of the System volume, so making changes is typically not as simple as remounting the volume as read-write. Two shell scripts to assist with this, remount-sysvol.sh
and rebuild-kc.sh
are provided. For now, remount-sysvol.sh
should be run from the patched installer USB (but after booting from your Big Sur installation).
/Volumes/Install\ macOS\ Big\ Sur\ Beta/remount-sysvol.sh
. Due to a bug which will be fixed in a future patcher release, it must be run like that, with the full pathname./
as read-write (if your system somehow started directly off the System volume), or it will create a temporary mount point and mount the underlying System volume at that temporary mount point. Then it will change the current directory to /System/Library/Extensions
wherever the System volume is mounted read-write (probably on the temporary mount point), and it will start a subshell./System/Library/Extensions
, or whatever other changes you want to make on the System volume for that matter. These changes can be made using whatever means you prefer -- they do not need to be done through the subshell (although they can be). You may also run /Volumes/Install\ macOS\ Big\ Sur\ Beta/zap-snapshots.sh
to delete all APFS system snapshots except for the most recent (this script must be run inside the subshell)."$REBUILD_KC"
(including the quotation marks). This must be run inside the subshell. This will rebuild the kernel/kext collections that Big Sur uses as its kernel cache. Note that if you try to install a kext which is incompatible with Big Sur, this may fail; in that case, you will need to undo the incompatible kext change and try "$REBUILD_KC"
again. (If you ran zap-snapshots.sh in step 3 without making any other changes to your System volume, then this step is not required. For most Big Sur systems, this step will be required if any other changes are made to the System volume, to create and "bless" a new snapshot. If your Big Sur system boots directly from the System volume rather than using snapshot booting -- this is rare -- then this step is only needed if you make kext changes, and it will not create any snapshots.)"$REBUILD_KC"
finishes successfully, run the exit
command in the subshell. The remount-sysvol.sh
script will then attempt to unmount the temporary mount point. The unmount attempt may fail, but if so, it's no big deal because macOS will unmount it when restarting anyway.