macOS 11 Big Sur on Unsupported Macs Thread

[jackluke]

Oh, I think I understood now. @Barry K. Nathan's setvars is a mini-bootable thing of it's own, to reset the relevant vars, right? I'll play with this - if I can make a copy which just sets boot-args and nothing else - which is what I need, so I guess it might be useful for someone else - then I'll post that up.

From any UEFI bootloader binary exec are .efi files, refind can find them automatically, opencore needs in config.plist to add them in Drivers or Tools folder. With those buttons that are based on @Barry K. Nathan and rodsbooks I added a workaround way after exiting from opencore to keep -no_compat_check and SIP custom 0xFFF , a simply PRAM reset clear both, or from a macOS Recovery "csrutil enable" or "csrutil disable" set a standard SIP value.

 

[Barry K. Nathan]

Oh, I think I understood now. @Barry K. Nathan's setvars is a mini-bootable thing of it's own, to reset the relevant vars, right? I'll play with this - if I can make a copy which just sets boot-args and nothing else - which is what I need, so I guess it might be useful for someone else - then I'll post that up.

I think you should take a look at v0.4.0pre of the patcher. (The git branch is called dev-v0.3.4, but it's actually going to be v0.4.0 when it's done.) I might still make some more changes to some parts of the patcher before release, but the setvars changes are done. There are two new variants which do the following:

• set boot-args (one variant with -v for verbose boot, the other without)
• set EnableTRIM=%01 (to enable TRIM on non-Apple SSDs), like all the EFI versions of setvars so far
• unset csr-active-config, so SIP and ARV are enabled

If this is close enough to what you need, you can just use it, otherwise I can do something custom after I finish and release v0.4.0 (in the next day or so) if you have any trouble making your own changes. The source code is there, so in theory you can just change it and recompile, but the thing is that it needs a GNU EFI build environment running on Linux. (Basically, install 64-bit Debian or Ubuntu, then install the build-essential gnu-efi gcc-multilib packages using APT or whatever -- I'm sure other Linux distributions will also work, but Debian is what I used and Ubuntu is similar enough, so they're the ones I can easily describe the setup for.) By the way, the build-all.sh script builds 64-bit, 32-bit, and fat binary versions of setvars, but you probably only need 64-bit so you can just use make directly.

 

[Fran Frin]

It works well on iMac 2011 with a metal capable gpu card.

Whats metal capable gpu card used?

 

[Pascal Baillargeau]

Whats metal capable gpu card used?

AMD Radeon WX7100 for instance, but it can be another card. Have a look at this thread:
2011 iMac Graphics Card Upgrade
With no metal support (no graphic acceleration) Mojave, Catalina, Big Sur are not really usable.

 

[Pascal Baillargeau]

Big Sur Beta9.
As HEVC enc/dec does not work for now in Big Sur i had a look in PrivateFrameworks folder to check for AppleGVA.framework. I did found no executable file in AppleGVA.framework folder and no executable files in all other folders in PrivateFrameworks. Are these executable somewhere else? Or not there at all? Or maybe i have a bad installation?

 

[Ausdauersportler]

Big Sur Beta9.
As HEVC enc/dec does not work for now in Big Sur i had a look in PrivateFrameworks folder to check for AppleGVA.framework. I did found no executable file in AppleGVA.framework folder and no executable files in all other folders in PrivateFrameworks. Are these executable somewhere else? Or not there at all? Or maybe i have a bad installation?

It is not working because Big Sur broke Lilu or Whatevergreen or both. @startergo made a post about this some pages ago.
This is obviously the reason why Lilu is broken...

 

[jackluke]

Big Sur Beta9.
As HEVC enc/dec does not work for now in Big Sur i had a look in PrivateFrameworks folder to check for AppleGVA.framework. I did found no executable file in AppleGVA.framework folder and no executable files in all other folders in PrivateFrameworks. Are these executable somewhere else? Or not there at all? Or maybe i have a bad installation?

The BigSur frameworks (and privateframeworks) exec are all "packaged" here:
/Volumes/BigSurSystemLabel/System/Library/dyld/dyld_shared_cache_x86_64

That makes even harder patching any non-metal or openGL video acceleration.

On early BigSur betas, I guess when system SDK was still 10.16 (now it's 11.0) , on "10.16 BaseSystem.dmg" apple included the "unpackaged" frameworks exec.

Anyway I made earlier some non-clever tests example: BigSur patched CoreBrightness exec

and if you replace for a framework you'd want to patch in this path:

/FrameworkName.framework/Versions/A/Frameworkexec

with a Catalina Frameworkexec, BigSur kernel will try to load that one you replaced in that path before reload the same one on its dyld_shared_cache_x86_64.

Of course to attempt any frameworks replacement you need first Disable Library Validation (ASentientBot method or amfi disabled in nvram), and is advisable snapshot booting disabled to have a working mount -uw / from CMD+S (or even with snapshot enabled but you should make a new snapshot with the frameworkexec replaced).

 

[Barry K. Nathan]

I have released Big Sur Micropatcher v0.4.0. Here are the release notes.

There are many changes in this release, mostly small changes I suppose, but different changes will be very important to different groups of users. Most existing users do not urgently need the improvements or bug fixes in this release and can wait until the next Big Sur beta (or GM) before updating. When it is time to update to the next Big Sur build, make sure not to skip steps 7 or 9, *especially* on Late 2013 iMacs.

patch-kexts.sh now has a new `--iMac` command line option that adds the necessary kext patches for (2011) iMacs which have been upgraded with Metal GPUs. At this time, the --iMac and --2011 command line options must be used together, and the --iMac option only works when running patch-kexts.sh on a live Big Sur installation, not when booted from the installer USB. Thanks to Ausdauersportler for the code contribution.

patch-kexts.sh has an improved check for SIP/ARV that is less prone to false negatives. (Thanks to jackluke for reporting the bug.) Also, there is a new `--force` option to override the check.

patch-kexts.sh now has a `--wifi=` option for choosing a WiFi kext patch. It defaults to `--wifi=mojave-hybrid` (the one that has been used from v0.2.1 onward), but `--wifi=hv12v-old` (used in micropatcher v0.0.6-v0.0.20) and `--wifi=hv12v-new` (used in micropatcher v0.1.0-v0.2.0) are also available.

patch-kexts.sh also adds a `--old-kmutil` option that uses the kmutil from Big Sur beta 8 instead of the one that is installed on the system. This can help with troubleshooting problems with kext patches, especially during patch development. This option is currently not documented in the README. Eventually I will document it, but future patcher releases may change the option's name or other implementation details first.

If patch-kexts.sh is run on a system volume snapshot, it now mounts the underlying volume at `/System/Volumes/Update/mnt1`, just like Apple's own delta updaters.

remount-sysvol.sh and rebuild-kc.sh have been updated with all of the applicable patch-kexts.sh bug fixes from this release and the last several releases, so they now work again.

There are new variants of the setvars EFI program which enable, rather than disable, SIP and ARV (authenticated-root). install-setvars.sh has been updated to automatically use the new variants on Late 2013 iMacs, but there are also command line options for overriding the Mac model detection. The trampoline has been updated to leave APFS volume sealing enabled if both SIP and ARV are enabled. The end result is that, on Late 2013 iMacs, SIP and ARV stay enabled the entire time during and after the installation process, just like on a supported Mac. (Users of other 2012/2013 Macs which have been upgraded to 802.11ac WiFi cards may want to use the `-e` option with install-setvars.sh in order to get the same security benefits as Late 2013 iMac users.)

The `reenable-animations.sh` and `disable-animations.sh` scripts have been moved from the misc-scripts directory to the payloads directory. Thus, they are now copied onto the installer USB, which makes them more conveniently accessible for disabling animations on non-Metal Macs after finishing the Big Sur Setup Assistant.

Finally, there have been many updates to the README.

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

 

[Bmju]

I think you should take a look at v0.4.0pre of the patcher. (The git branch is called dev-v0.3.4, but it's actually going to be v0.4.0 when it's done.) I might still make some more changes to some parts of the patcher before release, but the setvars changes are done. There are two new variants which do the following:

• set boot-args (one variant with -v for verbose boot, the other without)
• set EnableTRIM=%01 (to enable TRIM on non-Apple SSDs), like all the EFI versions of setvars so far
• unset csr-active-config, so SIP and ARV are enabled

If this is close enough to what you need, you can just use it, otherwise I can do something custom after I finish and release v0.4.0 (in the next day or so) if you have any trouble making your own changes. The source code is there, so in theory you can just change it and recompile, but the thing is that it needs a GNU EFI build environment running on Linux. (Basically, install 64-bit Debian or Ubuntu, then install the build-essential gnu-efi gcc-multilib packages using APT or whatever -- I'm sure other Linux distributions will also work, but Debian is what I used and Ubuntu is similar enough, so they're the ones I can easily describe the setup for.) By the way, the build-all.sh script builds 64-bit, 32-bit, and fat binary versions of setvars, but you probably only need 64-bit so you can just use make directly.

@Barry K. Nathan

Many thanks for the helpful info about the required dependencies. I have modified your code now to make myself a little boot image which just sets boot-args="-no_compat_check" (and nothing else) and then does a warm restart. That's a LOT quicker than booting into recovery every time I want to set it. Thanks!

I don't know if it would be okay if I put up a link to my compiled EFI folder of this, in case it's useful to anybody else? (If so, with full credit that it's done using your setvars code, of course.)

 

[Barry K. Nathan]

@Barry K. Nathan

Many thanks for the helpful info about the required dependencies. I have modified your code now to make myself a little boot image which just sets boot-args="-no_compat_check" (and nothing else) and then does a warm restart. That's a LOT quicker than booting into recovery every time I want to set it. Thanks!

I don't know if it would be okay if I put up a link to my compiled EFI folder of this, in case it's useful to anybody else? (If so, with full credit that it's done using your setvars code, of course.)

Yes, it's fine with me.

 

[Bmju]

Here is my simple EFI boot bundle which sets boot-args="-no_compat_check" and then reboots, hopefully on any Mac.

The idea of it is to save you time if you're trying out things in this thread and you find you keep having to boot into Recovery mode just to change this one setting. (Which is more likely to be true if you're trying not to use the full micropatcher, but to install an unpatched Big Sur on a nearly compatible machine, using @jackluke's ID-spoofing OpenCore bootloader.)

To use it:

• Download boot-args.zip
• Unzip it
• Copy the whole EFI folder into the root of any FAT32 USB drive; it doesn't matter if the USB drive has other files on it, these can stay there and you can still use them
• Reboot your MAC with the USB drive plugged in, while holding down the ALT-Option key
• You should see a new boot option called boot-args (if you're not sure, you could try unplugging and plugging back in the USB drive, to see it disappear and reappear again)
• Selecting this boot option will immediately set boot-args="-no_compat_check" and reboot

Just a line to acknowledge and appreciate that this is just a slightly modified version of Barry K. Nathan's setvars program from the excellent big-sur-micropatcher. With very many thanks!

 

[205Maxi]

Just added a custom icon for Restart and Power off so simply reinstall USBopencore through my app and it's shown, but currently it's the same icon for both buttons, because seems from opencore binary exec use a common icon, I also tried to drag and drop the icon in the binary exec and it worked on Finder, but not on opencore menu, so for now they need to use the same icon.

Let me ask you this, is there a way to get 125px to show instead of these huge 256px?? Is it something that we can set in opencore so that it displays smaller icons? I heard that no matter what you do/change, OC displays 256px.

Thank you.

 

[jackluke]

Let me ask you this, is there a way to get 125px to show instead of these huge 256px?? Is it something that we can set in opencore so that it displays smaller icons? I heard that no matter what you do/change, OC displays 256px.

Thank you.

I guess no, but that's not an OpenCore issue rather an OpenCanopy.efi bootpicker, any default icns used by opencanopy contains two pictures, picture1 256px and picture2 128px (I guess picture2 is used for low resolution display), but you could manually edit the picture1 even with Preview.app and resize manually the picture in the icon, in that way it's shown smaller on the OpenCanopy menu; another issue of OpenCanopy is that if you have multiple bootable volumes it doesn't resize to fit correctly the display, for example for 1280x800 opencanopy can draw correctly at screen nine icons, the others are hidden but selectable with keyboard arrows.

 

[Alex-Microsmeta]

Hi @Barry K. Nathan , has micropatcher 0.4.0 something different from mount -uw / to try to inflate kexts in Mac mini 2010? Thank you!

 

[205Maxi]

I guess no, but that's not an OpenCore issue rather an OpenCanopy.efi bootpicker, any default icns used by opencanopy contains two pictures, picture1 256px and picture2 128px (I guess picture2 is used for low resolution display), but you could manually edit the picture1 even with Preview.app and resize manually the picture in the icon, in that way it's shown smaller on the OpenCanopy menu; another issue of OpenCanopy is that if you have multiple bootable volumes it doesn't resize to fit correctly the display, for example for 1280x800 opencanopy can draw correctly at screen nine icons, the others are hidden but selectable with keyboard arrows.

Preview.app not possible I have already tried.. I will try thank you very much.

 

[jackluke]

Preview.app not possible I have already tried.. I will try thank you very much.

I use Preview.app from a 32 bit capable macOS, that is Mojave, maybe try from there (or earlier macOS) that should keep a low level icns format, using Preview.app from a 64 bit only macOS (Catalina and later) won't work to keep a valid icns format.

 

[205Maxi]

I use Preview.app from a 32 bit capable macOS, that is Mojave, maybe try from there that should keep a low level icns format, using Preview.app from a 64 bit only macOS (example Catalina and later) won't work.

Jackluke, thank you very much, I will try.

Here is something actually completely out of subject but maybe we can do something about it, I own an old MacBook Pro 17 2011, with the actual open core I can boot Big Sur perfectly. Though is there a way I could get the AppleALC.Kext to be loaded in the kext folder along the HD3000 kext? do you have them by any chance? I saw a post the other day from Mojave where you were posting them. I can't find them anymore. Would it be possible to get the required ones, HD3000 and AppleALC.kext if you do not mind? thank you.
[automerge]1602518941[/automerge]

 

[jackluke]

Though is there a way I could get the AppleALC.Kext to be loaded in the kext folder along the HD3000 kext?

AFAIK for those is required Lilu.kext but seems doesn't work on BigSur due to incompatible injection on KernelCollection BKE, you could get Sound and basic Graphics using this: https://github.com/barrykn/big-sur-micropatcher

Video acceleration requires Metal 2 I guess, so the kext I posted for Mojave won't work on BigSur.

 

[205Maxi]

AFAIK for those is required Lilu.kext but seems doesn't work on BigSur due to incompatible injection on KernelCollection BKE, you could get Sound and basic Graphics using this: https://github.com/barrykn/big-sur-micropatcher

Video acceleration requires Metal 2 I guess, so the kext I posted for Mojave won't work on BigSur.

But if and say if Catalina runs great on this MacBook Pro 17 ( Did not use dosdude though ) manually patched it, in theory I should get Big Sur working with the same set of kexts correct?

 

[David403]

I use Preview.app from a 32 bit capable macOS, that is Mojave, maybe try from there (or earlier macOS) that should keep a low level icns format, using Preview.app from a 64 bit only macOS (Catalina and later) won't work to keep a valid icns format.

I used a copy of 'Lion' I installed with VMware Fusion 11.5.6 just to use Lion's 'Preview' to resize icons - worked perfectly for me.

As I don't use it for anything else it only occupies about 8 Gb of my Catalina 1Tb SSD.

 

[alfon_sico]

I do not have a glass ball. The best you can get for a very limited set of systems is 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

@jackluke has another approach for some other systems. Search for his posts here.

Got it!! Mac mini 2012 Big Sur beta 9 working very well - patch 0.3.3. Wifi card patched!!

Let's try and beyond. Next step investigate about delta update

 

[Ausdauersportler]

I have released Big Sur Micropatcher v0.4.0. Here are the release notes.

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

Hi Nathan!

After spending some time into the preparation of a new USB boot stick I can confirm that your micro patcher version 4.0 was the smoothest installation experience with Big Sur so far.

Using an iMac 2011 with an AMD WX4130 card I had right in the middle the "com.apple.DiskManagement.disenter error 49168", just restarting and choosing the MacOS installer to continue made a complete installation.

From a running system I opened the Terminal app, changed into the Installer folder and used the sudo ./patch-kext.sh --2011 --iMac --no-wifi to patch the system. On reboot I got a white screen and had to use my custom OpenCore booted to spoof the correct board-id and got the wonderful colored Big Sur login screen, again!

Thanks for making this happen...

P.S.:
We have to add some lines of code for the AMD card to the patch-kext.sh. The installation of the patched AppleIntelSNBGraphicsFB.kext failed. My fault. Submitted the corrected version with a different post, I guess.

 

[webg3]

AFAIK for those is required Lilu.kext but seems doesn't work on BigSur due to incompatible injection on KernelCollection BKE, you could get Sound and basic Graphics using this: https://github.com/barrykn/big-sur-micropatcher

Video acceleration requires Metal 2 I guess, so the kext I posted for Mojave won't work on BigSur.

Video acceleration requires Metal 1 = Intel HD Graphics 4000 on MacBook (Air/Pro/Mini) 2012

 

[Barry K. Nathan]

I have just released Big Sur Micropatcher v0.4.1.

This release fixes bugs in the 2011 --iMac Metal GPU option in patch-kexts.sh. Thanks again to Ausdauersportler for the code contribution. There are also some corrections and updates in the README.

Note that there are USB problems on many 2010 and earlier Macs, which are being tracked as GitHub issue #68. I plan to fix these problems in another release, perhaps later this week.

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

 

[Franky1971]

Hallo, Big Sur don‘t boot with the micropatch. Can I do something? iMac 9,1 I have installed Catalina on AFPS