macOS 11 Big Sur on Unsupported Macs Thread

[bhast2]

Dumb question, already installed BS on mu MBP mid 2012, flawless, with no wifi, all solutions read are bit too difficult too me so I will wait for an easier way, in the meantime I would like to use a wifi stick archer t2u nano, but when installing the driver it says "wrong version" (obvious), im new on macOS, is there something im doing wrong? or another way?

can you give my step by step guide as to how u got it installed I have the same Mac and it won't boot

 

[Jose C. Salazar]

can you give my step by step guide as to how u got it installed I have the same Mac and it won't boot

you need to be more specific, I used the @GameRoof video on YouTube, but if your problem is this symbol on boot 🚫, just enter terminal on recovery and use -no_compat_check, then reboot

 

[Payne Mononymous Bachman]

Hi everyone if any one is looking for the beta for ios, watch os, tv os, ipad os, Mac OS Big Sur you should check out this link: https://betaprofiles.com/ its free and I have tested the different OS they have provided on their website.
Also here is the the video form Game Roof channel:

I am Interested to hear your thoughts.

 

[Payne Mononymous Bachman]

Also for WiFi issues has anyone tried copying the drivers for WiFi from @dosdude1 mac OS Catilina patcher. If it is possible it may be able to fix the WiFi issues that people are experiencing.

 

[Pudlo]

2012 rMBP 15' fully working with Wifi and even the instruction is not that hard

 

[Payne Mononymous Bachman]

Also while I am thinking about it can we use @dosdude1 Mac OS Catilina patcher and just change the OS to Big Sur instead of Catalina?
[automerge]1593048883[/automerge]

2012 rMBP 15' fully working with Wifi and even the instruction is not that hard

Glad to hear that it is working on a 2012 rMBP 15 with Wifi.

 

[Jose C. Salazar]

2012 rMBP 15' fully working with Wifi and even the instruction is not that hard

What method you used for wifi? I have failed 66 on one method and not acces too root

 

[quaccOS]

2012 rMBP 15' fully working with Wifi and even the instruction is not that hard

Did you use https://github.com/4ndv/big-sur-plz? 2010 MBP 13” here, stuck in boot loop

 

[tsanchai]

What method you used for wifi? I have failed 66 on one method and not acces too root

Can you please give detail step by step on how to install Big Sur on 15 inches mid 2012 rMBP (same as your Mac) with WiFi working so that I can follow.

Thank very much for sharing.

 

[libneko]

Did you use https://github.com/4ndv/big-sur-plz? 2010 MBP 13” here, stuck in boot loop

You'll need to remove telemetry for this to work, afaik

 

[tsanchai]

2012 rMBP 15' fully working with Wifi and even the instruction is not that hard

Can you please provide step by steps on how t9 get Big Sur installed with WiFi 8n mid 2012 15 inches rMBP so that I can follow. Thank very much in advance. I am very confuse with all the readings and don.
’t know what will work. Thank again

 

[Payne Mononymous Bachman]

Theses two websites may help you guys get this installed successfully.

How to install Big Sur to Mac Mini Late 2012

With the new release of Big Sur, apple have dropped my “brand new” Mac Mini Late 2012, so that’s how I made it work with the help of…

medium.com

Big Sur on Unsupported Macs TL;DR

All the information about Big Sur on unsupported Macs structured in one place

lynx.pink

They were sent in the big sur discord which you can find at this link:https://discord.com/channels/495817813932638208/724707989386428437

Hope this helps everyone.

 

[Pudlo]

Can you please provide step by steps on how t9 get Big Sur installed with WiFi 8n mid 2012 15 inches rMBP so that I can follow. Thank very much in advance. I am very confuse with all the readings and don.
’t know what will work. Thank again

What method you used for wifi? I have failed 66 on one method and not acces too root

Did you use https://github.com/4ndv/big-sur-plz? 2010 MBP 13” here, stuck in boot loop

i used this method to install Big Sur on separate Volume
https://www.reddit.com/r/BigSurPatcher/comments/hekcnv
and this to make Wifi work (but its now obsolete and there is a new method, but i'm pretty sure i tried new one and couldn't mount rw so used the longer more dangerous approach, but it worked)
old one i used:

Making WiFi work on Big Sur unsupported Macs with “failed with 66” error

How to make wifi work on unsupported macs running Big Sur, if you have “failed with 66” error

medium.com

new one:

macOS 11 Big Sur on Unsupported Macs Thread

For enabling Wifi 802.11n on any 2012 Mac or any other unsupported Big Sur but supported Catalina Mac (in few words those who use the AirPortBrcm4360 driver), this will work: https://forums.macrumors.com/threads/macos-11-big-sur-on-unsupported-macs-thread.2242172/post-28595200 To install it...

forums.macrumors.com

 

[PiggyGamingYT3]

Also for WiFi issues has anyone tried copying the drivers for WiFi from @dosdude1 mac OS Catilina patcher. If it is possible it may be able to fix the WiFi issues that people are experiencing.

I did this. Nothing happened.

 

[libneko]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -r ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

Sadly, my bless method didn't worked out. Looks like for now, this is our best bet

 

[Payne Mononymous Bachman]

I did this. Nothing happened.

Ok it was worth a shot at suggesting that. Also thank you for trying that to see if it would work.

 

[libneko]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -r ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

...and it haven't worked for me
🤔

 

[nandor690]

big-sur-plz

Installed completely with almost no problem. Everything except NightShift appears to be working fine at the moment. Thanks again

 

[Payne Mononymous Bachman]

Installed completely with almost no problem. Everything except NightShift appears to be working fine at the moment. Thanks again

Cool glad to hear those things are working.

 

[nandor690]

Installed completely with almost no problem. Everything except NightShift appears to be working fine at the moment. Thanks again

I guess I shouldn’t say “everything” but you know, the usual suspects that people are looking for in the beginning. 😊

 

[libneko]

Hey everyone! After wasting half the day on this, I finally figured out one piece of the snapshots/error 66 puzzle.

The TL;DR is that you can just call apfs_systemsnapshot -v /Volumes/... -r "" to boot from the live volume. I haven't seen this published anywhere yet, and the accepted wisdom seems to be that you can't boot the live volume in BS. Hopefully this method will continue to work. It will make patching much easier.

Long version:
- disable SIP, including ARV (funnily enough, my very early boot.efi patch with all the 0xffffffffs actually works for this, even though @dosdude1's 0x67 one does not... anyways, I'll find the correct flags shortly and make a new patch)
- boot into Big Sur or a BS recovery/install disk
- diskutil mount diskXsY the real system volume (not the root snapshot, which will already be mounted at diskXsYsZ)
- find the path to the mounted volume (if you're booted into the same system, it will be volume_name 1 because of the previously mounted snapshot)
- /S*/L*/F*/apfs.fs/C*/R*/apfs_systemsnapshot -v "/Volumes/volume_name" -r ""
- reboot
- mount -uw / should now work, changes will apply immediately to the live volume, and you can remove all the snapshots with diskutil apfs deletesnapshot if desired

(I spent ages reverse engineering apfs_systemsnapshot and learning about the fs_snapshot_* functions before realizing you could just call the tool with an empty string. But if anyone is interested in the code for programmatically managing snapshots, I am happy to share it.)

Thanks to @mac_4eva/this post for the starting point.

One remaining mystery is figuring out how to mount the BS root from Cat. With the sealing/snapshots disabled, I don't see any reason why it shouldn't be possible.

I hope this works for others!

Looks like, at least for me, deleting all the snapshots is also required.

You can do it from BS recovery or Installer usb, after mounting your disk, and doing this:

mount -uw /Volumes/Big\ Sur\ Volume\ Name

diskutil apfs listSnapshots disk2s7 (replace with your disk), here will be uuids

Then for each of the uuids:

diskutil apfs deleteSnapshot disk2s7 -uuid UUIDHERE (replace disk2s7 and UUIDHERE with corresponding values)

 

[nandor690]

Cool glad to hear those things are working.

I shouldn’t say everything is working. Just the usual things in the beginning that people are looking to work

 

[ASentientBot]

I sse something similar here

macOS 11 Big Sur

At WWDC 2020, Apple finally announced a major advancement to the Mac - the migration to Apple silicon with backwards-compatible support for Intel via ...

egpu.io

Absolutely, very good article and quite similar. The difference is I just passed an empty string for the root snapshot name, which seems to cause it to use the live volume. But other people are reporting various results... use at your own risk.

 

[ASentientBot]

With fully disabled SIP including authenticated root (ARV), csr-active-config=w%08%00%00 is set in NVRAM, which corresponds to a value of 0x867 after boot.efi reads it (previously 0x67 on Catalina).

Knowing this, the new boot.efi patch is as follows:
- search for CSR:IN string and find the procedure that references it
- find and some_register1,0xffffffef ("some_register1" changes depending on the build but refers to the value loaded from NVRAM, this line is what explains the csr-active-config "w" (0x77) changing to 0x67)
- find the next line which should be mov dword[some_register3+offset],some_register1 (saves the result, where it will be eventually passed to the kernel)
- copy a nearby line that looks like or byte[some_register2+offset],0x8 (not honestly sure what this is for, but it's necessary -- presumably setting some flag in a structure which is checked later)
- copy the mov line and change it such that it's writing 0x867 rather than the previously read value
- overwrite the start of the function with those two lines and then ret

An example for DP1's boot.efi (file is also attached):

0x1f242: mov dword[rsi+0x498],0x867
or byte[rsi+6],0x8
ret

Most likely @dosdude1 and @parrotgeek1 may want this at some point for your patchers. One thing I noticed is that re-selecting the startup disk can cause boot.efi to be overwritten with the original copy -- probably a good idea to figure out where that "comes from" so it can be replaced as well, or automatically re-replace the file on shutdown. Otherwise, SIP may be randomly enabled after a while (I also had this issue on Cat).

Hope this is useful.

Edit: for wacky extra things like disabling root DMG verification, some "Apple internal" setting, etc. you can just use 0xffffffff instead of 0x867. I just did this in order to boot a modified ramdisk, which is normally not allowed. May be other side effects though.

 

[Barry K. Nathan]

With fully disabled SIP including authenticated root (ARV), csr-active-config=w%08%00%00 is set in NVRAM, which corresponds to a value of 0x867 after boot.efi reads it (previously 0x67 on Catalina).

This got me wondering whether it would be possible to disable authenticated root from a previous macOS's Recovery, via something like nvram csr-active-config='w%08%00%00'. As it turns out, it's possible to do this from Lion recovery, and Mavericks recovery, but not Yosemite or later. (Presumably Mountain Lion recovery also works, but I didn't test it.) I'm not at all surprised that this doesn't work from El Capitan onward, but I'm mildly surprised that Yosemite also blocks it.