Until recently, the only reliable way to create an external bootable disk on an M1 Mac has been to install Big Sur on it, either in recoveryOS or using the full Installer app. The latest version 6 of Carbon Copy Cloner can now use macOS tools to make a full clone of a Big Sur System Volume Group, although this is no longer recommended. This article explores how successful making full clones can be, specifically whether you can use them to assemble a multi-boot disk containing multiple versions of Big Sur.
Developers, researchers and system administrators often keep a collection of previous bootable systems so they can go back and run tests under those older versions, for instance when someone reports a bug which can’t be reproduced in the current macOS. M1 Macs pose several problems for doing this:
- Full installers for older versions of Big Sur don’t work when run in a later release. This currently appears insoluble, making it essential to create each bootable system when that version of Big Sur is still current.
- M1 Macs can’t boot from an older release of Big Sur without setting that bootable volume group to Reduced Security using Startup Security Utility in recoveryOS.
- Some external disks can only boot when physically connected in certain ways, e.g. SATA/USB-C disks may need to be connected to a USB-A port rather than USB-C.
The alternative is to keep old versions in Virtual Machines in Parallels Desktop.
I prepared my external SATA/USB-C SSD by connecting it to a USB-A port on my M1 Mac mini, which I know works reliably for booting, then using Disk Utility to divide it into a series of 100 GB containers, each of which will contain a different version of Big Sur.
If you then make a regular clone to one of those containers from a bootable volume group using Carbon Copy Cloner 6, the default is to omit the System volume. You could perhaps then install Big Sur into that volume group, but I opted to use what CCC terms its Legacy Bootable Backup option.
Select this by clicking on the destination volume and choosing the Legacy Bootable Backup Assistant…
CCC then explains the implications of this option. Click on the button to Allow CCC to erase [volume name].
When you then click on the button to Start that full clone backup, there are subtle differences in what’s shown in CCC’s window.
I made two full clones to different containers on my external SSD: one was from my internal SSD, the other from a Thunderbolt 3 external disk which already has a fully functional and bootable copy of Big Sur 11.3.1 installed on it. Both full clones were reported as being successful, and were very quick indeed: almost 160 GB was copied from my internal SSD in just over 15 minutes; amost 22 GB was copied from my external SSD in just over 2 minutes.
Once the full clones were ready, I checked the Startup Disk pane, which only offered the copy of the external SSD as an alternative for booting. The copy of the internal SSD wasn’t recognised as being available, despite it being successfully mounted.
Attempting to boot from the copy of the external SSD brought the normal request for an authorised user, and was then successful following two restarts. There, the Startup Disk pane offered the clone of the internal SSD as being available to restart from, so I tried that, and it worked.
When booted from the clone of the internal SSD, though, several things didn’t appear quite right. For a start, it was engaged in performing deep signature checks on all the apps installed, including Xcode, which takes a very long time. But most prominent and alarming was the fact that the internal SSD was no longer included in the list in the Startup Disk pane, despite being mounted and accessible.
Concerned that I might have to resort to restoring my M1 Mac mini in DFU mode, I tried restarting it from the other external boot volume group. This took some strange negotiations with recoveryOS before I was finally offered Macintosh HD as a boot disk, and successfully restored order.
Once back on the internal SSD, I checked the status of boot volumes using
bputil -d, which listed all three as being available and apparently correctly configured, with unique volume group UUIDs. No security settings had been changed, but the clone of the internal SSD still wasn’t offered in the Startup Disk pane.
While full cloning does work in CCC version 6, it’s hard to see what use it is in reality. Use it to clone your M1 Mac’s internal SSD to an external container, and you apparently can’t boot from that directly, and it doesn’t appear to work entirely normally either. Where full cloning does work best is in making a faithful copy of a bootable external disk, but there is little or no advantage over using the full Installer to create a fresh copy of macOS. Use cases in which full cloning does appear valuable are marginal – for example where you already have an external disk with that version of macOS installed, and want to copy that to another external disk.
On M1 Macs:
- Carbon Copy Cloner 6 can now create full clones of bootable system volume groups in containers on an external disk;
- making a full clone of the internal SSD works, but it can’t readily be booted, and is strange in other ways too. Unless you have a compelling reason for doing so, avoid this;
- booting from a full clone of the internal SSD is to be avoided;
- making a full clone of an external SSD works, but has little or no advantage over performing a full install of macOS on that disk.
For the great majority of users, bootable clones are a thing of the past. If they play any role in your current workflows or recovery plans, you need to reconsider those in the light of their limitations.