macOS 11 Big Sur on Unsupported Macs Thread

[jackluke]

Ok, guys. I just heard from a friend of mine how to get beta 8 using jackluke's usbopencore and Barry's patcher, with airdrop enabled. I will be testing it out this weekend, and will post steps if it works. He even said that hardware acceleration is working on his 2012 13" MBP, but I need to fact-check that with my 2011 13" MBP.
[automerge]1601031636[/automerge]
I will be testing it on a separate partition, and if the results are good, I'll repeat the process on my main drive!

Some notes about my USBopencore 4.2 spoofing version, if after beta 6 installation you patched some kext (typically the Wifi and Sound) that means these kernelcollections changed compared to a "sealed system apple stock":

BootKernelExtensions.kc (easily recoverable), SystemKernelExtensions.kc (size 500 MB or more, not easily recoverable, but more easier if you have an unsealed system or a working "sudo mount -uw /") and AuxiliaryKernelExtensions.kc (that are kext installed on /Library/Extensions/ not useful for Wifi or Audio patches).

Probably some mismatched kernelcollection is recoverable from a BigSur recovery through: kmutil invoke-panic-medic or kmutil trigger-panic-medic --volume-root /Volumes/<YourVolumeName>

Anyway regardless of "SystemKernelExtensions.kc" that is also updated when kext are patched, this should fix an usbopencore booting for the BigSur's Preboot: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28948321

I know It's weird but you need a separate snapshot for opencore, because the snapshot booting used for "apple startup manager" is tagged for a different UUID root, but using my previous step from single user mode should fix this even when using a kernelcollection with patched kext.

My USBopencore setup could work also for other machines, but for those who have a MacPro I advise to follow this thread: https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/

 

[Japenxiamen]

What can I do for this error ?

 

[Ausdauersportler]

What can I do for this error ?

Check your network connection! Sure that your provider allows you to access all available sites? This is really off topic!

 

[mlody]

Any luck getting the big sur on 2012 iMac 27? Originally, I committed to buy 2020 iMac, and actually like the hardware/upgrades that 2020 brings, but with the whole transition to Apple Silicon, I am not so sure if dropping $2k-3k is a smart decision. Because of that, I am looking to keep my 2012 iMac around for another year or until first Apple Silicon macs hit the shelfs and then make a decision.

 

[telepati]

is there any way to Disable Library Validation on Big Sur?

Edit: Found it in the thread. ?

Disable;

sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true

Enable;

sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool false

 

[justperry]

Any luck getting the big sur on 2012 iMac 27? Originally, I committed to buy 2020 iMac, and actually like the hardware/upgrades that 2020 brings, but with the whole transition to Apple Silicon, I am not so sure if dropping $2k-3k is a smart decision. Because of that, I am looking to keep my 2012 iMac around for another year or until first Apple Silicon macs hit the shelfs and then make a decision.

I am in a similar position, I don't want to buy a new Mac now, not until Apple Silicon Macs are around, I then could make a decision to buy one of the last Intels or AS./

 

[Barry K. Nathan]

Oh, yes it can. HD4000 is actually doing pretty good, in my humble opinion. I think that the Intel HD3000 and HD4000 are the only integrated cards where you'll see the least loss in performance in Big Sur

Performance should be vastly better on HD 4000 than HD 3000. HD 4000 has graphics acceleration under Big Sur, HD 3000 doesn't -- after all, HD 4000 supports Metal, but HD 3000 doesn't.

 

[ASentientBot]

Jeez patching macOS will be impossible soon. I'm glad I'm making a patcher while I still can.

"Reduced security mode provides more flexibility by allowing users to disable System Integrity Protection and run any version of macOS, including those that are no longer signed by Apple"
- Link in the comment you replied to

That sounds to me like patching will still be possible ?

 

[webg3]

Some notes about my USBopencore 4.2 spoofing version, if after beta 6 installation you patched some kext (typically the Wifi and Sound) that means these kernelcollections changed compared to a "sealed system apple stock":

BootKernelExtensions.kc (easily recoverable), SystemKernelExtensions.kc (size 500 MB or more, not easily recoverable, but more easier if you have an unsealed system or a working "sudo mount -uw /") and AuxiliaryKernelExtensions.kc (that are kext installed on /Library/Extensions/ not useful for Wifi or Audio patches).

Probably some mismatched kernelcollection is recoverable from a BigSur recovery through: kmutil invoke-panic-medic or kmutil trigger-panic-medic --volume-root /Volumes/<YourVolumeName>

Anyway regardless of "SystemKernelExtensions.kc" that is also updated when kext are patched, this should fix an usbopencore booting for the BigSur's Preboot: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28948321

I know It's weird but you need a separate snapshot for opencore, because the snapshot booting used for "apple startup manager" is tagged for a different UUID root, but using my previous step from single user mode should fix this even when using a kernelcollection with patched kext.

My USBopencore setup could work also for other machines, but for those who have a MacPro I advise to follow this thread: https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/

That must be why I couldn't get it to work, I don't have any snapshots. I will try as informed in the other answer, thanks for everything.

 

[MacHacJac]

Performance should be vastly better on HD 4000 than HD 3000. HD 4000 has graphics acceleration under Big Sur, HD 3000 doesn't -- after all, HD 4000 supports Metal, but HD 3000 doesn't.

I know, but I think that the performance of both wasn't hurt too much in Big Sur. (For HD3000 it might just be because there isn't much performance in the first place lol)
[automerge]1601067964[/automerge]

"Reduced security mode provides more flexibility by allowing users to disable System Integrity Protection and run any version of macOS, including those that are no longer signed by Apple"
- Link in the comment you replied to

That sounds to me like patching will still be possible ?

True, but I would have to learn a whole new structure. Not like I'm doing that right now

 

[webg3]

USBOpenCoreAPFSloader4s not working for me ; please, can someone give me the contents of the EFI folder, because the App is not creating anything, so it is not recognized at boot

 

[Barry K. Nathan]

I have decided to try @jackluke's suggestion of just taking IO80211Family.kext directly from Mojave and using that as the WiFi patch. (To be specific, I took it from Security Update 2020-005 Mojave.) So far it seems to be working well on my MacBookPro8,1. Anyone who wants to try this can get it from the dev-v0.2.1 branch of the GitHub project, which I will link below. I would suggest trying it if you want Handoff and AirDrop (on 2012/2013 Macs) or if WiFi with previous patches has been unstable.

I'm not completely done with v0.2.1 yet, but I think all of the remaining changes are going to be small, and I should be able to arrange the remaining commits so that the tree remains in a functional state and doesn't break at any point before v0.2.1 is finished. If feedback is sufficiently positive, I might finish and release v0.2.1 later today, or if not today then at least this weekend.

https://github.com/barrykn/big-sur-micropatcher/tree/dev-v0.2.1

 

[jackluke]

View attachment 959469

USBOpenCoreAPFSloader4s not working for me ; please, can someone give me the contents of the EFI folder, because the App is not creating anything, so it is not recognized at boot

I uploaded my opencore EFI folder (also updated to 0.6.1) to spoof a supported BigSur Mac in order to detect OTA updates: USBOpencore4s1

to make it working simply copy the EFI folder to any FAT32 formatted volume, at reboot hold alt-option key to select it from the apple startup manager.

But as I wrote a snapshot booting (and sealed system) is required to complete the OTA update properly.

 

[webg3]

I uploaded my opencore EFI folder (also updated to 0.6.1) to spoof a supported BigSur Mac in order to detect OTA updates: USBOpencore4s1

to make it working simply copy the EFI folder to any FAT32 formatted volume, at reboot hold alt-option key to select it from the apple startup manager.

But as I wrote a snapshot booting (and sealed system) is required to complete the OTA update properly.

Man I don't even know how to thank you, thank you very much, really, you were amazing.

 

[eric89074]

Any luck getting the big sur on 2012 iMac 27? Originally, I committed to buy 2020 iMac, and actually like the hardware/upgrades that 2020 brings, but with the whole transition to Apple Silicon, I am not so sure if dropping $2k-3k is a smart decision. Because of that, I am looking to keep my 2012 iMac around for another year or until first Apple Silicon macs hit the shelfs and then make a decision.

BS Beta will run on a 2012 iMac using a patched installer. I installed BS on a late 2013 iMac and 2012 Mac mini and BS runs great on both with an SSD. Catalina will still get security updates by the time the transition to AS is complete.

 

[Japenxiamen]

I have decided to try @jackluke's suggestion of just taking IO80211Family.kext directly from Mojave and using that as the WiFi patch. (To be specific, I took it from Security Update 2020-005 Mojave.) So far it seems to be working well on my MacBookPro8,1. Anyone who wants to try this can get it from the dev-v0.2.1 branch of the GitHub project, which I will link below. I would suggest trying it if you want Handoff and AirDrop (on 2012/2013 Macs) or if WiFi with previous patches has been unstable.

I'm not completely done with v0.2.1 yet, but I think all of the remaining changes are going to be small, and I should be able to arrange the remaining commits so that the tree remains in a functional state and doesn't break at any point before v0.2.1 is finished. If feedback is sufficiently positive, I might finish and release v0.2.1 later today, or if not today then at least this weekend.

https://github.com/barrykn/big-sur-micropatcher/tree/dev-v0.2.1

Thank you, Barry K. Nathan. AirDrop works well, but no hand-off =.=.

 

[jackluke]

Thank you, Barry K. Nathan. AirDrop works well, but no hand-off =.=.

View attachment 959584

To make handoff working, from System Preferences General tab check this:
Allow Handoff between this Mac and your iCloud devices

If already checked then you should from System Preferences Sign out and Sign in again with your Apple ID that must be the same for your iOS devices, moreover you should enable the two form factor authentication: https://support.apple.com/en-us/HT204915 that since Catalina is required to get continuity features to work.

 

[RITAMA]

I uploaded my opencore EFI folder (also updated to 0.6.1) to spoof a supported BigSur Mac in order to detect OTA updates: USBOpencore4s1

to make it working simply copy the EFI folder to any FAT32 formatted volume, at reboot hold alt-option key to select it from the apple startup manager.

But as I wrote a snapshot booting (and sealed system) is required to complete the OTA update properly.

oh TQ..it's work!

 

[jackluke]

oh TQ..it's work!

Even if it's downloading the small OTA it might not install and you get instead delivered an update of 11,51 GB that is also the beta 8 and you could try to install it, allow the "Preparing macOS Big Sur beta 8" to complete, meanwhile check from BigSur terminal:

mount

if the first output line shows a diskXs5s1

that means you are using a snapshot booting (of course it is because you can download a small OTA update)

diskutil info / | grep Sealed

If No means that you have an unsealed system (in few words mountable and writeable from other APFS macOS)

 

[borp99]

But as I wrote a snapshot booting (and sealed system) is required to complete the OTA update properly.

I don't like the fact that a sealed Big Sur system won't mount under Mojave (or Catalina - not too sure). Having to cancel the Mojave notification banner that the format is unknown just bugs me!

As the ideal situation (for me) is to have Big Sur sealed for accomplishing OTA updates but unsealed the rest of the time, is there a simple way to add or delete system 'sealing' from Recovery [obviously following the installation of an initially sealed OS), the same way that Snapshots can easily be added and deleted? Isn't 'sealing' just enacting 256bit encryption (which has been available when partitioning before now) or is it fundamentally different?

 

[jackluke]

I don't like the fact that a sealed Big Sur system won't mount under Mojave (or Catalina - not too sure). Having to cancel the Mojave notification banner that the format is unknown just bugs me!

As the ideal situation (for me) is to have Big Sur sealed for accomplishing OTA updates but unsealed the rest of the time, is there a simple way to add or delete system 'sealing' from Recovery [obviously following the installation of an initially sealed OS), the same way that Snapshots can easily be added and deleted? Isn't 'sealing' just enacting 256bit encryption - and you could do this anyway when partitioning?

As you know even with a Sealed System you can anyway remove or tag empty snapshot to use "sudo mount -uw /", the only issue of a Sealed System is that you can't mount and write it from other macOS.

To unseal the system you should reinstall with ASentientBot Hax3.dylib or Micropatcher that automatically disable it, otherwise during an OTA update, after completed the "Preparing macOS Big Sur beta" instead of auto reboot you can within a minute select to reboot for update later, so you can replace in this path:

/System/Volumes/YourBigSurLabel/macOS Install Data/

this file: https://github.com/jacklukem/BigSurfixes/blob/master/legacyusb installer fix/UpdateOptions.plist

(not sure but maybe is also present on the AssetsV2 long path or on the "source" alias path)

this should complete the OTA staged update unsealed, but currently there is no way to unseal the System directly from BigSur Recovery.

 

[RITAMA]

Even if it's downloading the small OTA it might not install and you get instead delivered an update of 11,51 GB that is also the beta 8 and you could try to install it, allow the "Preparing macOS Big Sur beta 8" to complete, meanwhile check from BigSur terminal:

mount

if the first output line shows a diskXs5s1

that means you are using a snapshot booting (of course it is because you can download a small OTA update)

diskutil info / | grep Sealed

If No means that you have an unsealed system (in few words mountable and writeable from other APFS macOS)

it's show like you said

 

[jackluke]

it's show like you said

I add that when Sealed: Broken means that you can use sudo mount -uw / (even with a sealed system), but in this condition after opencore spoofing OTA update might not downloading or preparing (so it is still on beta 6), to run the OTA update smoothly apart a diskXs5s1 root as apple prefers the System should be Sealed , but this is not so relevant because when they release a full installer app updating process is more simpler.

 

[justperry]

I have decided to try @jackluke's suggestion of just taking IO80211Family.kext directly from Mojave and using that as the WiFi patch. (To be specific, I took it from Security Update 2020-005 Mojave.) So far it seems to be working well on my MacBookPro8,1. Anyone who wants to try this can get it from the dev-v0.2.1 branch of the GitHub project, which I will link below. I would suggest trying it if you want Handoff and AirDrop (on 2012/2013 Macs) or if WiFi with previous patches has been unstable.

I'm not completely done with v0.2.1 yet, but I think all of the remaining changes are going to be small, and I should be able to arrange the remaining commits so that the tree remains in a functional state and doesn't break at any point before v0.2.1 is finished. If feedback is sufficiently positive, I might finish and release v0.2.1 later today, or if not today then at least this weekend.

https://github.com/barrykn/big-sur-micropatcher/tree/dev-v0.2.1

I still get this weird behaviour, didn't change, but Wifi overall seems to be more stable, might have been a bit more stable before I used your dev-v0.2.1 patch.

BTW, I hate the new Wifi Menu, before we could see all the networks in the Menu, now you have to click the other networks button to see the networks near you.

 

[justperry]

Just before my Wifi was connected to "LIFX", if I try to connect to one of my other networks from the Wifi Menu Bar I get the dreaded Could not join "X" network, LIFX was in the preferred networks in System Preferences, I uncheck the checkbox and then it allows me to connect to another one of my own without problem, weird stuff.