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...

[gbdoc]

This may not resolve everyone’s problems, but it’s important to know that for clones to be bootable on silicon Macs (I have an M2 MBAir/Sonoma) you absolutely need to have a very fast external drive. IME, HDD won’t do the job, you need an SSD. I got an OWC envoy express thunderbolt 3 (usb-c) and fitted it out with a 1 TB OWC Aura P12 Pro. Now my SD! clones are bootable with no hassle. I did the same for a friend with the same machine. I’m not too tech-savvy, so I don’t know whether there might be other drives fast enough, but thunderbolt 3 surely is. I would suggest, Dave, that you make this very clear in your instructions.

[dnanian]

In general, I suggest USB-C/3 or later SSDs, yes. Slower drives *can* work, though...and remember, a drive does not have to be bootable to be restorable...

[Gusto5]

Originally Posted by dnanian

...remember, a drive does not have to be bootable to be restorable...

Could you expand on your statement quoted above?
I have always assumed if I can't boot up from a backup then I can't re-install the backup over an existing internal boot drive that has become perhaps corrupted. Having a bootable clone makes the process so fast and generally trouble free. If I backup my M3 MBP14 to an HDD, and it isn't bootable how do I restore my MBP from the non bootable HDD?

[dnanian]

The OS cannot be copied into an Apple silicon Mac - only out. It always has to be either installed (from Recovery) or a recovery image needs to be installed by Configurator (which may become easier someday with firmware support).

As such, all full restores on Apple silicon are done by clean installing the OS, then -- when prompted -- selecting the backup to restore. That backup can either be a "full" bootable copy with an OS, or it can be a "Backup - all files" with "Smart Update" - basically, a full copy of the Data volume, without an OS (since the OS doesn't get restored anyway).

[Gusto5]

Originally Posted by dnanian

In general, I suggest USB-C/3 or later SSDs, yes. Slower drives *can* work,.

From the first part of your previous answer, quoted above, you appear to recommend using a SSD over a HDD as the backup hard drive for an Apple silicon Mac. If using a SSD or a HDD result in the same non bootable backup why do you suggest a SSD is a better choice for a backup hard drive, beyond file copy speed/time?

[gbdoc]

Just a pleasing update:

Just updated to Sonoma 14.3, cloned it to my external SSD, and it*s still bootable, problem-free.