tl;dr
SuperDuper v3.10 B3 is now available, with various improvements, including significantly improved bootabilty for users who previously had problems. A download is available at the bottom of this post.
Or you can continue to read...
The Story
As you know, since Big Sur or so, external boot has become more difficult. Apple stopped allowing 3rd parties to copy the OS for security reasons, and enhanced asr, a command-line tool, so that it could be used to copy the OS.
Since Apple controls both the OS and asr, and can verify that chain of trust, this ensures that OS access remains secure and read-only. Combining that with various forms of cryptographic security and server-side checks allows detection of a modified OS after the fact.
Everyone who makes "bootable copies" of macOS above the sector level, since Big Sur, must use asr to make the copy.
Worthy Goals
The intention here, of course, is a good one. None of us want our system to get hacked (put your hand down, you in the back).
But we do want to be able to maintain a reliable, testable backup strategy, and many of us want to be able to run from an external drive both when diagnosing issues, to roll back some non-OS changes, or when time is of the essence, and we need to get back up and running immediately—not after doing a multi-hour restoration.
Changes
In Ventura, Apple made some new changes to allow for rapid security responses. Part of the previously described security setup—Cryptexes—also started showing up where asr no longer copied it: a new location in Preboot.
What was (and is) weird about this change requires a little discussion of how Preboot is laid out.
Since a given APFS container can hold multiple copies of the OS, Preboot and Recovery have folder structures that include UUIDs corresponding to the volume that "owns" that part of their shared volumes in the group. Inside that UUID-named folder are the files that "pair" with the system you're trying to boot.
In Ventura and later, for some reason, one set of Cryptexes also appear outside this structure, at the top of Preboot.
Wait, What?
This is quite...strange. If the Cryptexes folder isn't inside the appropriate UUID-based folder, then it's shared between all of them. And if there are different systems in the same container, the Cryptexes would also be different. So they can't be shared. (And, indeed, each Preboot sub volume also has its own Cryptexes...which we expected to be sufficient.)
What We Thought
On top of that, asr didn't (and doesn't) copy the Cryptexes. So we thought "well, there's got to be a reason for this; they're probably generating and grafting the right folder during the boot process". And, indeed, that's what it does.
Or seems to do.
Sometimes.
The Theory, by A. Elk (Miss)
Here's the thing. For many users, the straight up copy, as above, seems to work just fine. Internally, on some of our test systems, backups boot as expected without trouble. Others, like my own development system, do not do so consistently.
The difference seems to have to do with what's installed. Maybe.
On our test systems, we're using a straight install of macOS. On my development system, which has been carried forward for years, I have some apps that require 3rd party kernel extensions.
Those extensions are necessary for some things I run, but they seem to interfere with boot. On the "plain" systems, you don't even need the "root level" Cryptexes folder and yet it boots (using, I assume, the existing Cryptexes inside the UUID-based folder). But on others, you absolutely do need them at the top of Preboot, or you get a kernel panic.
A kernel panic we see too often, and that we've reported to The Powers That Be. And we've been waiting, for quite a while, for a fix.
That's nice. What now?
So, what have we done? We've decided to not wait for asr to be fixed by TBTB. And we don't want to continue to tell people to install the OS over the backup (which lets Apple fix the issue).
Instead, to improve bootability, and save user's time (not to mention sanity), we're decided to copy over the Cryptexes to the root of Preboot.
This shouldn't be necessary...but it is. Sometimes. And in the cases where it isn't, it doesn't hurt anything.
Beta 3!
With no further ado, here's Beta 3 of SuperDuper! v3.10. There are various other improvements in this beta (including much faster Diagnostics collection; see the Release Notes), with more to come in future Beta releases.
As always, if you install this Beta, subsequent v3.10 Beta releases will automatically be offered via the normal update mechanism.
When the final v3.10 comes out, you will receive that, and then you'll be on the non-Beta release cycle again...unless you subsequently install a later Beta.
Enjoy!
