macOS 11 Big Sur on Unsupported Macs Thread

[Alex-Microsmeta]

Hi @Barry K. Nathan is this the forked version for Mac mini 2010? https://github.com/barrykn/big-sur-micropatcher/tree/dev-v0.4.5 Thank you!

 

[justperry]

Hi!!!
I installed Big Sur on my Unsupported Imac 2013, and would like to know if there is anyway I can Update it.

THANKS!!!

Update to what?
Plenty of answers here, go read a few pages here.

 

[MacHacJac]

I also attempted to add apps there and if you read my earlier posts, editing Utilities.plist you can point any app exec, but AppleScript converted app won't work, because osascript doesn't work from BigSur Recovery, so you should check that your builded apps are independent and also that launch from BigSur normal booting, because since frameworks are in dyld shared cache you can't add easily frameworks to a BaseSystem to support a third party app, otherwise you should use script apps that are essentially bash script with chmod 755.

Moreover I noticed that is even possible to boot a patched BaseSystem with its stock BootKernelExtensions.kc (but for legacy USB Mac only prelinkedkernel), the main condition is SIP with value 0xFFF or ASentientBot patched 0xfff boot.efi that allows any patched BaseSystem booting without kp verification.

Alright, thanks, so the criteria of a Big Sur Recovery app are:
1) Not applescript
2) Can run off of normal Big Sur boot

I also would need to figure out how to add the third party app due to the dyld shared cache, but patching a duplicate base system is wholly possible. Thank you for the information. I am going to start trying to do this.

 

[jackluke]

Alright, thanks, so the criteria of a Big Sur Recovery app are:
1) Not applescript
2) Can run off of normal Big Sur boot

I also would need to figure out how to add the third party app due to the dyld shared cache, but patching a duplicate base system is wholly possible. Thank you for the information. I am going to start trying to do this.

I added some additional script apps to legacy USB recovery installer, but I am waiting for beta 11 because apple often changed its beta BaseSystem.dmg size and components, on next release they could also change any InstallAssistant exec references dropping the "Beta" naming using "Install macOS Big Sur.app" and to boot a Recovery the naming structure is also checked from BaseSystem ramdisk I guess.

 

[Ausdauersportler]

cool, thank you for your update and you have included the HD3000 bundle, had to add 2 lines in the kext-patch.sh now are as there and still do not put an H264

Basically these are the same files that have been installed until 0.4.0 and which @jackluke provided in his posts. So we have with including the two lines to unzip the files the same state as before. We cannot expect to get a different result. The problem has not been solved from Beta3 on, user @Wania posted about the missing iGPU back then. I did several test since then and had not a single successful one.
Throwing the files back into S/L/E and S/L/PF simply doesn't work as we knew it from Catalina and Mojave, before.

 

[Mark Meretz]

Yes that works somehow, no idea why. I will give the development of BigSur a little more time. Thanks for the support

 

[Alex-Microsmeta]

I added some additional script apps to legacy USB recovery installer, but I am waiting for beta 11 because apple often changed its beta BaseSystem.dmg size and components, on next release they could also change any InstallAssistant exec references dropping the "Beta" naming using "Install macOS Big Sur.app" and to boot a Recovery the naming structure is also checked from BaseSystem ramdisk I guess.

Maybe it will be GM

 

[tom33231]

Does anyone know if there is actually a lack of video decoding acceleration on non metal Macs. I have a MacBook Pro 7,1 I plan to upgrade to Catalina I'm currently on Mac OS 10.14.6. If this is true then let me know. I know for a fact that I had to replace AppleGVA.framework from High Sierra to get video accelerated decoding for quicktime on Mojave. I hope that that's all I have to do on Catalina as well. I saw this a while back when looking into the issue. TimothyR734 said that all I should have to do is replace AppleGVA.framework for video decoding to be accelerated. I am also wondering if h264 would be accelerated like in Mojave if I upgraded to Catalina and just replaced AppleGVA.framework after Dos dues patches.

 

[tom33231]

I added some additional script apps to legacy USB recovery installer, but I am waiting for beta 11 because apple often changed its beta BaseSystem.dmg size and components, on next release they could also change any InstallAssistant exec references dropping the "Beta" naming using "Install macOS Big Sur.app" and to boot a Recovery the naming structure is also checked from BaseSystem ramdisk I guess.

Do you know if there is actually a lack of video decoding acceleration on non metal Macs on Catalina. If so what would I need to do. I am on Mac OS Mojave and I had this issue but I fixed this by replacing AppleGVA.framework from High Sierra. So would Catalina be the same thing.

 

[Ausdauersportler]

Does anyone know if there is actually a lack of video decoding acceleration on non metal Macs. I have a MacBook Pro 7,1 I plan to upgrade to Catalina I'm currently on Mac OS 10.14.6. If this is true then let me know. I know for a fact that I had to replace AppleGVA.framework from High Sierra to get video accelerated decoding for quicktime on Mojave. I hope that that's all I have to do on Catalina as well. I saw this a while back when looking into the issue. TimothyR734 said that all I should have to do is replace AppleGVA.framework for video decoding to be accelerated. I am also wondering if h264 would be accelerated like in Mojave if I upgraded to Catalina and just replaced AppleGVA.framework after Dos dues patches.

Read here:

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

Read the last 3 pages about the H.264 ....

 

[MacHacJac]

I added some additional script apps to legacy USB recovery installer, but I am waiting for beta 11 because apple often changed its beta BaseSystem.dmg size and components, on next release they could also change any InstallAssistant exec references dropping the "Beta" naming using "Install macOS Big Sur.app" and to boot a Recovery the naming structure is also checked from BaseSystem ramdisk I guess.

When the time comes, could you show those to me/us? I'd love to see them implemented so I have a better idea.

 

[tom33231]

Read here:

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

Read the last 3 pages about the H.264 ....

Read here:

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

Read the last 3 pages about the H.264 ....

I see what you're talking about but I'm talking about Catalina not Big Sur. Unless there's info on there about Catalina as well.

 

[jackluke]

When the time comes, could you show those to me/us? I'd love to see them implemented so I have a better idea.

Of course, they are not properly apps, but bash scripts adapted as apps (so they require a minimal keyboard interaction), I am still testing them, mainly I tried to simplify the process to install with minimal patching on non-APFS Mac , next week I should release those and their coding will be readable from any plain text editor.

 

[Franky1971]

During early Catalina beta ASentientBot patched IOHIDFamily.kext to make a kind of automatic exited single user mode, then on next Catalina beta apple weirdly fixed it to work without that patch.

When you install the LegacyUSBInjector.kext as --bundle-path on BKE, does iSight webcam work ?

Because I get kp on later booting when use bundle path for Legacy USB Injector and Video Support .

I guess that kp is due to LegacyUSBVideoSupport.kext (so I removed) while non working iSight to video framebuffer kext loaded, because seems without those kext (using basic graphics kext as safe mode) on BKE (and SKE) the internal webcam worked for Legacy USB Mac .

Hello, is it possible to install Big Sur on a MacBook 4.1? Catalina IS already installed and runs without problems. With the BaseSystem legacy usb fix, it doesn't boot.

 

[jackluke]

Do you know if there is actually a lack of video decoding acceleration on non metal Macs on Catalina. If so what would I need to do. I am on Mac OS Mojave and I had this issue but I fixed this by replacing AppleGVA.framework from High Sierra. So would Catalina be the same thing.

With a non Metal GPU, HighSierra AppleGVA.framework replacement on Catalina has no effect, because non metal Catalina has no hardware decoding acceleration, while non metal Mojave is fully video accelerated .

 

[jackluke]

Hello, is it possible to install Big Sur on a MacBook 4.1? Catalina IS already installed and runs without problems. With the BaseSystem legacy usb fix, it doesn't boot.

That machine requires very legacy usb fix (not only LegacyUSBInjector.kext but some USB* kext replacements), @Larsvonhier released a patched prelinkedkernel for that machine during early beta, you should search and try to replace it to this installer path: /System/Library/PrelinkedKernels/

 

[jackluke]

Maybe it will be GM

Maybe, but even if next release is still a beta, I guess they'll drop anyway the "Beta" suffix from InstallAssistant and from "About This Mac" after the update is installed.

 

[tom33231]

With a non Metal GPU, HighSierra AppleGVA.framework replacement on Catalina has no effect, because non metal Catalina has no hardware decoding acceleration, while non metal Mojave is fully video accelerated .

Is there anyway to achieve full video acceleration or is Windows or linux my only hope now other than what's supported or Mojave on that machine.

 

[tom33231]

Is there anyway to achieve full video acceleration or is Windows or linux my only hope now other than what's supported or Mojave on that machine.

I found this that you posted a while back does this work to accomplish this.

macOS 10.15 Catalina on Unsupported Macs

I've been working on the remaining acceleration issues on non-Metal systems (bad performance in some websites, lack of video decoding acceleration). I think I've made some slight progress, though I'm not entirely sure what to make of it. This tool VDADecoderChecker reports the status of video...

forums.macrumors.com

 

[Franky1971]

That machine requires very legacy usb fix (not only LegacyUSBInjector.kext but some USB* kext replacements), @Larsvonhier released a patched prelinkedkernel for that machine during early beta, you should search and try to replace it to this installer path: /System/Library/PrelinkedKernels/

Thank you for the quick answer. I'll look for the prelinkedkernel.

 

[Ausdauersportler]

I see what you're talking about but I'm talking about Catalina not Big Sur. Unless there's info on there about Catalina as well.

Then, I would strongly recommend you search for another thread. Read the title of this one.
This is not the Catalina thread and just in case, check the forum rules about cross posting.

 

[hvds]

During early Catalina beta ASentientBot patched IOHIDFamily.kext to make a kind of automatic exited single user mode, then on next Catalina beta apple weirdly fixed it to work without that patch.

When you install the LegacyUSBInjector.kext as --bundle-path on BKE, does iSight webcam work ?

Because I get kp on later booting when use bundle path for Legacy USB Injector and Video Support .

I guess that kp is due to LegacyUSBVideoSupport.kext (so I removed) while non working iSight to video framebuffer kext loaded, because seems without those kext (using basic graphics kext as safe mode) on BKE (and SKE) the internal webcam worked for Legacy USB Mac .

Good, jackluke, that you remember this.

Some news regarding CMDS+S delay / USB response:
I've patched the IOHIDFamily exec from BS beta10's IOHIDFamily.kext à la ASentientBot, using hopper disassembler v4. No re-codesign done but that seems unnecessary. So in effect function _isSingleUser always returns TRUE.

Installed the patched IOHIDFamily.kext, again via patch-kexts.sh. Booting my legacy USB MBP5,2 now results in responsive USB keyboard and mouse even without CMDS+S/exit (tried booting a few times). iSight also works, but I think it did before.
I can't easily tell with my non-graphics-accelerated machine if this patch causes undesired delays elsewhere.

Anyway attached is the IOHIDFamily.kext containing the patched exec.

 

[jackluke]

Good, jackluke, that you remember this.

Some news regarding CMDS+S delay / USB response:
I've patched the IOHIDFamily exec from BS beta10's IOHIDFamily.kext à la ASentientBot, using hopper disassembler v4. No re-codesign done but that seems unnecessary. So in effect function _isSingleUser always returns TRUE.

Installed the patched IOHIDFamily.kext, again via patch-kexts.sh. Booting my legacy USB MBP5,2 now results in responsive USB keyboard and mouse even without CMDS+S/exit (tried booting a few times). iSight also works, but I think it did before.
I can't easily tell with my non-graphics-accelerated machine if this patch causes undesired delays elsewhere.

Anyway attached is the IOHIDFamily.kext containing the patched exec.

Well done, codesigning is not required for kext exec, but only for frameworks exec, I notice that also your iSight webcam works.

But I guess for some non-APFS machines still there is an iSight issue not due to LegacyUSBInjector.kext or IOHIDFamily.kext or patched CoreBrightness, because from my another test seems that on non-APFS Mac FaceTime iSight crashed when framebuffer video kext are loaded, instead with basic graphics kext (as those used in safe mode) it works.

edit:
Your patched file worked to skip CMD+S and exit for legacy USB Mac, checking your IOHIDFamily exec is reduced to 882 KB (while stock apple beta 10 one is 2 MB ) so more than half of assembler code has been removed from binary patching or there was some ARM coding removed after binary exec produced ?

@ASentientBot and @Barry K. Nathan could you confirm that modifying the assembler code for _isSingleUser function from IOHIDFamily binary stock 2 MB the binary size is reduced to half, I guess it's the ARM code that is removed from Disassembler when build Mach-O x86_64 output exec ?

In that case (as for Catalina exec 32 bit is removed) ARM binary code is almost unuseful for Intel cpus, so @hvds patched IOHIDFamily worked correctly for BigSur legacy USB Mac.

 

[Alex-Microsmeta]

Good, jackluke, that you remember this.

Some news regarding CMDS+S delay / USB response:
I've patched the IOHIDFamily exec from BS beta10's IOHIDFamily.kext à la ASentientBot, using hopper disassembler v4. No re-codesign done but that seems unnecessary. So in effect function _isSingleUser always returns TRUE.

Installed the patched IOHIDFamily.kext, again via patch-kexts.sh. Booting my legacy USB MBP5,2 now results in responsive USB keyboard and mouse even without CMDS+S/exit (tried booting a few times). iSight also works, but I think it did before.
I can't easily tell with my non-graphics-accelerated machine if this patch causes undesired delays elsewhere.

Anyway attached is the IOHIDFamily.kext containing the patched exec.

Wow, I can't wait to test it on my Mac mini 2010!

 

[hvds]

edit:
Your patched file worked to skip CMD+S and exit for legacy USB Mac, checking your IOHIDFamily exec is reduced to 882 KB (while stock apple beta 10 one is 2 MB ) so more than half of assembler code has been removed from binary patching or there was some ARM coding removed after binary exec produced ?

Could be due to ARM code. I just overwrote the beginning of _isSingleUser with the two instructions and left the (orphaned) rest of the function untouched.
Then to save the change did in hopper disassembler File / Produce New Executable.

Edit: probably Hopper Disassembler can't deal with the ARM instruction set anyway, it may ignore ARM code already while reading the exec file.