macOS 11 Big Sur on Unsupported Macs Thread

[Jose C. Salazar]

Anyone else with this bug? When I choose BS wallpapers I get Catalina ones 😥

 

[ScreenSavers]

Anyone else with this bug? When I choose BS wallpapers I get Catalina ones

Yep me too. Even on a supported Mac.

 

[PiggyGamingYT3]

Here's a video I made that shows how macOS Big Sur currently runs on a MacBookPro 8,1.

Also, Has anyone figured out graphics acceleration on an Intel HD Graphics 3000?

 

[Paulo Andrade]

Macbook Air 2015 without Wi-Fi, can someone help me?

 

[Pendleton115]

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

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

 

[TimothyR734]

I made these for those who have usb Big Sur installers

 

[ASentientBot]

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!

 

[iMac-iPad]

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!

 

[jbapps]

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]

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]

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]

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]

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.

GitHub - barrykn/big-sur-micropatcher: A primitive USB patcher for installing macOS Big Sur on unsupported Macs

A primitive USB patcher for installing macOS Big Sur on unsupported Macs - barrykn/big-sur-micropatcher

github.com

 

[nandor690]

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

 

[nandor690]

 

[niccoloboano]

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]

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]

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"

 

[niccoloboano]

If you're getting "crossed circle", then:

sudo nvram boot-args="-no_compat_check"

No, there is no crossed circle, I can see the Apple logo for 2/3 seconds, but after this time the installer crashes

 

[libneko]

No, there is no crossed circle, I can see the Apple logo for 2/3 seconds, but after this time the installer crashes

Penryn?

 

[Barry K. Nathan]

Penryn?

In niccoloboano's case (MBP 15" 2010) it's Arrandale, not Penryn, but either way it's pre-Sandy Bridge, so I wouldn't be surprised if it's the telemetry plugin.

 

[alphascorp]

something kind of stupid. But I kinda hope that have a ssd pic for ssd drive
View attachment 927839

Hello @nandor690
You mean SSD icons like this?

 

[jackluke]

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.

 

[niccoloboano]

Those are my specs

 

[niccoloboano]

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?