Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
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.

Pendleton115

macrumors newbie
Oct 13, 2019
14
28
Thought you all would want to see this, my 2012 15" Unibody MacBook pro has had it's WiFi card replaced with a more modern one and it runs Big Sur flawlessly, no Kext edits required. better than Catalina IMO
Screen Shot 2020-06-26 at 11.59.09 am.png

If you're curious about the WiFi card you can find it here: https://subtle.design/
 

Attachments

  • Screen Shot 2020-06-26 at 11.57.38 am.png
    Screen Shot 2020-06-26 at 11.57.38 am.png
    3.2 MB · Views: 156

ASentientBot

macrumors 6502a
Jun 27, 2018
863
3,421
SkyLight.framework
Alright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.

I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?

Hardware checks
These are present both in the installer (the BIErrorDomain error 3 message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with -no_compat_check, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.

Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to the APFS_INCOMPAT_SEALED_VOLUME flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fix error 66 for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.

Snapshots
This causes the notorious error 66 when trying to remount the system volume, since / actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created by ramrod/patchd in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to use diskutil apfs deletesnapshot to remove all snapshots (thank you to @libneko for this idea). However one sticking point is that diskutil will sometimes refuse to remove the most recent one. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too. I've never managed to do that though, since I get an error referring to it being tagged for booting.

SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.

Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.

One thing I'm still not clear on is why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.

Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]
You miss the point. Currently Big Sur already requires SIP to be disabled in order to allow unsupported legacy kernel extensions to load. If that gets removed by Apple, one would likely have to hack code that loads very early and which probably has some serious signing requirements imposed upon it. Good luck with that.
This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature on boot.efi. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.

But that doesn't mean it won't be a pain!
 
Last edited:

iMac-iPad

macrumors newbie
Jan 16, 2020
24
51
Alright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.

I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?

Hardware checks
These are present both in the installer (the BIErrorDomain error 3 message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with -no_compat_check, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.

Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to the APFS_INCOMPAT_SEALED_VOLUME flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fix error 66 for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.

Snapshots
This causes the notorious error 66 when trying to remount the system volume, since / actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created by ramrod/patchd in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to use diskutil apfs deletesnapshot to remove all snapshots (thank you to @libneko for this idea). However one sticking point is that diskutil will sometimes refuse to remove the one that's flagged for booting. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too.

SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.

Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.

One thing I'm still not clear on why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.

Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]

This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature on boot.efi. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.

But that doesn't mean it won't be a pain!
Awesome @ASentientBot you are the Big Sure Hero keep hope n fighting as always, best of luck man!
Sure man you must have right to edit wikipost
Thank You & All Devs!
 
Last edited:

jbapps

macrumors newbie
Oct 9, 2019
6
13
Alright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.

I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?

Hardware checks
These are present both in the installer (the BIErrorDomain error 3 message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with -no_compat_check, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.

Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to the APFS_INCOMPAT_SEALED_VOLUME flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fix error 66 for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.

Snapshots
This causes the notorious error 66 when trying to remount the system volume, since / actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created by ramrod/patchd in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to use diskutil apfs deletesnapshot to remove all snapshots (thank you to @libneko for this idea). However one sticking point is that diskutil will sometimes refuse to remove the most recent one. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too. I've never managed to do that though, since I get an error referring to it being tagged for booting.

SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.

Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.

One thing I'm still not clear on is why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.

Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]

This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature on boot.efi. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.

But that doesn't mean it won't be a pain!

I just want to say thank you for all that you do to keep our old Macs alive. Your hard work is appreciated by us all.
 

ASentientBot

macrumors 6502a
Jun 27, 2018
863
3,421
SkyLight.framework
Awesome Asentientbot you are the Big Sure Hero keep hope n fighting as always, best of luck man!
Sure man you must have right to edit wikipost
I just want to say thank you for all that you do to keep our old Macs alive. Your hard work is appreciated by us all.
Thanks guys, I appreciate all the positivity even after I've spent the last couple days mostly being confused. And yes I'm able to edit the wikipost, but I didn't want to unilaterally decide to stuff a bunch of possibly-incorrect text in there before it was checked over a bit.

Hoping to finally make some progress on acceleration over the next few days, now that the worst of the install BS (lol) is dealt with. But it's certainly going to be tricky. If anyone else (looking at you, @pkouame, @testheit and @parrotgeek1, among others) has some ideas or contributions, they will be more than welcome. I'm feeling way out of my depth haha.
 

William Rogers

macrumors newbie
Jun 22, 2020
3
5
This thread will be used to discuss advancements in getting macOS 11.0 Big Sur running on unsupported Macs.

---
Compatibility List:

Macs officially compatible with macOS Big Sur:

  • 2015 and later MacBook
  • 2013 and later MacBook Air
  • Late 2013 and later MacBook Pro
  • 2014 and later iMac
  • 2017 and later iMac Pro
  • 2014 and later Mac mini
  • 2013 and later Mac Pro
Macs officially compatible with macOS Catalina but have been dropped from official support in macOS Big Sur:
- These Macs so far are capable of running Big Sur properly, but Wifi support is currently broken. See FAQ for more information.

  • 2012 and Early 2013 MacBook Pro
  • 2012 MacBook Air
  • 2012 and 2013 iMac
  • 2012 Mac mini
  • 2008-2012 Mac Pro*
*Not officially supported in macOS Catalina, but are fully capable of running both Catalina and Big Sur with a Metal-compatible GPU and upgraded Wifi/BT card.

Macs capable of being patched to run macOS Catalina properly and potentially can be patched to run macOS Big Sur:
- These Macs so far can boot Big Sur, but do not currently feature Wifi or graphical acceleration support. See FAQ for more information.

  • Early-2008 or newer Mac Pro, iMac, or MacBook Pro:
    • MacPro3,1*
    • MacPro4,1*
    • MacPro5,1*
    • iMac8,1
    • iMac9,1
    • iMac10,x
    • iMac11,x (systems with AMD Radeon HD 5xxx and 6xxx series GPUs were almost unusable when running Catalina and will be under Big Sur as well.)
    • iMac12,x (systems with AMD Radeon HD 5xxx and 6xxx series GPUs were almost unusable when running Catalina and will be under Big Sur as well.)
    • MacBookPro4,1
    • MacBookPro5,x
    • MacBookPro6,x
    • MacBookPro7,x
    • MacBookPro8,x
  • Late-2008 or newer MacBook Air or Aluminum Unibody MacBook:
    • MacBookAir2,1
    • MacBookAir3,x
    • MacBookAir4,x
    • MacBook5,1
  • Early-2009 or newer Mac Mini or white MacBook:
    • Macmini3,1
    • Macmini4,1
    • Macmini5,x (systems with AMD Radeon HD 6xxx series GPUs were almost unusable when running Catalina and will be under Big Sur as well.)
    • MacBook5,2
    • MacBook6,1
    • MacBook7,1
  • Early-2008 or newer Xserve:
    • Xserve2,1*
    • Xserve3,1*
*Not officially supported in macOS Catalina, but are fully capable of running both Catalina and Big Sur with a Metal-compatible GPU and upgraded Wifi/BT card.

Macs that WILL NOT BE SUPPORTED in any capacity:
  • 2006-2007 Mac Pros, iMacs, MacBook Pros, and Mac Minis:
    • MacPro1,1
    • MacPro2,1
    • iMac4,1
    • iMac5,x
    • iMac6,1
    • iMac7,1
    • MacBookPro1,1
    • MacBookPro2,1
    • MacBookPro3,1
    • Macmini1,1
    • Macmini2,1
  • — The 2007 iMac 7,1 is compatible with Catalina and potentially Big Sur if the CPU is upgraded to a Penryn-based Core 2 Duo, such as a T9300.

  • 2006-2008 MacBooks:
    • MacBook1,1
    • MacBook2,1
    • MacBook3,1
    • MacBook4,1
  • 2008 MacBook Air (MacBookAir 1,1)
  • All PowerPC-based Macs

---

FAQ:

Q: Why did Apple drop support for my perfectly capable Mac?
A: Only Apple can give a definite answer to this. However there is evidence that it is based upon the CPUs being used in the now-unsupported Macs, which was the case last year with the Mac Pro 4,1/5,1. Intel decided to stop releasing firmware security fixes for Ivy Bridge and previous-generation CPUs. While they are technically compatible and supported in Big Sur, Apple has decided it is not worth the risk to continue supporting CPUs that have permanently unpatched security holes, putting users at risk.

While this is also not confirmed, another possibility could be that some of the excluded Macs feature Wifi chips that are no longer deemed fit for the next major release. This decision could be based on the previously mentioned security issues as well. The presence of graphics drivers for some of these newly unsupported Macs in Big Sur Beta 1 suggests this.

Q: Will my unsupported Mac get macOS 11.0 Big Sur?
A: If your Mac had official support in macOS Catalina, they will likely be able to be patched to run Big Sur with minimal issues. As of writing, only WiFi appears to be broken.
If your Mac was unsupported before the release of macOS Catalina, support remains to be seen as graphics acceleration may not be feasible at this time. While Catalina still supported OpenGL (former macOS graphical API) and even used it as a fallback software render mechanism, Big Sur officially drops support and shifts to Apple's Metal API entirely.

Q: When will my unsupported Mac receive macOS 11.0 Big Sur? / ETA when?
A:
This is a community driven effort to try and restore support for various unsupported Macs. Community members are working as hard as they can, often in their spare time, to try and add back stable support for these Macs. Based upon changes in macOS Big Sur, it may be possible some Macs that were previously patchable in Mojave, Catalina, and other previous releases of macOS may not be patchable under Big Sur. Please do not harass the patch developers to go faster, release the patcher, etc. Please do not clog up the thread with useless posts asking if your specific Mac will be patchable. Big Sur was only just released in its initial beta form and a lot is still subject to change before the final release. Rest assured, the dedicated community of developers working on these patches are doing everything that they can to re-add support for as many Macs as possible.

Q: Where/how can I download macOS 11.0 Big Sur?
A:
For legal purposes, the only official way to obtain a copy of macOS Big Sur is to be a registered Apple Developer and pay a yearly $99 fee to become eligible for downloading beta software. According to Apple, a public beta which does not require a registered Developer account will be released at some point in July and will be free to sign up for. Please remember it is highly suggested that you do not install beta software on your main devices, overwriting any stable releases. Beta software can cause irreparable hardware damage or irrecoverable data loss and should be used at one's own risk.

Apple and all patch developers are not responsible for any potential damage or data loss caused by using pre-release software or unofficial support patches. Please use at your own risk.
Someone told me this online- doesn’t need a patch just an opencore boot loader efi on a usb installer with all booted quirks turned off and a spoofed smbios of imacpro 1,1 after the install it’s no longer needed just need -no_compat_check in nvram. I don’t know if this helps?
 

TimothyR734

macrumors 68030
Apr 10, 2018
2,723
2,753
Logsden Oregon
Alright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.

I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?

Hardware checks
These are present both in the installer (the BIErrorDomain error 3 message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with -no_compat_check, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.

Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to the APFS_INCOMPAT_SEALED_VOLUME flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fix error 66 for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.

Snapshots
This causes the notorious error 66 when trying to remount the system volume, since / actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created by ramrod/patchd in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to use diskutil apfs deletesnapshot to remove all snapshots (thank you to @libneko for this idea). However one sticking point is that diskutil will sometimes refuse to remove the most recent one. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too. I've never managed to do that though, since I get an error referring to it being tagged for booting.

SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.

Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.

One thing I'm still not clear on is why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.

Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]

This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature on boot.efi. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.

But that doesn't mean it won't be a pain!
You are the man Asentientbot will everything you do to help us keep or old Mac's up and running . you and may others here are just awesome and hope one day soon pkouame will be onboard as well :)
 

Barry K. Nathan

macrumors 6502
Jul 6, 2018
387
1,145
Irvine, CA, USA
Hoping to finally make some progress on acceleration over the next few days, now that the worst of the install BS (lol) is dealt with. But it's certainly going to be tricky. If anyone else (looking at you, @pkouame, @testheit and @parrotgeek1, among others) has some ideas or contributions, they will be more than welcome. I'm feeling way out of my depth haha.
Edit: Oh, I guess you meant contributions to acceleration. Whoops, I misread your message, sorry. Edit-edit: Or did I read it right the first time? I don't know. I think I need to take a break.


I don't know if this counts as an idea or contribution, but I've created an initial primitive attempt at a USB patcher, so that one can run the installer from the recovery environment and install onto bare metal just as with a supported Mac or a dosdude1-patched Mojave/Catalina. It depends on your Hax.dylib or Hax2Lib.dylib, which is (currently) not bundled with my patcher and has to be copied onto the USB stick separately. I created this for my own use but then added a ton of error-checking to hopefully make it something suitable for use by others.

I guess it would be neat if I could bundle Hax.dylib or Hax2Lib.dylib (or something functionally equivalent) with the patcher so that the whole thing is self-contained, if you don't mind. (There are some other improvements I'll make to my patcher in the next few days. I think I'll at least change it so that you can copy the entire Hax2.app onto the USB stick and my scripts will find the Hax2Lib.dylib inside Hax2.app.)

Another (hopefully final) edit, to be extra clear: This doesn't try to get WiFi working or deal with the snapshot stuff, yet. It's just to get a basic installation done on an unsupported Mac that doesn't already have another version of macOS installed on it, because I figured that would make it easier for me to try to do further improvements.

 
Last edited:

nandor690

macrumors 6502
Jun 25, 2011
374
221
You miss the point. Currently Big Sur already requires SIP to be disabled in order to allow unsupported legacy kernel extensions to load. If that gets removed by Apple, one would likely have to hack code that loads very early and which probably has some serious signing requirements imposed upon it. Good luck with that.
I get what your saying. But iv been doing hackintoshes and unsupported Mac stuff for years. I don't know how many times iv seen people fret over things that Apple has done that could potentially stop that stuff. Yet....here we are lol
[automerge]1593143371[/automerge]
Alright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.

I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?

Hardware checks
These are present both in the installer (the BIErrorDomain error 3 message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with -no_compat_check, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.

Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to the APFS_INCOMPAT_SEALED_VOLUME flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fix error 66 for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.

Snapshots
This causes the notorious error 66 when trying to remount the system volume, since / actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created by ramrod/patchd in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to use diskutil apfs deletesnapshot to remove all snapshots (thank you to @libneko for this idea). However one sticking point is that diskutil will sometimes refuse to remove the most recent one. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too. I've never managed to do that though, since I get an error referring to it being tagged for booting.

SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.

Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.

One thing I'm still not clear on is why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.

Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]

This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature on boot.efi. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.

But that doesn't mean it won't be a pain!
Thanks a lot for all the time you put into this. Keep up the great work man!
[automerge]1593143563[/automerge]
Someone told me this online- doesn’t need a patch just an opencore boot loader efi on a usb installer with all booted quirks turned off and a spoofed smbios of imacpro 1,1 after the install it’s no longer needed just need -no_compat_check in nvram. I don’t know if this helps?
Thats good info to know. But that is only going to get it installed. There still has to be patches made to fix acceleration and brightness controls (among other things). But using open core may be a better option for people having a problem getting it installed. at least until there is an install tool from this great group of people
[automerge]1593143755[/automerge]
something kind of stupid. But I kinda hope that have a ssd pic for ssd drive :p
Screen Shot 2020-06-25 at 10.54.17 PM.png
 
Last edited:

niccoloboano

macrumors newbie
Jun 26, 2020
6
11
Hello everyone, I've just
1. Disabled SIP from Recovery Mode
2. Downloaded the InstallAssistant.pkg file and installed the package
3. Downloaded the ASentientBot "really simple installer hack" file
4. ran sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true command (for disabling Library Validation)
5. ran launchctl setenv DYLD_INSERT_LIBRARIES $PWD/Hax.dylib command
6. Opened Install macOS Beta.app file
7. Selected Macintosh HD as installation disk

The installer automatically rebooted my mac (Macbook Pro 15, Mid 2010) and booted the installer partition, but when Apple logo shows up the system crashes and reboots, crashing again.

What can I do?

(I'm running macOs Catalina now)
 

avz

macrumors 68000
Oct 7, 2018
1,830
1,896
Stalingrad, Russia
Someone told me this online- doesn’t need a patch just an opencore boot loader efi on a usb installer with all booted quirks turned off and a spoofed smbios of imacpro 1,1 after the install it’s no longer needed just need -no_compat_check in nvram. I don’t know if this helps?

I believe jackluke is already documented quite well this approach in more than one "unsupported threads". You should read the thread before posting any "new" solutions to avoid doubling up and unnecessary bloat which makes it even harder to read.
 

libneko

macrumors member
Jun 22, 2020
62
165
Siberia
Hello everyone, I've just
1. Disabled SIP from Recovery Mode
2. Downloaded the InstallAssistant.pkg file and installed the package
3. Downloaded the ASentientBot "really simple installer hack" file
4. ran sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true command (for disabling Library Validation)
5. ran launchctl setenv DYLD_INSERT_LIBRARIES $PWD/Hax.dylib command
6. Opened Install macOS Beta.app file
7. Selected Macintosh HD as installation disk

The installer automatically rebooted my mac (Macbook Pro 15, Mid 2010) and booted the installer partition, but when Apple logo shows up the system crashes and reboots, crashing again.

What can I do?

(I'm running macOs Catalina now)
If you're getting "crossed circle", then:

sudo nvram boot-args="-no_compat_check"
 
  • Like
Reactions: ASentientBot

jackluke

macrumors 68040
Jun 15, 2018
3,321
8,068
Hello everyone, I've just
1. Disabled SIP from Recovery Mode
2. Downloaded the InstallAssistant.pkg file and installed the package
3. Downloaded the ASentientBot "really simple installer hack" file
4. ran sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true command (for disabling Library Validation)
5. ran launchctl setenv DYLD_INSERT_LIBRARIES $PWD/Hax.dylib command
6. Opened Install macOS Beta.app file
7. Selected Macintosh HD as installation disk

The installer automatically rebooted my mac (Macbook Pro 15, Mid 2010) and booted the installer partition, but when Apple logo shows up the system crashes and reboots, crashing again.

What can I do?

(I'm running macOs Catalina now)

Arrandale cpu i5 (and I guess i7 too) on BigSur either USB Installer or installation causes a kernel panic at early boot due to:

AppleACPICPU , AppleACPIPlatform and maybe any other *ACPI* related kext

Arrandale cpu till Catalina can use the stock telemetry.plugin so it's not the case to remove it.

Currently Arrandale cpu are not able to boot BigSur kernel, while instead a Penryn Core2Duo cpu can.

Not totally sure if this early kernel panic after BigSur kernel initialization is related also to the Dual GPUs (and so AGDC, AGPM, AGDP plugins and so on), but I'd exclude, rather I guess it's the Arrandale architecture the issue for booting BigSur.
 
Last edited:

niccoloboano

macrumors newbie
Jun 26, 2020
6
11
Arrandale cpu i5 (and I guess i7 too) on BigSur either USB Installer or installation causes a kernel panic at early boot due to:

AppleACPICPU , AppleACPIPlatform and maybe any other *ACPI* related kext

Arrandale cpu till Catalina can use the stock telemetry.plugin so it's not the case to remove it.

Currently Arrandale cpu are not able to boot BigSur kernel, while instead a Penryn Core2Duo cpu can.

Not totally sure if this early kernel panic after BigSur kernel initialization is related also to the Dual GPUs, but I'd exclude, rather I guess it's the Arrandale architecture the issue for booting BigSur.
So there's no method to boot Big Sur from my computer or there are some fixes?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.