{"id":47221,"date":"2025-03-27T16:08:41","date_gmt":"2025-03-27T20:08:41","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=47221"},"modified":"2025-04-10T15:27:48","modified_gmt":"2025-04-10T19:27:48","slug":"superduper-3-10-beta-works-around-asr-bug","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/03\/27\/superduper-3-10-beta-works-around-asr-bug\/","title":{"rendered":"SuperDuper 3.10 Beta Works Around asr Bug"},"content":{"rendered":"

Dave Nanian<\/a> (Mastodon<\/a>):<\/p>\n

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.<\/p>

In Ventura and later, for some reason, one set of Cryptexes also<\/strong> appear outside<\/strong> this structure, at the top of Preboot.<\/p>

[…]<\/p>

On top of that, asr<\/code> 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.<\/p>\n<\/blockquote>\n

But only sometimes.<\/p>\n

\n

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.<\/p>

[…]<\/p>

We’ve decided to not wait for asr<\/code> to be fixed by TBTB. […] 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.<\/p><\/blockquote>\n\n

Previously:<\/p>\n