macOS 11 Big Sur on Unsupported Macs Thread

[jackluke]

Same here on my MBP5,2.
Stage2 runs fine after having applied the stage2 fix.
The legacy USB fix and the stage3 fix don‘t enable stage3 to procees. Looking in single user mode, stage3 hangs with the legacy USB power problem.
In my case I can then hot swap the USB installation target disk to a USB3 port (on a nanotech expresscard), and installation proceeds, but the software solution will be preferable.
I also noticed that the stage3 fix changes the label macOS installer to Big Sur.

The stage2 and stage3 installer for a clean installation should let completed without applying any kext patches, stage2 installer on legacy USB target I'd say is fixed (through BigSur stage2 installer fix), stage3 instead needs further testing, because it uses this new ramdisk: /Volumes/APFS Data Volume/boot/x86_64SURamDisk.dmg

this ramdisk even on external legacy USB target could be ignored if the installation has an apple setup done, that means if at least an user is already made, for example upgrading a previous Mojave, Catalina or BigSur beta already installed on target disk, then my "BigSur stage3 installer fix" is more effective.

But this vnode issue related mainly to the "APFS Data Volume" without any user yet that completed the apple setup, I guess could be also skipped using an APFS container converted (erased) from a previous Mojave or Catalina, or maybe on the next opencore release, because currently opencore have some issues on injecting legacy USB on the "x86_64SURamDisk.dmg" that has its own BKE also on this path: /Volumes/APFS Data Volume/boot/

That said, as you know on those non-APFS machines (even through opencore) installing BigSur directly on target SATA disk, the stage2 and stage3 should automatically complete without any patches, then after the bootloop using "BigSurFixes Legacy USB patches" is sufficient to access the apple welcome screen.

 

[minman]

When ever I try to do nexts patch at the end I get this these are the things I’m doing can someone help

on the installed big sur plug in your patch flash drive open a terminal from the flash drive put patch-kexts.sh wait for it to install restart in my case double shutdown now everything works

 

[LaCamela]

I’m having an iMac Late 2013, and wont be able to run Big Sur. Will there be any patch or so, so I can run it?
Thanks in advance!

 

[justperry]

I’m having an iMac Late 2013, and wont be able to run Big Sur. Will there be any patch or so, so I can run it?
Thanks in advance!

Page 1/Post 1/Original Thread starter

 

[PeterHolbrook]

I'm trying to make Night Shift work after installing an unmodified Big Sur via OpenCore on a Mac Pro 5,1. Unless I'm mistaken, in order to do that, it is imperative to run

csrutil authenticated-root disable

from the Big Sur Recovery partition. Then, and only then, will it be possible to run

mount -uw /

from within Big Sur itself, in order to write to the sealed system volume. However, the rest of the procedure is unclear to me. It appears that, somehow I need to create a snapshot of the system, bless it and boot from it? If I simply run mount... and copy CoreBrightness where I believe it should be, will I be crippling Big Sur and make it impossible to reboot, or would the file simply vanish into thin air when I reboot? If I'm forced to create a snapshot and bless it, et cetera, does the change stick? Do I have to run something like "csrutil authenticated-root enable" afterwards? Do I need to create a new snapshot every time I need to create or modify a file in the system volume? If so, can older snapshots be erased without ill effects?

I hope some of the more experienced users can clarify the above or whatever other scenarios you deem necessary. Thanks.

 

[zorropapa31]

Hello, It's cMP 3,1 (with gtx680, handoff compatible wireless, apfs patched rom), When i post patching with bigmac, it can't delete APFS snapshot. Anybody has an idea, how can i fix? I tried with official 11.0.1 installer. Yeah, and i've got panic loop.

 

[Ausdauersportler]

I'm trying to make Night Shift work after installing an unmodified Big Sur via OpenCore on a Mac Pro 5,1. Unless I'm mistaken, in order to do that, it is imperative to run

csrutil authenticated-root disable

from the Big Sur Recovery partition. Then, and only then, will it be possible to run

mount -uw /

from within Big Sur itself, in order to write to the sealed system volume. However, the rest of the procedure is unclear to me. It appears that, somehow I need to create a snapshot of the system, bless it and boot from it? If I simply run mount... and copy CoreBrightness where I believe it should be, will I be crippling Big Sur and make it impossible to reboot, or would the file simply vanish into thin air when I reboot? If I'm forced to create a snapshot and bless it, et cetera, does the change stick? Do I have to run something like "csrutil authenticated-root enable" afterwards? Do I need to create a new snapshot every time I need to create or modify a file in the system volume? If so, can older snapshots be erased without ill effects?

I hope some of the more experienced users can clarify the above or whatever other scenarios you deem necessary. Thanks.

That will not work ....but read this:

GitHub - barrykn/big-sur-micropatcher: A primitive USB patcher for installing macOS Big Sur on unsupported Macs

A primitive USB patcher for installing macOS Big Sur on unsupported Macs - barrykn/big-sur-micropatcher

github.com

And if you search this thread than you possibly will find a post @jackluke made already about this. This problem has been tackled...searching the thread is a real valuable tool. Otherwise we repeat again and again and...

 

[Stuessi]

Thanks to all of you who have put in the work to either provide solutions or help problem-solve for the larger community. Unless I missed a post, I have a problem that I have not seen mentioned yet on my late-2012 MacMini. Having tried both @Barry K. Nathan's solution and Patched Sur, I get blocked each time but this error message at the end of the USB creation: "An EFI volume is already mounted, Please unmount it and then try again. install-setvards cannot continue". There are no EFI volumes mounted. I have tried rebooting to attempt the install but don't see any EFI volumes to choose from anyway. If anyone has any ideas of how to troubleshoot, please let me know.

 

[pyedog]

Thanks to all of you who have put in the work to either provide solutions or help problem-solve for the larger community. Unless I missed a post, I have a problem that I have not seen mentioned yet on my late-2012 MacMini. Having tried both @Barry K. Nathan's solution and Patched Sur, I get blocked each time but this error message at the end of the USB creation: "An EFI volume is already mounted, Please unmount it and then try again. install-setvards cannot continue". There are no EFI volumes mounted. I have tried rebooting to attempt the install but don't see any EFI volumes to choose from anyway. If anyone has any ideas of how to troubleshoot, please let me know.

This may not be your problem, but I have had issues with some usb drives. You may want to try a different usb stick, format it as GUID, and try again. Good Luck!

 

[Stuessi]

This may not be your problem, but I have had issues with some usb drives. You may want to try a different usb stick, format it as GUID, and try again. Good Luck!

I‘ve used two different USB sticks, formatting them multiple times as GUID, with the same error each time 😢

 

[PeterHolbrook]

That will not work ....but read this:

GitHub - barrykn/big-sur-micropatcher: A primitive USB patcher for installing macOS Big Sur on unsupported Macs

A primitive USB patcher for installing macOS Big Sur on unsupported Macs - barrykn/big-sur-micropatcher

github.com

And if you search this thread than you possibly will find a post @jackluke made already about this. This problem has been tackled...searching the thread is a real valuable tool. Otherwise we repeat again and again and...

I’ve followed this thread and read most of its content. Understand if I don’t thank you for not providing the link to the specific post that addresses my questions.

 

[Ausdauersportler]

I’ve followed this thread and read most of its content. Understand if I don’t thank you for not providing the link to the specific post that addresses my questions.

If your time is too expensive to hit the search button yourself than please understand that I will not waste mine to do so for you. This "link please mentality" is annoying.

I added the @jackluke note, because it came suddenly into my mind. It could have helped you to avoid trying what others already achieved.. and this is still not enough? And at least I provided the link about how to change the system.

But all this is not enough for you?\

Have you at least tried to follow the link?

 

[Mac_tech]

That will not work ....but read this:

GitHub - barrykn/big-sur-micropatcher: A primitive USB patcher for installing macOS Big Sur on unsupported Macs

A primitive USB patcher for installing macOS Big Sur on unsupported Macs - barrykn/big-sur-micropatcher

github.com

And if you search this thread than you possibly will find a post @jackluke made already about this. This problem has been tackled...searching the thread is a real valuable tool. Otherwise we repeat again and again and...

I'm trying to make Night Shift work after installing an unmodified Big Sur via OpenCore on a Mac Pro 5,1. Unless I'm mistaken, in order to do that, it is imperative to run

csrutil authenticated-root disable

from the Big Sur Recovery partition. Then, and only then, will it be possible to run

mount -uw /

from within Big Sur itself, in order to write to the sealed system volume. However, the rest of the procedure is unclear to me. It appears that, somehow I need to create a snapshot of the system, bless it and boot from it? If I simply run mount... and copy CoreBrightness where I believe it should be, will I be crippling Big Sur and make it impossible to reboot, or would the file simply vanish into thin air when I reboot? If I'm forced to create a snapshot and bless it, et cetera, does the change stick? Do I have to run something like "csrutil authenticated-root enable" afterwards? Do I need to create a new snapshot every time I need to create or modify a file in the system volume? If so, can older snapshots be erased without ill effects?

I hope some of the more experienced users can clarify the above or whatever other scenarios you deem necessary. Thanks.

For Night Shift, you you could use f.lux which does the same thing. I use f.lux on my unsupported Mac and it works great.

 

[pyedog]

I‘ve used two different USB sticks, formatting them multiple times as GUID, with the same error each time 😢

Very strange - I have used Barry's patcher multiple times on 2 different mac mini 2012 machines and never had a problem like that. The script is pretty straight forward - it contains

# Make sure there isn't already an "EFI" volume mounted.
if [ -d "/Volumes/EFI" ]
then
echo 'An "EFI" volume is already mounted. Please unmount it then try again.'
echo "If you don't know what this means, then restart your Mac and try again."

so the shell thinks you *do* have an EFI partition mounted at that point.

If you go into Terminal right after you get this error and issue
ls -l /Volumes
what does it return?

An alternate possibility would be to try the following in Terminal:
sudo nvram boot-args='-no_compat_check'
and see if that will let you reboot into the usb installer w/o having to use the efi partition to set the nvram. If you are already on Big Sur you probably shouldn't need to set it again, and if you are not on Big Sur you should be able to set it in the terminal.

 

[jtheogr]

What is the right way to reinstall catalina ?

Undo the kext patch for WiFi with patch-kexts.sh -u
Reset NVRAM
Install Catalina from the usb.

 

[Pinarek]

Hello friends ... I wanted to give a success report about clean installation of an iMac 13,2 late 2012 with 27 inches.
I installed the Barry K Micropatcher 0.5.1 on internal built-in SSD. I only needed to run patch-kexts.sh once after the basic installation to activate the Broadcom WLAN card, that was all. Everything is working fine.

One thing I have not yet managed to remove the sealed, so that everything can be changed, so read u write access. Ok, I don't need to install any additional kexts, but it would still be nice to have full read and write access like in Catalina. I printed out the original English manual from Micropatcher 0.5.0.

I can't handle the terminal commands:

Modifying the System volume yourself


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).

1. Run /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.
2. The script will either remount / 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.
3. At this point, you can make whatever changes you want to the kexts in /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).
4. Once you are done modifying the System volume, run "$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.)
5. Once "$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

I did everything like that and I also saw the correct execution in the terminal window. I've always done these instructions with the bootable Micropatcher 0.5.1 USB stick, because I don't have write access to the terminal in Big Sur, but when I restarted macOS, I always found a sealed system. What am I doing wrong ?

Update: have found a wonderfull Helpsite:
macOS Commands

 

[mixel]

I really have only noticed it with white and gray tones and on maximum brightness. Not sure if that is related in any way, but that's just when I seem to notice it most when it occurs.

Mine was very pronounced and once it kicks in would leave weird residual light/green lines vertical anywhere there has been light stuff on the screen.. Which meant basically no smooth gradients as they’d have shadowy lines messing them up.

No sign of it’s return yet..

 

[Payne Mononymous Bachman]

I can not thank Ben Sova and everyone else in this whole mac rumors thread. Thank you so much for getting Big Sur running successfully on a Mid 2012 non retina Macbook pro with Wi-Fi. truly incredible work.

 

[PBear.SF]

Just installed final release (20B29) on my Late 2012 Mac mini; like with earlier betas, install went without a hitch using @Barry K. Nathan's method. But I now have the oddest bug occurring with Finder that never occurred with any of the betas (or any earlier version of macOS): In Finder Preferences, there is the option "New Finder windows show:" where a folder name must be entered to designate the default folder that comes into view when Finder is opened. (Like always, I'm using my User folder.)

Now, whenever I click on the Finder icon in the Dock, Finder comes to the foreground as the active window -- but, now, every time, it opens a new tab of the selected "New Finder windows show" choice. Finder is only supposed to open this folder when Finder's being opened from a closed state. Now Finder is opening a new, duplicate tab or window every time it's activated from the Dock, even when Finder is already open on the screen. It's startling to see this happen every time I activate Finder -- and somewhat annoying.

Is anyone else experiencing this behavior since installing the final release? If so, I'll post on the Apple Support forum.

Seem to have found the fix. Culprit was apparently a "stuck" preference for multiple desktops ("Spaces") in Mission Control. In System Preferences/Mission Control, option for "When switching to an application, switch to a Space with open windows for the application" was checked. I just tried unchecking it, then checking it again. Now, when I click on the Finder icon in the Dock, screen goes to the desktop where Finder is open and a new Home folder no longer pops open in a new tab. The currently opened folder in Finder just sits there quietly, and alone, in a single tab, like it should.

 

[elxeneize]

Right, BigSur since beta1 caused on any unsupported Mac overheating (I have even a doubt that those few who EFI bricked instead of OTA spoofing was a logic board overheat), because smc sensors are not correctly detected (probably are required some AppleSMC*.kext patches), I made a simple app from BigSur recovery environment, based on this: https://github.com/hholtmann/smcFanControl

I attach also my customised shell app, run it directly from Downloads folder, then open terminal use sudo -s and drag and drop "smc.command", for your MBP to detect average temperature use "CPU temp for Ivy Bridge" function.

Or you can use Macs Fan Control but "Auto" on BigSur won't work, just customise your CPU temperature range for adeguate RPM speed.

I tried this and I got this error, how can I fix it? Thank you!


ads/smc/smc.command

sudo: invalid option -- /
usage: sudo -h | -K | -k | -V
usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user]
[command]
usage: sudo [-AbEHknPS] [-C num] [-g group] [-h host] [-p prompt] [-T timeout]
[-u user] [VAR=value] [-i|-s] [<command>]
usage: sudo -e [-AknS] [-C num] [-g group] [-h host] [-p prompt] [-T timeout]
[-u user] file ...

 

[tokyogentleman]

hello friends, I get lost with so many Mac models, I have a MacBookPro 5.5 from 2009, it runs on Catalina. Do I stay like this or can I upgrade to Big Sur? Cheers

I got a similar MBP5.3, 8GB RAM, RAID0-BOOT on Catalina. It the best we can do for now.

 

[tokyogentleman]

Very strange - I have used Barry's patcher multiple times on 2 different mac mini 2012 machines and never had a problem like that. The script is pretty straight forward - it contains

# Make sure there isn't already an "EFI" volume mounted.
if [ -d "/Volumes/EFI" ]
then
echo 'An "EFI" volume is already mounted. Please unmount it then try again.'
echo "If you don't know what this means, then restart your Mac and try again."

so the shell thinks you *do* have an EFI partition mounted at that point.

If you go into Terminal right after you get this error and issue
ls -l /Volumes
what does it return?

An alternate possibility would be to try the following in Terminal:
sudo nvram boot-args='-no_compat_check'
and see if that will let you reboot into the usb installer w/o having to use the efi partition to set the nvram. If you are already on Big Sur you probably shouldn't need to set it again, and if you are not on Big Sur you should be able to set it in the terminal.

be sure to format the drive as HFS+ and GUID before creating the image. often times there are hidden partitions in the usb.

 

[macsba]

be sure to format the drive as HFS+ and GUID before creating the image. often times there are hidden partitions in the usb.

I thought APFS is the preferred format for both Catalina and Big Sur. Am I missing something here?

 

[avz]

I thought APFS is the preferred format for both Catalina and Big Sur. Am I missing something here?

It might be about bootable USB installer.

 

[PeterHolbrook]

If your time is too expensive to hit the search button yourself than please understand that I will not waste mine to do so for you. This "link please mentality" is annoying.

I added the @jackluke note, because it came suddenly into my mind. It could have helped you to avoid trying what others already achieved.. and this is still not enough? And at least I provided the link about how to change the system.

But all this is not enough for you? You must be really special...

Have you at least tried to follow the link?

I distinctly dislike rudeness. My original request for clarification gave evidence that I HAD read about the issue. There was no need for stupid patronizing remarks, since I know how to search for information. Still, not thanks to you.