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!
www.reddit.com
I can't find any 
github.com