macOS 11 Big Sur on Unsupported Macs Thread

[Ausdauersportler]

I'm using OC to force the install through, but I have a late 2012 retina MBP - this is just before the Big Sur support cutoff, and with an updated Wi-Fi card Big Sur can run on it completely unpatched.

The black screen issue is known within the iMac world for a longer time with NVIDIA cards. You can solve this by patching in your board-id into the AppleGraphicsControl.kext using this ...assuming you know how to make root writable and rebuild the kernel..

cd /Systems/Library/Extensions

MYBOARD=`/usr/sbin/ioreg -l | grep board-id | awk -F\" '{ print $4 }' | grep Mac`

/usr/libexec/PlistBuddy -c 'Add :IOKitPersonalities:AppleGraphicsDevicePolicy:ConfigMap:$MYBOARD string none' AppleGraphicsControl.kext/Contents/PlugIns/AppleGraphicsDevicePolicy.kext/Contents/Info.plist

chmod -R 0:0 AppleGraphicsControl.kext
chown -R 755 AppleGraphicsControl.kext

Of course you have to apply the usual kmutil commands, the best thing is to use the scripts @Barry K. Nathan provided to change the system.

It would be possible to add this in general into the micropatcher, i.e. check for Nvidia GPU and do the patch. This change does not really hurt if no NVIDIA card will be used, I guess.

To achieve this I need a list of available NVIDIA GPUs in 2012-2013 iMacs/Macbooks, just post back the result of this line:

/usr/sbin/system_profiler SPDisplaysDataType | fgrep "Device ID" | awk '{print $3}'

 

[ReiPs]

Hello everybody.
Please! Is there any way to install Big Sur on iMac Mid 2011?
AirPort Extreme (0x168C, 0x9A) Firmware: Atheros 9380: 4.0.74.0-P2P

Thank you!

 

[lumos]

Search back for posts made by user @jackluke - he published once a patched framework.

Which patcher you have used so far, ask the author to add the framework? It has been included into the latest dev version of the micropatcher. Will release it soon, but you can access it right now.

I used BigMac and I asked @StarPlayrX the possibility to add the script.
He say ok to add it but he need a working script.

 

[Phil G.]

Why do all these scripts use shell? Python is far superior.

 

[PBear.SF]

Thanks to everyone for all the terrific advice, workarounds, patches and scripts that allowed me to run Big Sur on my Mac mini (Late 2012) for all these months, starting with the first beta. Nevertheless, I am jumping ship now, thanks to my new Mac mini (M1/2020), with Big Sur natively installed, that was delivered last Friday.

I'm amazed by the speed of this M1 machine (Safari, for example, opens instantly now, instead of after 2-3 seconds on the old model; even legacy Intel applications, under Rosetta, open and respond faster than they did on the old Intel-based Mac mini running off an SSD). I've successfully re-installed all my old applications, with only one exception (VirtualBox, sadly not ready for M1 Macs yet and, even when it is, it will likely only support ARM-based virtual machines, at least to begin with). With trade-in, the new base model was US$599, plus tax. A viable alternative to unsupported Macs, if you've got that much at your disposal now or in the future .

Best to all.

 

[Ausdauersportler]

Why do all these scripts use shell? Python is far superior.

This is off topic, most shells are stable for years now, part of the Unix OS derivatives and so the scripts do not depend on deprecated or new python versions. Each additional layer makes all these things not really more stable and as far as I know all scripting near the Unix OS core is shell based. Let‘s stick with it.

 

[Ausdauersportler]

I used BigMac and I asked @StarPlayrX the possibility to add the script.
He say ok to add it but he need a working script.

As far as I know my micropatcher fork is public.

 

[Ausdauersportler]

Hello everybody.
Please! Is there any way to install Big Sur on iMac Mid 2011?
AirPort Extreme (0x168C, 0x9A) Firmware: Atheros 9380: 4.0.74.0-P2P
View attachment 1715642

Thank you!

No real chance! You can use patcher option #6 from the first post but since your iMac had never support by @dosdude1 with Mojava and Catalina the very same is true with Big Sur. The Radeon 6xxx series sucks. Stick with High Sierra or exchange your GPU - first link of my signature.

 

[naylom11]

I'm using OC to force the install through, but I have a late 2012 retina MBP - this is just before the Big Sur support cutoff, and with an updated Wi-Fi card Big Sur can run on it completely unpatched.

If I've understood correctly, OC from I think 0.6.4 onwards can block whatever Apple are doing which is bricking these machines, but only if you boot through OC every time.

So I'm currently stuck with any of:

a) Completely replace the Apple boatloader with OC (probably the best choice!)
b) Always boot via the Apple boatloader initially, and only start OC as a sideloader when I want to do an upgrade (which is what I am actually doing), but in that case I can then choose:
i) Always install from a *full* download and use `createinstallmedia`, because this never black-screens
ii) Install using an incremental update (which is desirable because you can get updates sooner, and in principle they are much faster to install), but in this case I always have to disassemble the machine and disconnect then reconnect the battery after the first reboot, to get my machine back from the black screen state

I'm surprised that Apple still don't seem to have fixed the issue - even up to and including 11.2 beta 2 - especially as it didn't happen in the early betas of Big Sur.

I don't know if it is something to do with supporting the fast incremental update, which I believe new to Big Sur updates system files in place on the cryptographically signed system drive.

The fact that it isn't fixed makes me think Apple isn't ever going to fix it; and the fact that they are insisting on upgrading the logic boards on these machines (when all you apparently need to do is disconnect the battery to get the machine back ... but in fact this only fixes it until the next incremental update) makes sense if they aren't ever going to fix it. If my guess is right, then maybe the reason for replacing the logic boards is not that they are fried, but rather that they are being replaced with logic boards that support something new. Any other opinions? Does this make sense?

This theory still doesn't really add up, unfortunately, if you can buy a second-hand logic board from an old Mac as a replacement and that works as a permanent fix. (I'm not sure if that is the case or not.) Unless somehow something in my Mac's logic board really HAS been fried ... but only in a way that prevents it rebooting during an incremental update until you disconnect and reconnect the battery....!!! Which seems pretty unlikely!

Okay there's a lot to unpack here. Maybe this can provide some clarity.

First and foremost, your machine is capable of running Big Sur, but it does require a patch to boot. Whether that's the micro patcher or opencore. You can't get around it. You'll have to bypass nocompatcheck and other boot flags. There is no native booting with your particular machine. If that were the case the 2012 rMbp would be officially supported, which its not. What you mean to say is that your system doesn't require any additional kexts. And you'd be correct, with an upgraded airport card it works just like a supported system (except when it comes to booting). You need some patched solution.

Second. You're misunderstanding the way opencore works fundamentally. It never fully replaces the apple boot loader. When you install it, it becomes a boot option within the apple boot loader itself (or a "sideloader" as you call it). And when setup correctly your system will boot directly into it, allowing system spoofing/kext injection at boot. This can always be averted by holding down the option key, but in order to update correctly, set up opencore the way its intended to be used. This will make OTA updates work as intended as well.

Third. Its Opencore 0.6.6 (not 0.6.4 or 0.6.5) that has added the MaxBIOSVersion protection against unintended firmware updgrades, and thus negates the bricking issue. So you won't have to disconnect the battery. However, this needs to be tested as newer versions of Big Sur roll out (proceed with caution as always). The latest legacy patcher is built around OC 0.6.6.

And fourth. Apple hasn't released any full installers for either 11.2 beta, and there was some news that the days of full standalone installers may be dead. While it sucks, creating a full installer for each upgrade may not be an option going forward. Therefore I'd stick with opencore for the foreseeable future. (Unless of course apple does the smart thing, and releases the full installer... but we can only hope)

 

[Phil G.]

This is off topic, most shells are stable for years now, part of the Unix OS derivatives and so the scripts do not independent on deprecated or new python versions. Each additional layer makes all these things not really more stable and as far as I know all scripting near the Unix OS core is shell based. Let‘s stick with it.

I see...thanks.

 

[Bmju]

... I need a list of available NVIDIA GPUs in 2012-2013 iMacs/Macbooks, just post back the result of this line:

/usr/sbin/system_profiler SPDisplaysDataType | fgrep "Device ID" | awk '{print $3}'

Hi @Ausdauersportler :

I have a late 2012 13" retina display MBP (MacBookPro 10,2 ; board id Mac-AFD8A9D944EA4843) here's the info you want from mine:

$ /usr/sbin/system_profiler SPDisplaysDataType | fgrep "Device ID" | awk '{print $3}'
0x0166

 

[Bmju]

Okay there's a lot to unpack here. Maybe this can provide some clarity.

First and foremost, your machine is capable of running Big Sur, but it does require a patch to boot. Whether that's the micro patcher or opencore. You can't get around it. You'll have to bypass nocompatcheck and other boot flags. There is no native booting with your particular machine. If that were the case the 2012 rMbp would be officially supported, which its not. What you mean to say is that your system doesn't require any additional kexts. And you'd be correct, with an upgraded airport card it works just like a supported system (except when it comes to booting). You need some patched solution.

Second. You're misunderstanding the way opencore works fundamentally. It never fully replaces the apple boot loader. When you install it, it becomes a boot option within the apple boot loader itself (or a "sideloader" as you call it). And when setup correctly your system will boot directly into it, allowing system spoofing/kext injection at boot. This can always be averted by holding down the option key, but in order to update correctly, set up opencore the way its intended to be used. This will make OTA updates work as intended as well.

Third. Its Opencore 0.6.6 (not 0.6.4 or 0.6.5) that has added the MaxBIOSVersion protection against unintended firmware updgrades, and thus negates the bricking issue. So you won't have to disconnect the battery. However, this needs to be tested as newer versions of Big Sur roll out (proceed with caution as always). The latest legacy patcher is built around OC 0.6.6.

And fourth. Apple hasn't released any full installers for either 11.2 beta, and there was some news that the days of full standalone installers may be dead. While it sucks, creating a full installer for each upgrade may not be an option going forward. Therefore I'd stick with opencore for the foreseeable future. (Unless of course apple does the smart thing, and releases the full installer... but we can only hope)

Hi - many thanks for all the feedback!

1. I really think it doesn't require a patch, if patch means "persistent change to at least some part of the files which make up OS" (which I think it does!?). I'm booting it without a patch. It JUST requires nvram boot-args="-no_compat_check"; that nvram setting is persistent once set, and unpatched/unchanged Big Sur will boot and keep booting on my machine as long as that nvram var remains set. (I do need a temporary patch, provided by OC, in order to make the Big Sur installer detect my machine as one on which it can run, and also in order to allow the software updater to see Big Sur updates as ones which are valid for my machine; so, each time I want to check for and/or install updates, but not each time I boot.)

2. Thanks for the clarification. This is still confusing me a bit, because OpenCore can certainly boot Hackinstoshes - and presumably there it must be booting without the Apple bootloader. I was starting to wonder whether there must be a way to do that on Mac hardware too. But maybe not!

3. I know there is a commit in OC which adds BlacklistAppleUpdate, which went into 0.6.4. I think it was meant as a fix for these bricking firmware updates, but I haven't tried it out. Looking at the discussion there, it looks as if it only ended up fixing the issue on non-Mac hardware? I wasn't aware of the new MaxBIOSVersion option, so thanks!

4. I was wondering about no more full updates, so thanks again for that info.

EDIT: I had a final question here, asking about how OC can prevent the black-screen firmware update, when the scheduled update happens before OC starts (in fact, before basically anything else starts); the answer is: by faking something (the BIOS version) so that the Big Sur installer no longer schedules it!

 

[Bmju]

I guess 'all' OC needs to do is somehow prevent the OS updater from actually prepping the firmware update at all, before the reboot ever happens...

I just read through the commit which adds the MaxBIOSVersion flag to OpenCore, and it looks like all I need to do is upgrade to OC 0.6.6, add a setting for MaxBIOSVersion = true in the right place, and my all woes will be over... with incremental updates fully supported. Nice.

 

[laertemeira]

Hi people! Hope u all r safe! Question: any news about @mrbubzie1993 AMD 6xxx drivers?

 

[naylom11]

Hi - many thanks for all the feedback!

1. I really think it doesn't require a patch, if patch means "persistent change to at least some part of the files which make up OS" (which I think it does!?). I'm booting it without a patch. It JUST requires nvram boot-args="-no_compat_check"; that nvram setting is persistent once set, and unpatched/unchanged Big Sur will boot and keep booting on my machine as long as that nvram var remains set. (I do need a temporary patch, provided by OC, in order to make the Big Sur installer detect my machine as one on which it can run, and also in order to allow the software updater to see Big Sur updates as ones which are valid for my machine; so, each time I want to check for and/or install updates, but not each time I boot.)

2. Thanks for the clarification. This is still confusing me a bit, because OpenCore can certainly boot Hackinstoshes - and presumably there it must be booting without the Apple bootloader. I was starting to wonder whether there must be a way to do that on Mac hardware too. But maybe not!

3. I know there is a commit in OC which adds BlacklistAppleUpdate, which went into 0.6.4. I think it was meant as a fix for these bricking firmware updates, but I haven't tried it out. Looking at the discussion there, it looks as if it only ended up fixing the issue on non-Mac hardware? I wasn't aware of the new MaxBIOSVersion option, so thanks!

4. I was wondering about no more full updates, so thanks again for that info.

EDIT: I had a final question here, asking about how OC can prevent the black-screen firmware update, when the scheduled update happens before OC starts (in fact, before basically anything else starts); the answer is: by faking something (the BIOS version) so that the Big Sur installer no longer schedules it!

No worries!

In terms of the word patch, I just meant any modification to "trick" the system into loading BigSur. Technically speaking, changing that in the boot args is patching, because its modifying the system, and it doesn't survive an NVRAM reset (as booting into a Catalina Install would)... But this is just a matter of semantics. I have a mid-2012 non retina and have a very similar setup to yours. My advice would be install OC on a USB first and do some testing. This will allow you to boot using OC whenever you'd like, and check for updates. Just reset the NVRAM and reapply the nocompatcheck boot arg when switching back.

And think about opencore as simply emulating a Mac efi. Because your machine has the native bootROM baked into the firmware, there's no way for opencore to modify that or "take over"... It simply becomes an option within the boot menu. With a hackintosh its no different. Opencore doesn't replace the system bios on those machines, it simply becomes an option to load during the boot process. Although its not exactly the same, think of the Mac Boot Menu as a Hackintosh Bios.

And you are correct about the last question! Hope this helps

 

[buckrock]

Hi @Ausdauersportler :

Mine is 15" rMBP mid-2012, (10,1), i7, 802.11ac wifi card, dual graphics, Board ID Mac-C3EC7CD22292981F and here's my output:

buck ~ % /usr/sbin/system_profiler SPDisplaysDataType | fgrep "Device ID" | awk '{print $3}'
0x0166
0x0fd5
buck ~ %

 

[LavaTech]

I have officially been boomed. Im going for Big sur on a gt 120 in a 8 core mac pro 5,1. Its running mojave decently fine (patched) rn. hehe gt 120 go boom

 

[n0rt0nthecat]

To achieve this I need a list of available NVIDIA GPUs in 2012-2013 iMacs/Macbooks, just post back the result of this line:

/usr/sbin/system_profiler SPDisplaysDataType | fgrep "Device ID" | awk '{print $3}'

iMac late 2013, NVIDIA GT 750M 1GB

0x0fe9

 

[rehkram]

To achieve this I need a list of available NVIDIA GPUs in 2012-2013 iMacs/Macbooks, just post back the result of this line:

/usr/sbin/system_profiler SPDisplaysDataType | fgrep "Device ID" | awk '{print $3}'

Here you go. Mine is an rMBP 15 inch 10,1 mid 2012,
Intel HD Graphics 4000 1536 MB
NVIDIA GeForce GT 650M 1 GB

0x0166 <---- intel
0x0fd5 <---- Nvidia

 

[vinaypundith]

Mid-2012 non-Retina Core i5 13" MacBook Pro 9,2 - Issues with OpenCore Legacy Patcher 0.0.9

So I just completed my full rebuild of a nearly destroyed MacBook Pro. (Honestly for how many parts I had to replace I should have just given it the sledgehammer and bought another laptop). Sure seemed like the laptop had been soaked in water or something. Wouldn't have been so bad if I hadn't wasted $160 for damaging the motherboard while cleaning it. Got a fresh installation of Catalina 10.15.7 loaded on it (natively supported, no patches used).

So to install Big Sur, I chose to go with the OpenCore Legacy Patcher option because I prefer the method of applying patches at the EFI boot loader level instead of the operating system level, so that the patches won't get messed up with OS updates/reinstalls (an issue I used to face with the DosDude patchers) and OTA updates would be usable - a super duper nice thing.

I followed the instructions at https://github.com/dortania/Opencore-Legacy-Patcher, which had worked great on a 2008 Mac Pro 3,1 that I did a couple of weeks ago, but upon rebooting using the new OpenCore boot loader, it just shows these messages and then starts booting to the recovery partition:

[EB| 'LD:LF] FIO: 0, DIR:1, P: <null string>, DP:1
[EB|'B:SBS] SZ: 6211112
[EB|#B:SHA] f4031e1840ae80899574cd5a1feedc6b106d0f87
[EB|'WLWLFNV] Err(0xE) @ GV wake-failure
[EB|#WLT] 0xCB 0x3C 184 0xCA
[EB|'FS:AGSVH] Err(0xE) @ 'AGU.0
[EB|'LD:LKC] SB -> (System\Library\PrelinkedKernels\immutablekernel)
[EB|'LD:LKC] BPDK -> (System\Library\PrelinkedKernels\immutablekernel.development)
[EB|'LD:LF] FIO: 0, DIR:1, P: System\\Library\\PrelinkedKernels\\immutablekernel.development, DP:0
[EB|'LD:OFS] Err(0xE) @ OPEN (System\\Library\\PrelinkedKernels\\immutablekernel.development)
[EB|'LD:LKC] BPDK, !R -> (System\Library\PrelinkedKernels\immutablekernel)
[EB|'LD:LF] FIO: 0, DIR:1, P: System\\Library\\PrelinkedKernels\\immutablekernel, DP:0

So what have I done wrong? What's an immutablekernel? Also I did not add any prelinkedkernel patches, so why the related errors? Do I need to modify the config.plist configuration created by the OpenCore Legacy Patcher, or exclude some kexts? Tried searching the internet for this error to no avail. Kinda stumped.

I should probably add that the machine that the Legacy Patcher decided to spoof to is a MacBook Pro 11,1.

On a separate subject, is there any way to add support for Intel IDE controllers in OpenCore for Mac OS Big Sur? (Thinking about a Mac Pro 3,1)

 

[Ausdauersportler]

Mid-2012 non-Retina Core i5 13" MacBook Pro 9,2 - Issues with OpenCore Legacy Patcher 0.0.9

So I just completed my full rebuild of a nearly destroyed MacBook Pro. (Honestly for how many parts I had to replace I should have just given it the sledgehammer and bought another laptop). Sure seemed like the laptop had been soaked in water or something. Wouldn't have been so bad if I hadn't wasted $160 for damaging the motherboard while cleaning it. Got a fresh installation of Catalina 10.15.7 loaded on it (natively supported, no patches used).

So to install Big Sur, I chose to go with the OpenCore Legacy Patcher option because I prefer the method of applying patches at the EFI boot loader level instead of the operating system level, so that the patches won't get messed up with OS updates/reinstalls (an issue I used to face with the DosDude patchers) and OTA updates would be usable - a super duper nice thing.

I followed the instructions at https://github.com/dortania/Opencore-Legacy-Patcher, which had worked great on a 2008 Mac Pro 3,1 that I did a couple of weeks ago, but upon rebooting using the new OpenCore boot loader, it just shows these messages and then starts booting to the recovery partition:

[EB| 'LD:LF] FIO: 0, DIR:1, P: <null string>, DP:1
[EB|'B:SBS] SZ: 6211112
[EB|#B:SHA] f4031e1840ae80899574cd5a1feedc6b106d0f87
[EB|'WLWLFNV] Err(0xE) @ GV wake-failure
[EB|#WLT] 0xCB 0x3C 184 0xCA
[EB|'FS:AGSVH] Err(0xE) @ 'AGU.0
[EB|'LD:LKC] SB -> (System\Library\PrelinkedKernels\immutablekernel)
[EB|'LD:LKC] BPDK -> (System\Library\PrelinkedKernels\immutablekernel.development)
[EB|'LD:LF] FIO: 0, DIR:1, P: System\\Library\\PrelinkedKernels\\immutablekernel.development, DP:0
[EB|'LD:OFS] Err(0xE) @ OPEN (System\\Library\\PrelinkedKernels\\immutablekernel.development)
[EB|'LD:LKC] BPDK, !R -> (System\Library\PrelinkedKernels\immutablekernel)
[EB|'LD:LF] FIO: 0, DIR:1, P: System\\Library\\PrelinkedKernels\\immutablekernel, DP:0

So what have I done wrong? What's an immutablekernel? Also I did not add any prelinkedkernel patches, so why the related errors? Do I need to modify the config.plist configuration created by the OpenCore Legacy Patcher, or exclude some kexts? Tried searching the internet for this error to no avail. Kinda stumped.

I should probably add that the machine that the Legacy Patcher decided to spoof to is a MacBook Pro 11,1.

On a separate subject, is there any way to add support for Intel IDE controllers in OpenCore for Mac OS Big Sur? (Thinking about a Mac Pro 3,1)

You need to post those OLP problems and RFE on the Github page of the OLP project or using discord. The developers do *not* read here and we are somewhat lost unless another user with experience can comment on errors.

 

[air.man]

Mid-2012 non-Retina Core i5 13" MacBook Pro 9,2 - Issues with OpenCore Legacy Patcher 0.0.9

So I just completed my full rebuild of a nearly destroyed MacBook Pro. (Honestly for how many parts I had to replace I should have just given it the sledgehammer and bought another laptop). Sure seemed like the laptop had been soaked in water or something. Wouldn't have been so bad if I hadn't wasted $160 for damaging the motherboard while cleaning it. Got a fresh installation of Catalina 10.15.7 loaded on it (natively supported, no patches used).

So to install Big Sur, I chose to go with the OpenCore Legacy Patcher option because I prefer the method of applying patches at the EFI boot loader level instead of the operating system level, so that the patches won't get messed up with OS updates/reinstalls (an issue I used to face with the DosDude patchers) and OTA updates would be usable - a super duper nice thing.

I followed the instructions at https://github.com/dortania/Opencore-Legacy-Patcher, which had worked great on a 2008 Mac Pro 3,1 that I did a couple of weeks ago, but upon rebooting using the new OpenCore boot loader, it just shows these messages and then starts booting to the recovery partition:

[EB| 'LD:LF] FIO: 0, DIR:1, P: <null string>, DP:1
[EB|'B:SBS] SZ: 6211112
[EB|#B:SHA] f4031e1840ae80899574cd5a1feedc6b106d0f87
[EB|'WLWLFNV] Err(0xE) @ GV wake-failure
[EB|#WLT] 0xCB 0x3C 184 0xCA
[EB|'FS:AGSVH] Err(0xE) @ 'AGU.0
[EB|'LD:LKC] SB -> (System\Library\PrelinkedKernels\immutablekernel)
[EB|'LD:LKC] BPDK -> (System\Library\PrelinkedKernels\immutablekernel.development)
[EB|'LD:LF] FIO: 0, DIR:1, P: System\\Library\\PrelinkedKernels\\immutablekernel.development, DP:0
[EB|'LD:OFS] Err(0xE) @ OPEN (System\\Library\\PrelinkedKernels\\immutablekernel.development)
[EB|'LD:LKC] BPDK, !R -> (System\Library\PrelinkedKernels\immutablekernel)
[EB|'LD:LF] FIO: 0, DIR:1, P: System\\Library\\PrelinkedKernels\\immutablekernel, DP:0

So what have I done wrong? What's an immutablekernel? Also I did not add any prelinkedkernel patches, so why the related errors? Do I need to modify the config.plist configuration created by the OpenCore Legacy Patcher, or exclude some kexts? Tried searching the internet for this error to no avail. Kinda stumped.

I should probably add that the machine that the Legacy Patcher decided to spoof to is a MacBook Pro 11,1.

On a separate subject, is there any way to add support for Intel IDE controllers in OpenCore for Mac OS Big Sur? (Thinking about a Mac Pro 3,1)

Check Github. In the issues section there is an open issue related to immutablekernel.

 

[Ausdauersportler]

Here you go. Mine is an rMBP 15 inch 10,1 mid 2012,
Intel HD Graphics 4000 1536 MB
NVIDIA GeForce GT 650M 1 GB

0x0166 <---- intel
0x0fd5 <---- Nvidia

Thanks!
So you have the black screen with stock Big Sur installed, no patch applied and you cannot force the internal display to work on boot by pressing alt/option to force a boot screen?

 

[LavaTech]

I did it!!!!!!!! I finally got Catalina installed on my Mac Pro 5,1, dual cpu, with the gt 120 😂, its actually running better then Mojave (patched) at this rate. I’m going for the big win with Big Sur on this machine.

 

[LavaTech]

Catalina, going for Big Sur next!