macOS 11 Big Sur on Unsupported Macs Thread

[Barry K. Nathan]

So I assume to use legacy USB without USBOpenCore, my "legacyusb prelinkedkernel fix" should be replaced also on the BaseSystem /System/Library/Prelinkedkernels/ and maybe also on the BaseSystem Preboot for more kext matching .

In my testing, it was only necessary to replace the prelinkedkernel on the USB stick itself (/Volumes/Install macOS Big Sur Beta/System/Library/PrelinkedKernels). The prelinkedkernel is being loaded straight off the USB drive, not from the BaseSystem's Preboot. (It won't do any harm to replace the prelinkedkernel in the BaseSystem and the BaseSystem's Preboot, but I'm not sure it's necessary either.)
[automerge]1596120616[/automerge]

The point is that we don't seem to have a reliable set of instructions that allow others to reproduce the feat of building prelinked kernels under Big Sur once the seal and the snapshot is removed starting from an installation performed on a supported machine. In particular, it is entirely unclear why 'sudo kextcache -i /' procedures a non-functional prelinkedkernel that is so much larger than yours (when the only additional kext added were AppleIntelPIIXATA.kext at 120,557 bytes and LegacyUSBInjector.kext at 137,715 bytes).

As far as the kc's are concerned, the elide that was produced from kmutil and kcditto seemed to indicate that the original kext required by the MacBook Pro 14,1 were still being bundled rather than those for the MacPro 3,1. I am wondering if that is a side-effect of "Error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.apple.KernelExtensionServer" UserInfo={NSDebugDescription=connection to service on pid 0 named com.apple.KernelExtensionServer}". Perhaps that com.apple.KernelExtensionServer connection is required for the recognition of the kext that have to be loaded on the unsupported hardware and, in its absence, the kext set is left as those used by the original supported machine.

I may be mistaken, but I think:

• The elides are consumed, not produced, by kmutil. (I suspect they're put in place by the installer, one way or another, but I'll have to dig into that later.) I think kmutil has a command line option for giving it additional elides, for what that's worth.
• The com.apple.KernelExtensionServer stuff only affects the Auxiliary KC (the one for kexts in /Library/Extensions not /System/Library/Extensions)

 

[jackluke]

In my testing, it was only necessary to replace the prelinkedkernel on the USB stick itself (/Volumes/Install macOS Big Sur Beta/System/Library/PrelinkedKernels). The prelinkedkernel is being loaded straight off the USB drive, not from the BaseSystem's Preboot. (It won't do any harm to replace the prelinkedkernel in the BaseSystem and the BaseSystem's Preboot, but I'm not sure it's necessary either.)

Yes, it is sufficient outside of the BaseSystem , in BaseSystem your "243 stock kext replacement" method worked to fix the tmpfs.kext kp, if you read next messages I also noticed this some minutes later, now the USB BigSur Installer is bootable from non-APFS Mac (also with Wifi), but I am not sure if the stage2 installer will continue just with a patched BaseSystem.dmg (maybe with USBopencore it could continue too), but will do this test on next beta 4 .

 

[Barry K. Nathan]

Yes, they completely changed the Ramdisk structure with BigSur, but thanks to your tips I have a bootable stock BaseSystem with stock prelinkedkernel and through USBOpenCoreAPFSloader3b already allow as is to boot the USB BigSur Installer from legacy USB Mac.

I edited my previous post: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28723098

in few words for using the stock apple BigSur prelinkedkernel on BaseSystem need to replace on BaseSystem SLE the same 243 kext (size about 240 MB) from a full BigSur install, while the forked ones size is 50 MB so they are incomplete of course for the prelinkedkernel.

On a full BigSur installation there are 480 kext (Extensions) or more for about 1,4 GB size, but only 243 (or maybe less) of them are needed to make work the stock prelinkedkernel for a BigSur BaseSystem .

edit:
After replaced the stock installation BigSur 243 kext on the "BaseSystem mounted RW"

to mount BaseSystem RW I used this method: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28626835

to replace the kext this method (use it directly from BigSur sudo -s): https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28722919

when the BaseSystem is modified and unmounted, is sufficient to copy (outside of the BaseSystem):

replace this: prelinkedkernelb3penryn.zip (using this will enable also Wifi on BigSur Recovery)
here: /USBInstallerBigSur/System/Library/Prelinkedkernels/prelinkedkernel

replace this: recovery bigsur com.apple.Boot.plist.zip
here: /USBInstallerBigSur/Library/Preferences/SystemConfiguration/com.apple.Boot.plist

and replace this ASentientBot boot_0xffffffff.efi.zip (rename to boot.efi)
here: /USBInstallerBigSur/System/Library/CoreServices/boot.efi


Now we have a non-APFS and legacy USB bootable USB BigSur Installer even without USBopencore (already tested from a non-APFS Mac and Wifi too is working), don't tested yet a stage2 installer but I assume it could work too.

I'd upload the patched BaseSystem.dmg but it's 930 MB, I am sure that others will provide more clever scripts to automatize this routine.

Thanks for wrapping it all up into one post like this! Just a couple of observations:

For mounting the BaseSystem read-write, you might want to use ULFO instead of UDZO. UDZO uses zlib (essentially gzip) compression, whereas ULFO uses LZFSE compression (it's basically from the same family of FSE/ANS compression algorithms as Zstandard). ULFO compresses at a similar speed to UDZO, takes less disk space (closer to 850MB instead of 930MB), and is much faster to decompress. The only real disadvantage is that ULFO disk images cannot be used on macOS Yosemite or earlier.

For the 0xffffffff patched boot.efi, I found that I had to use bless to copy it into place instead of doing it manually (see post #2546 for details).

 

[jackluke]

Thanks for wrapping it all up into one post like this! Just a couple of observations:

For mounting the BaseSystem read-write, you might want to use ULFO instead of UDZO. UDZO uses zlib (essentially gzip) compression, whereas ULFO uses LZFSE compression (it's basically from the same family of FSE/ANS compression algorithms as Zstandard). ULFO compresses at a similar speed to UDZO, takes less disk space (closer to 850MB instead of 930MB), and is much faster to decompress. The only real disadvantage is that ULFO disk images cannot be used on macOS Yosemite or earlier.

For the 0xffffffff patched boot.efi, I found that I had to use bless to copy it into place instead of doing it manually (see post #2546 for details).

If takes less disk space I'll use ULFO then, about your "243 kext replacement" you rightly deleted the *.kc files to free more space on BaseSystem, and stock BigSur installation kext should be used, because from my test the LZVN decompressed kexts are also incomplete (and still produce tmpfs.kext kp), if someone want to boot that same USB Installer using BKE , simply could copy and use directly a stock BaseSystembackup.dmg .

You could consider to add those "243 BaseSystem kext" already packaged for your micropatcher (I tried to zip them and their compressed size is 100 MB) for those who make the USB BigSur Installer without having BigSur installed .

edit:
To sum up, the free space available on a BigSur BaseSystem is 128 MB (after *.kc removing is 245 MB )

"243 kext stock BaseSystem SLE" size is 50 MB (these are not suffice to allow prelinkedkernel booting)
"243 kext stock BigSur Beta 3 SLE" size is 240 MB (these are suffice to allow prelinkedkernel but imply the removing of *.kc to free more space)

 

[Alex-Microsmeta]

@jackluke It's difficult to follow all experiments in 105 pages. When you have something that I can test for me and you, let me know (as you have already done ) . I'm about to transport here also my iMac 21' late 2013 that is fully compatible with BigSure according to parrotgeek1.

 

[jackluke]

@jackluke It's difficult to follow all experiments in 105 pages. When you have something that I can test for me and you, let me know (as you have already done ) . I'm about to transport here also my iMac 21' late 2013 that is fully compatible with BigSure according to parrotgeek1.

You have a MCP89 Nvidia Chipset Mac mini that is APFS supported with recent IOUSB , so you don't need these fixes that we are discussing about legacy USB (or non-APFS) , for Ivy Bridge Mac you can use parrotgeek1 bigsur installer.

 

[Arnomacmini]

For MacBook6,1 , I did a patch for Catalina that should enable AirDrop in BigSur Finder too (or AirDrop channel on System Report Wifi tab), you can use either with kextcache or kmutil, try replace both the kext : AirDrop Catalina patched MacBook6,1.zip

if you want handoff and AirDrop with a recent iOS device, you simply need to plug any USB Bluetooth 4.0 BLE dongle to your MacBook6,1 .

And after a working AirDrop in Finder, for enabling continuity you could try this from BigSur: catalinacontinuityfix.command.zip

Hello, can i try this ?
I want to make Airdrop work on my Mac mini 5.1 (2011) . In the finder, i have only the picture of Airdrop but it doesn't work .

I wanted to use the Catalina method to replace the kexts but impossible to erase old kekts or put in trash.
Have you a solution ?
Thanks .

 

[Barry K. Nathan]

You have a MCP89 Nvidia Chipset Mac mini that is APFS supported with recent IOUSB , so you don't need these fixes that we are discussing about legacy USB (or non-APFS) , for Ivy Bridge Mac you can use parrotgeek1 bigsur installer.

My recollection is that MCP89 has the same USB setup as MCP79 -- if so, then it doesn't need LegacyUSBInjector to boot from a USB drive with USB 2.0, but it still needs LegacyUSBInjector for the keyboard and trackpad to work (USB 1.1).


For my patcher, I plan to do another release with several improvements that I can do easily without having to modify the BaseSystem. This will probably be v0.0.18. I'm not sure if it'll be this weekend or if it'll be a week from today. After that release, I might start adding the stuff that modifies BaseSystem. The first release that modifies BaseSystem will probably be either v0.1.0 or v0.2.0. (There could be more v0.0.xx or maybe even v0.1.x releases before v0.2.0 is ready.)

It's possible -- not certain, but possible -- that, once I release v0.2.0, I might maintain v0.2.x and v0.1.x (or maybe v0.1.x and v0.0.x, depending on how things shake out) in parallel for a while, for various reasons, until I'm sure that v0.2.x is stable. That way, people with 2011 and newer Macs (as well as MacPro4,1/5,1) could stick with v0.0.x/0.1.x until v0.2.x is proven, and people with 2009/2010 Macs (and I gues MacPro3,1) would have access to v0.2.x which would handle their machines.

This is all tentative and subject to change, but this should give everyone some idea of what my plans are.


By the way, if anyone installs Big Sur, then tries to set up FileVault, and sees this message, just restart your Mac and FileVault will successfully activate. (At least, that's what happened on my MacBookPro8,1 when setting up FileVault under beta 2.) And if you're setting up FileVault on an internal non-Apple SSD, don't forget to use trimforce before activating FileVault! (Trimforce still works the way it always has since El Capitan or Yosemite or whatever release introduced it, even on our unsupported Macs -- just run "sudo trimforce enable" in Terminal -- in the full installed system, not in the installer/Recovery -- and once you agree to its terms, it'll automatically restart your Mac.)

 

[Barry K. Nathan]

@pfandung @guerrabadboy I've now reproduced your FileVault problem. (Doing a clean install of Big Sur beta 2, enabling FileVault, then upgrading to beta 3, is sufficient to reproduce the problem on my MacBookPro8,1. Edit: The problem does not happen with a clean beta 3 install -- it only happens with an upgrade from beta 2 to 3.)

Turning off FileVault doesn't work because the option to turn off FileVault doesn't appear to do anything. Clicking "Forgot all passwords" doesn't work, because you have to enter the Recovery Key on the next screen, and it doesn't recognize the Recovery Key either! At least a Catalina install USB does not ask for the password and allows you to get to Disk Utility, Terminal, etc. (although Disk Utility is unable to unlock FileVault), and the Erase Mac option on the Big Sur install USB works, even though it looks like the Mac is more or less frozen up for several minutes. (And the part about Erase Mac needing an Internet connection is actually untrue, at least for our unsupported Macs.)

Both of you: Do you have your data backed up? Do you have any Time Machine backups (whether they're from Catalina or Big Sur), or do you have any other kinds of backups of Catalina (such as a Carbon Copy Cloner backup or SuperDuper backup of Catalina)? The answers to these questions might affect my advice on how to resolve this situation, especially if beta 4 doesn't fix this.

 

[jackluke]

I made a simple experimental script to patch the BigSur beta3 BaseSystem.dmg to use prelinkedkernel and to allow booting from non-APFS or legacy USB Mac, but currently you need a BigSur installation and run this directly from BigSur because you need "243 stock BigSur kext" (240 MB) to fix BaseSystem (but I'll try to figure out how to replace less of them).

In the script is also included the @Barry K. Nathan method (to replace only the 243 kext already present on the BaseSystem with ULFO compression)

If script worked you should notice in this folder /Volumes/USBInstallerBigSur/BaseSystem/

a patched BaseSystem.dmg size 850 MB (size reduced through the ULFO compression) and a BaseSystembackup.dmg size 884 MB .

(It's advisable to use a 32 GB USB for an USB BigSur Installer, considering that only the installer app zlib compressed currently is 12.88 GB, but I made another fix for those who use a 16 GB USB)

In case of non working the script is harmless for any Mac .

(Note you can also get a backup of stock BaseSystem.dmg from BigSur Recovery:
diskutil mount Recovery ; open /System/Volumes/Recovery/ )

The script is in two parts because I can't find a way to eject only the shadow BaseSystem.dmg to allow the ULFO compression on the same USB drive, so after first part you should unplug and plug your USB BigSur Installer, then continue with second script .

edit:
To boot the patched USB BigSur installer you need from a macOS Recovery terminal csrutil disable
fixed it should work now, launch it directly from BigSur Beta3 normal booting to make a patched BaseSystem.dmg for an USB BigSur beta3 Installer to use legacy USB input output devices and Wifi too
(this version requires an USB BigSur Installer on an USB drive greater than 16 GB ).

edit2:
I made another fix for those who use an USB drive less than 32 GB for the USB BigSurInstaller, use the BigSur 16gb BaseSystem fix.

(this new fix can be used also from 32 GB USB)

edit3:
Here is a new version that works from any macOS with a reduced BaseSystem.dmg size 840 MB :

macOS 11 Big Sur on Unsupported Macs Thread

I just updated the "BigSur BaseSystem fix" for any stock createinstallmedia USB BigSur Installer , now this script should work from any macOS (doesn't require more an already BigSur installed), first requirement is that from a macOS Recovery terminal set csrutil disable then get an "Install...

forums.macrumors.com

 

[Alex-Microsmeta]

I made a simple experimental script to patch the BigSur beta3 BaseSystem.dmg to use prelinkedkernel and to allow booting from non-APFS or legacy USB Mac, but currently you need a BigSur installation and run this directly from BigSur because you need "243 stock BigSur kext" (240 MB) to fix BaseSystem (but I'll try to figure out how to replace less of them).

In the script is also included the @Barry K. Nathan method (to replace only the 243 kext already present on the BaseSystem with ULFO compression).

If script worked you should notice in this folder /Volumes/USBInstallerBigSur/BaseSystem/

a patched BaseSystem.dmg size 840 MB (size reduced through the ULFO compression) and a BaseSystembackup.dmg size 884 MB .

In case of non working the script is harmless for any Mac .

The script is in two parts because I can't find a way to eject only the shadow BaseSystem.dmg to allow the ULFO compression on the same USB drive, so after first part you should unplug and plug your USB BigSur Installer, then continue with second script .

edit:

there was a mistake on the script will upload later

We must find a final fix for error 66. I have succesfully diskutil authenticated-boot disabled and nvram setted to 00...09...00 but still no mount -uw / to modify kexts...?

 

[jhowarth]

I made a simple experimental script to patch the BigSur beta3 BaseSystem.dmg to use prelinkedkernel and to allow booting from non-APFS or legacy USB Mac, but currently you need a BigSur installation and run this directly from BigSur because you need "243 stock BigSur kext" (240 MB) to fix BaseSystem (but I'll try to figure out how to replace less of them).

In the script is also included the @Barry K. Nathan method (to replace only the 243 kext already present on the BaseSystem with ULFO compression)

If script worked you should notice in this folder /Volumes/USBInstallerBigSur/BaseSystem/

a patched BaseSystem.dmg size 850 MB (size reduced through the ULFO compression) and a BaseSystembackup.dmg size 884 MB .

(It's advisable to use a 32 GB USB for an USB BigSur Installer, considering that only the installer app zlib compressed currently is 12.88 GB)

In case of non working the script is harmless for any Mac .

(Note you can also get a backup of stock BaseSystem.dmg from BigSur Recovery:
diskutil mount Recovery ; open /System/Volumes/Recovery/ )

The script is in two parts because I can't find a way to eject only the shadow BaseSystem.dmg to allow the ULFO compression on the same USB drive, so after first part you should unplug and plug your USB BigSur Installer, then continue with second script .

edit:
fixed it should work now, launch it directly from BigSur Beta3 normal booting to make a patched BaseSystem.dmg for an USB BigSur beta3 Installer to use legacy USB input output devices and Wifi too .

Have you tried using your Big Sur usb installer that is hacked to boot on legacy usb hardware to see if that now allows for a usable legacy usb kc to be built from the Terminal application when booted from it? Specifically, does that suppress the "Error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.apple.KernelExtensionServer" UserInfo={NSDebugDescription=connection to service on pid 0 named com.apple.KernelExtensionServer}" error message seen from "sudo kmutil install --update-all" under a normal boot? My suspicion is that this might be an essential part of getting a usable kc built. My experience so far has been that the elides don't get properly regenerated and still reflect those from the supported machine the disk was installed on rather than the actual kext that the unsupported machine needs. Although it is possible that we really need to get the recovery partition hacked to boot on the unsupported legacy usb instead so that 'kmutil invoke-panic-medic' can use used instead. It is unclear if that would work from the patched usb installer.

 

[jackluke]

Have you tried using your Big Sur usb installer that is hacked to boot on legacy usb hardware to see if that now allows for a usable legacy usb kc to be built from the Terminal application when booted from it? Specifically, does that suppress the "Error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.apple.KernelExtensionServer" UserInfo={NSDebugDescription=connection to service on pid 0 named com.apple.KernelExtensionServer}" error message seen from "sudo kmutil install --update-all" under a normal boot? My suspicion is that this might be an essential part of getting a usable kc built. My experience so far has been that the elides don't get properly regenerated and still reflect those from the supported machine the disk was installed on rather than the actual kext that the unsupported machine needs. Although it is possible that we really need to get the recovery partition hacked to boot on the unsupported legacy usb instead so that 'kmutil invoke-panic-medic' can use used instead. It is unclear if that would work from the patched usb installer.

That USB Installer BaseSystem patched is to use prelinkedkernel , from my test to use without errors sudo kmutil install --update-all and to allow Auxiliary Extensions, you should change the com.apple.Boot.plist on the Preboot to don't use the prelinkedkernel , but only BootKernelExtensions.kc that aren't patched for legacy USB (or maybe they could work booting with CMD+S ), to disable prelinkedkernel booting is suffice to remove the com.apple.Boot.plist from this path /Preboot/UUID/System/Library/CoreServices/

then you have a kmutil working kc bootable system, but you need a recent Mac to boot it, then from recent mac you could use this to make a patched legacyUSB BKE : https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28656610

For instance when I make prelinkedkernel or BootKernelExtensions I don't used Recovery but BigSur normal booting (unsealed without snapshot) with a working "sudo mount -uw /".

 

[jhowarth]

That USB Installer BaseSystem patched is to use prelinkedkernel , from my test to use without errors sudo kmutil install --update-all and to allow Auxiliary Extensions, you should change the com.apple.Boot.plist on the Preboot to don't use the prelinkedkernel , but only BootKernelExtensions.kc that aren't patched for legacy USB (or maybe they could work booting with CMD+S ), to disable prelinkedkernel booting is suffice to remove the com.apple.Boot.plist from this path /Preboot/UUID/System/Library/CoreServices/

then you have a kmutil working kc bootable system, but you need a recent Mac to boot it, then from recent mac you could use this to make a patched legacyUSB BKE : https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28656610

For instance when I make prelinkedkernel or BootKernelExtensions I don't used Recovery but BigSur normal booting (unsealed without snapshot) with a working "sudo mount -uw /".

So is this the proverbial chick and the egg situation? You need to boot the unsupported mac from a working kc in order for kmutil to properly create a new one? From my understanding, 'kmutil invoke-panic-medic' is designed to revalidate the currently loading kext on the specific machine so anything you do on the supported machine is entirely unrelated to what the unsupported machine needs.

 

[Muhammad Faruq]

Successfully installed Big Sur Beta 3 on my MBP mid 2012 13''. Not a single problem!! Used big-sur-micropatcher

 

[Alex-Microsmeta]

Here we are!
Finally I'll soon have macOS 11 Big Sur beta 3 with acceleration and all working on iMac late 2013 ?

 

[jackacc]

Where can I download the Big Sur patch?

 

[jpmac1]

I HAVE A 2011 MAC MINI, AFTER BIG SUR INSTALLATION WITH THE big-on-micropatcher PATCH (Version 0.0.17), THE START DOES WITH CODE LINES rather than THE NORMAL PROGRESSION WITH THE LOGO APPLE.
ON THE SAME SSD I HAVE 3 PARTITIONS (HIGH SIERRA, MOJAVE AND BIG SUR). WHEN STARTING ON THE 3, THE LOGO'S PROGRESS IS REPLACED BY A CODE LINE SCROLL.how to solve THIS problem? Thank you.

 

[Barry K. Nathan]

AFTER BIG INSTALLATION ON WITH THE big-on-micropatcher PATCH (Version 0.0.17), THE START DOES WITH CODE LINES rather than THE NORMAL PROGRESSION WITH THE LOGO APPLE.
ON THE SAME SSD I HAVE 3 PARTITIONS (HIGH SIERRA, MOJAVE AND BIG ON). WHEN STARTING ON THE 3, THE LOGO'S PROGRESS IS REPLACED BY A CODE LINE SCROLL.how to solve THIS problem? Thank you.

When you ran /Volumes/Image\ Volume/set-vars.sh in step 6, did you add the -v option for verbose boot? If you did (actually, try this even if you didn't), boot off the patched Big Sur USB again, redo step 6 (make sure not to add -v), then restart your Mac and see if it's back to normal.

 

[jpmac1]

When you ran /Volumes/Image\ Volume/set-vars.sh in step 6, did you add the -v option for verbose boot? If you did (actually, try this even if you didn't), boot off the patched Big Sur USB again, redo step 6 (make sure not to add -v), then restart your Mac and see if it's back to normal.

It's back to normal, thank you.

 

[Alex-Microsmeta]

SUCCESS! Big Sur beta 3 on iMac late 2013 (iMac 14.1)

I have used the old method, csrutil disable from recovery passing from @jackluke opencoreloader3, then using @ASentientBot very simple installer with hax3. After installation all works perfectly: acceleration, wifi, bluetooth, internal sounds in and out and it is REALLY FAST on a Samsung T5 external SSD. Now I can test all the options and 3th party softwares. Its really a shame that Apple doesn't support it officially.

To all Big Sur on Unsupported mac forum users: Just tell me if you need help to patch this 7 years old Mac!

Thank you very much @jackluke and @ASentientBot I'm available for all test you could need to help others to fix issues, also for the Mac mini 2010.

 

[tchek]

Where can I download the Big Sur patch?

here :

macOS Big Sur Patcher Is No Longer Available

parrotgeek.com

big-sur-micropatcher (Version 0.0.17)
A primitive USB patcher for installing macOS Big Sur on unsupported Macs

 

[Stevejediknight]

SUCCESS! Big Sur beta 3 on iMac late 2013 (iMac 14.1)

I have used the old method, csrutil disable from recovery passing from @jackluke opencoreloader3, then using @ASentientBot very simple installer with hax3. After installation all works perfectly: acceleration, wifi, bluetooth, internal sounds in and out and it is REALLY FAST on a Samsung T5 external SSD. Now I can test all the options and 3th party softwares. Its really a shame that Apple doesn't support it officially.

To all Big Sur on Unsupported mac forum users: Just tell me if you need help to patch this 7 years old Mac!

Thank you very much @jackluke and @ASentientBot I'm available for all test you could need to help others to fix issues, also for the Mac mini 2010.

I have a 2012 iMac 21.5. Do you think the procedure you followed would work on mine? Anyone successfully load BS on a 2012 iMac with everything working? Thanks

 

[maxsp97]

I bought the Genuine Apple WiFi 802.11ac Bluetooth 4.2 Adapter Upgrade Kit Mac Pro 4,1/5,1 from eBay. Tested Mojave, Catalina and Big Sur WIFI/BT and AirDrop is working.
https://www.ebay.com/itm/Genuine-Ap...rand=Unbranded&_trksid=p2334524.c100667.m2042

 

[RITAMA]

View attachment 939243

Successfully installed Big Sur Beta 3 on my MBP mid 2012 13''. Not a single problem!! Used big-sur-micropatcher

how ? please step by step ?