Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.

bhast2

macrumors newbie
Jun 11, 2018
6
7
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
 
Comment

tsanchai

macrumors member
Jun 10, 2015
31
11
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
 
  • Like
Reactions: TimothyR734
Comment

Payne Mononymous Bachman

macrumors member
Jun 22, 2020
41
86
Theses two websites may help you guys get this installed successfully.
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.
 
Comment

Pudlo

macrumors member
Apr 3, 2014
55
16
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:
new one:
 
Last edited:
Comment

libneko

macrumors member
Jun 22, 2020
62
165
Siberia
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 :)
 
Comment

libneko

macrumors member
Jun 22, 2020
62
165
Siberia
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
🤔
 
Comment

nandor690

macrumors 6502
Jun 25, 2011
355
209
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. 😊
 
  • Like
Reactions: TimothyR734
Comment

libneko

macrumors member
Jun 22, 2020
62
165
Siberia
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)
 
Comment

ASentientBot

macrumors 6502a
Jun 27, 2018
814
3,210
SkyLight.framework
I sse something similar here

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.
 
Comment

ASentientBot

macrumors 6502a
Jun 27, 2018
814
3,210
SkyLight.framework
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):
Code:
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.
 

Attachments

  • boot 0x867.efi.zip
    384 KB · Views: 193
Last edited:
Comment

Barry K. Nathan

macrumors 6502
Jul 6, 2018
386
1,145
Irvine, CA, USA
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.
 
Comment
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.