I try to always do the “right thing”.
What does that mean? It means “only use documented calls”. It means “work around problems using normal processes, but not things that aren’t documented”.
It means that even when I know why something isn’t working, if there’s no documented fix…well, I don’t do that…unless I absolutely have to.
The past is prologue
I’ve been in this situation before. When Catalina was released, and the whole boot process was different, I spent all summer figuring out how to make a bootable copy: volume groups, roles, firmlinks, and so much time going through verbose boot logs (literally taking movies of them, since they went by so fast, and single stepping through) until I figured out the issue.
It was rough (but also fun).
And, obviously, none of that was documented. But I did it anyway…to benefit the users of SuperDuper.
A new dilemma
I’ve known for a while why drives aren’t showing up as bootable under Golden Gate. And it’s been reported as a bug, as mentioned in my previous blog posts. But I didn’t want to release the workaround I had, because it relies on something undocumented.
Specifically, one…single…bit.
Cat leaves bag
I had hoped that the Terminal command I provided in a previous post would be sufficient until an official fix came out, but it’s just too difficult for “regular” people to execute…and the last thing I want to do is put people in a state of panic when they’re trying to recover from a failure.
But the tipping point was that, yesterday, a beta of 27.2 (!) was released, without a fix. Which means I don’t know when, or if, a fix is going to be implemented.
The thing is, the copy is actually fine (as proven by the original workaround & “proof of life” screenshot). The real issue is that Golden Gate’s startup drive code is filtering its selections by looking for something that neither asr nor bless is setting. In fact, they’ve never set this value, which is why, under Golden Gate, your previously bootable backups look like they’re no longer bootable.
With those factors in mind, I’ve reversed course and have decided to go ahead and work around the issue as safely as I can.
Note that this fix will automatically disable itself when the real fix is (hopefully) released. In all the internal testing that I’ve done during the Golden Gate Beta, it’s worked fine and seems perfectly safe.
What you need to do (nothing)
The fix will be applied automatically when you make your next backup, even if it’s a Smart Update, under all macOS versions supported by SuperDuper 4. Other than that, there’s nothing special you need to do.
With all that said,
(or, better, just use the internal updater).
Thanks, as always, for using SuperDuper, and for your patience.