Creating Bootable Clone from Apple Silicon Mac

[mschmitt]

I've been trying to create a bootable clone from a 2023 MacBook Pro (M2 Pro chip), and failing. I'm wondering if these data points track with other's experiences.

I set up the MBP by using the Migration Assistant to copy from the old MacBook Pro, i.e. I didn't use SuperDuper!. Then I tried to create the clone, using the same 1TB HDD partition that I was using before:

1. Used SD erase-then-copy to clone the Ventura 13.5.2 system volume and the data volume to the HDD, i.e. via asr.
2. Tried to boot. It failed early on with a kernel panic: Library /usr/lib/libSystem.B.dylib not loaded
3. Tried everything I could think of to boot: ran First Aid, Safe mode, re-cloned, different USB adapter, different port, USB 2.0 cable, etc. All attempts ended the same.
4. To rule out the hardware, I used the full Ventura 13.5.2 installer to install onto the backup drive, overlaying what was there before (i.e. not an erase first). And then...
5. That booted with no errors! So it isn't the hardware! There's something different in what asr did?
6. But, I couldn't turn on FileVault; clicking the "Turn On" button had no effect. I think this was because for some reason, my userid didn't have a Secure Token (it was reading as "DISABLED").
7. I thought, better make sure I can boot a second time. Surely if it worked the first time it would work again. But just to make sure...
8. Nope, can't boot it again. Now it gets to the login prompt, but after that, panics with a resource busy error: "registry root held busy".

So there's at least three problems going on with cloning from Apple Silicon (or Ventura?) to an external HDD:

• asr did not produce a bootable drive
• Installing Ventura on top of the drive created by asr made it bootable, but without the secure token associated with my userid. (I think it may have created a new id with the secure token, but haven't confirmed that.)
• Can't boot after the initial boot.

And I see some clues that the last problem is really due to an assumption in the boot code that if you're on Apple Silicon, then you must be on a SDD, and therefore it doesn't need to adjust timeouts to allow for a slower HDD. So, it appears that it is timing out in the code that is waiting for extensions to load.

While it is true that the internal drive on Apple Silicon will always be a SDD, the websites I've consulted said that Apple Silicon Macs can still boot from HDD. Now I'm thinking that's only if you're lucky and your HDD is fast enough that you don't get caught by the timeouts.

[dnanian]

In some cases, asr or the OS is not rebuilding the dyld cache, which is why you're getting the boot panic. It should be...but sometimes isn't. We're hoping they're going to fix it.

The secure token should get created automatically when the password is set for the user...and the OS is going to import the password (and, one would expect, the token) when the OS is reinstalled - it's just a basic install. Again - Apple has continued to work through bugs in this stuff over time, but it's quite obviously not a priority for them.

I've never seen "registry root held busy"...and I don't think any of this has to do with HDD or SSD (but do, generally, recommend SSD these days).

Remember: on Apple silicon, you cannot copy the OS into the system at all - only out. As such, a full restore is going to be preceded by a clean OS install internally, followed by selecting 'restore' during first boot.

When you do that, the secure token is properly created by the process...so even if the external boot doesn't work, the restoration will be successful (assuming the backup is a "Backup - all files", with either Erase, then copy or Smart Update...and it doesn't even need an OS on the backup.

[mschmitt]

I saw the code for the registry error here, preceded by the comment:

PHP Code:

     * On kasan kernels, everything takes longer, so double the number of
     * timeout extensions. This should help with issues like 41259215
     * where WindowServer was timing out waiting for kextd to get all the
     * kasan kexts loaded and started.
     *
     * On legacy/x86 systems give a bit more time since we may be
     * booting from a HDD. 


The problem with not having the secure token on the clone is that I can't encrypt the data with File Vault. I don't like to have external disks lying around unencrypted.

I think I might have been able to repair that, but now I can't because it doesn't boot anymore.

I also think the secure token problem was created because I installed macOS over the cloned System.

It seems the use cases for bootable clones are reduced down to two now:

• Reinstall OS from clone <- can't anymore
• Boot when the internal SSD is completely toast <- can't anymore
• Boot to check things out on the data as it was at the time of the clone
• Boot when something goes catastrophically wrong with the data on the internal drive

[dnanian]

Well, that certainly seems like an issue with the HDD, yes. A fast SSD (they're not that expensive - 1TB is less than $70 these days) should resolve that issue.

With regard to encryption - my general feeling is that if you're not traveling with the backup, it's incredibly unlikely that someone breaking into your house is doing so to get your backup drive...and if they are, it's *quite* likely that information around your house, on your desk, in your trash, etc. is more likely to be 'useful'.

Note, too, that sensitive information like your keychain is encrypted anyway... so getting anything "useful" off the backup, to a casual thief, is unlikely.

Beyond that, encrypting the backup means data recovery, should you need to perform it, becomes nearly impossible. Given a backup is supposed to be a safety measure, I endeavor to ensure it's as safe as possible in a typical home setup. (I'm talking about local backups here - not 'cloud'.)

I know we're all the stars of our own spy movie, but in general no one really cares about your backup...except you. Maximizing its usefulness is key.

Finally, part of the reason you're making a "bootable style" backup is to ensure you have a backup that's redundant, and simpler, should the more complex schemes like Time Machine become corrupt or fail in some way. The more backups using different devices and software, the better.

That's why I advice three levels of protection in my blog post - SuperDuper, Time Machine and Cloud. Between the three, it's quite unlikely you'll lose data...and the point is to avoid exactly that.

Installing over a system (a basic OS reinstall) really shiouldn't whack your secure token...it's something users do all the time, leaving aside the backup.

[mschmitt]

I missed another reason for a bootable backup: to have a platform that can run macOS installers on (I've had little luck with the USB flash drive installers), and to have a platform for pushing a clone of data back to the other machine.

I do keep all three types of backups, plus more. For my main machine, I have:

• Time Machine
• Secondary Time Machine, connected once a month
• SuperDuper! bootable clone, updated weekly
• Second SuperDuper! bootable clone, updated monthly
• Backup to cloud via Arq, holding data back for 5 years
• 2 SuperDuper! data-only copies, backed up monthly (alternately), with one stored offsite. The backup date is 2 weeks later than the other monthly backups.

Apparently I have a FOLD (Fear of Losing Data).

I think it dates back to when I had a great scheme for using Retrospect to backup my Mac to DDS tape. Everything was backed up weekly, rotating between 3 tapes, where once a month one of them was sent offsite and the 13th oldest tape added back in. So I was covered, completely.

And then my PowerMac couldn't start up anymore. So I bought a new iMac.

That's when I discovered I couldn't connect my SCSI DDS tape drive to the new iMac, which had no SCSI ports!

(I did mange to get the PowerMac to boot one last time and grab all the data off it. But I swore NEVER AGAIN will I be without a means to recover my data.)

[dnanian]

I was very sad to send my old Sony DAT autoloader to the junkpile in the sky...

[mschmitt]

Update: I got an external SSD and tried again to create a bootable clone from a M2 MacBook Pro running Ventura 13.6.2.

First attempt: SuperDuper erase-then-clone (ASR): same problem where ASR didn't update the dyld cache.

2nd attempt: Update Ventura on the 1st clone, using the full Ventura installer. This didn't work because Apple hasn't posted 13.6.2 yet to the App Store, and you can't downgrade. So, putting this idea aside until there's an App Store version >= what's on the source drive.

3rd attempt: While waiting for above, tried erasing the drive, installing Ventura 13.6.1 using the full installer, then Smart Update over it.

I know that's not recommended but I figured won't hurt to try it.

What happened is when I try to use System Settings to start up from the clone, it asks me to authorize users, then it asks me to select an owner, then to authorize users, then to select an owner, over and over. Is this something you've run into? Google returns no hits on that problem. (Note that I didn't get into that loop in attempt 1.)

(Planned 4th attempt will be to erase, use full Ventura installer, boot from that, and then migrate the data from the internal SSD. And hope that after doing that, it will continue to be a bootable clone after a later Smart Update puts the data back 100% in sync with the source.)

[dnanian]

That's not going to work - the user info held in the hidden volumes won't match what's in the data. You'd have to migrate for that...or you might be able to force a sync.

Can't you install your Ventura version from Recovery? That's the way to do it, typically, not by using an installer.

[mschmitt]

(Talking about idea #2: erase-then-copy followed by a macOS update to get the dyld cache fixed...)

The macOS downgrade issue is a moot point now since Apple posted Ventura 13.6.3 to the App Store. But I'd think I'd better apply the 13.6.3 update to the internal drive first, in case running the 13.6.3 full installer also does a firmware update.

What do you mean by "force a sync"?

I'll try the reinstall from macOS Recovery.

Note: based on previous experience, I'm not sure this will even work. That is, I think it will make the clone bootable, but then won't allow turning on FileVault.

[mschmitt]

Did another erase-then-copy, tried to startup from it, but it goes through the same authorize users, set owner loop as previously described. Which is weird, since this worked the first time I tried an erase-then-copy.

Do I need to completely erase (repartition) the drive to clear out whatever hidden data is there? What I did was erase the APFS container in that partition, changing it to HFS+, then erase that and create as APFS.

[dnanian]

There's no need to change things to HFS+. I would erase the whole drive, from the hardware (top), and format as APFS from the get-go.

[greengrass]

FWIW I had no problem creating a bootable clone on an m3 iMac. I created an APFS volume on an external SSD, then did an erase and copy all files with SD. Upon completion, I booted to the volume, turned on FileVault, let it run for a while and then booted back to the internal drive.

[mschmitt]

Same authorize/owner loop as before.

I did this:

1. Erased entire drive (i.e. reparitiioned), as APFS "Untilted"
2. Renamed to Backup T7
3. SuperDuper! erase-then-copy from internal booted SSD (Ventura 13.6.2)
4. System Settings > General > Startup Disk
5. Select Backup T7
6. TouchID to unlock system settings
7. "Startup Disk needs to authenticate to continue" - entered password
8. Restart...
9. Are you sure? Restart
10. "This volume does not have any authorized users for this computer". Authorize users...
11. Authorize my main account, entered password
12. Authorize emergency account, entered password
13. Continue
14. "Please enter the password for the user <me>" - entered
15. "Select an owner" - selected me on the boot drive, Authorize
16. "Please enter the password for the user <me>" - entered
17. "This volume does not have any authorized users for this computer".
18. repeats steps 10 - 16 forever

[mschmitt]

Originally Posted by greengrass

FWIW I had no problem creating a bootable clone on an m3 iMac. I created an APFS volume on an external SSD, then did an erase and copy all files with SD. Upon completion, I booted to the volume, turned on FileVault, let it run for a while and then booted back to the internal drive.

I'm hitting two main issues right now:

• First time I tried it, it crashed on the restart, because asr didn't rebuild the dyld cache. We've seen this before.
• Now I can't even get that far. It won't let me complete the authorize users/set owner process.

When you did it, did you try to restart by selecting in the System Settings? Or did you just reboot and hold the power button to choose a different drive?

Did it ask you to authorize a user and select an owner?

[dnanian]

Maybe your users on the internal drive are bad? You may want to consider reinstalling the OS to the internal (pretty basic and non-destructive) from Recovery.