Old SuperDuper for Big Sur
Dave Nanian (Hacker News, tweet):
To accomplish this, use an old version of SuperDuper—specifically, v3.2.5—to copy the Data volume, which is shown in the older version!
v3.2.5 is well tested, having been on the market for quite some time, and is reliable. So we don’t have to worry about doing a broad beta test of a partially complete new release. It’s already tested, and I’ve been busy doing the additional testing necessary to prove it works on Big Sur.
Again, this will make a copy of the data that you need to preserve your stuff, both Applications and Data, while leaving the Sealed System Volume alone.
And it’s a valid source for “restore” during a clean install or migration! So restoration is easy and fast should it become necessary.
[…]
M1 Macs can’t be copied in a way that makes them bootable. Bare metal recovery on an M1 Mac isn’t possible, since they depend on the contents of their internal drive even when booting externally. And the tools required to make bootable copies of Intel Macs are limited, often fail, and produce inscrutable and undocumented diagnostics when they do.
Previously:
- macOS 11.2 Beta 2 Adds Full Custom Kernel Support
- No More Big Sur Internet Recovery
- Booting an M1 Mac From an External Disk
- Reviving or Restoring a Mac With Apple Silicon
- Waiting to Update to Big Sur
- macOS Big Sur 11.0.1 Release Candidate
- Carbon Copy Cloner 5.1.22
- Awaiting SuperDuper for Big Sur
- Boot and Recovery Mode on Apple Silicon Macs
10 Comments RSS · Twitter
"Progress" these days seems to involve less repairable, more brickable, and shorter lasting devices.
God, it's all getting to be so damned hard. This is not what I signed up for.
Not that migrating from Intel Mojave to M1 Big Sur is necessarily on the agenda, except perhaps experimentally--I'll probably be doing a clean install anyway. But, how would I do it? Is Migration Assistant during the initial setup essentially where it's at? Target Disk mode no longer supports cross-installs, and you can't boot an M1 from an empty internal disk in any case. So is there any way, besides Migration Assistant, to move an external installation onto the internal disk?
One would hope future Macs would work differently. And since now there is only macOS booting from bare hardware (not EFI or T2 firmware), likely it can be improved.
@Sebby
With the caveat that I don't have an M1 Mac, this is my understanding from reading the technical details provided by Howard Oakley…
https://eclecticlight.co/2021/01/14/m1-macs-radically-change-boot-and-recovery/
You can boot an M1 from an 'empty' internal disk. Although physically the boot manager is also stored on the internal & integral SSD, it's best thought of as firmware separate from the internal disk, as with the boot manager on Intel Macs. So if you wanted to migrate from a Mojave Mac to a new M1 Mac without using Migration Assistant, you could (again, in theory, I've not tried this):
(1) Boot into the recovery tools, erase the internal disk, attach the Mojave Mac in target disk mode, and use Disk Utility (in the recovery tools ) to clone it to the internal drive. You'd then need to run the Big Sur installer (from recovery tools) on the internal disk.
or, alternately
(2) Boot into the recovery tools, erase the internal disk. Then use the "Share Disk" utility in the recovery tools to share the (blank) internal drive with your old Mojave Mac. From the Mojave Mac, use Carbon Copy Cloner to clone the Mojave internal drive to the M1 Mac's shared internal drive. You will then need to exit the sharing and run the Big Sur installer from the recovery tools on the M1 Mac's internal disk.
I'm not sure it would be worth the hassle to use either of these methods. Migration Assistant is works well and is generally the most straightforward method for migrating regardless of Mac type.
Is there some reason one should avoid Migration Assistant?
It has worked well for me for over a decade, well over a dozen successful migrations between my own work and personal machines and with family and friends. In the early days there were definitely issues, but those memories have faded.
It seems we’re creating some headaches by trying to avoid the obvious solution.
@Simon Migration Assistant is fine, but it’s not as fast or flexible as SuperDuper. It also seems to require more work afterwards, e.g. signing into services.
Looks like I'll be doing some risky experiments. At the very least there's a time window after erasing the disk but before running the installer during which the only way the Mac can be restored if it all goes wrong is using DFU. Fortunately, I have the hardware (cable, USB-C-equipped Mac) to do it. Unfortunately, it runs Mojave ...
@Jolin: option 1 may be plausible, with above caveat. But option 2 is impossible because the internal disk is now represented to the other Mac as an SMB file share and not a block device.
@Simon: it may very well be that Migration Assistant is adequate nowadays (I haven't tried it in at least a few years), although oddly, even though it seems to use the same logic as the actual installation process for deciding how to perform the upgrade, IME it has been rather less thorough post-installation at preserving certain preferences. I should give it another go though--hopefully it's got better and maybe it's now as good as the installer itself.
Thanks for replies.
@Sebby: regarding option 2, that is why I said you'd need to use Carbon Copy Cloner: It can write to SMB file shares. I realise it can't create a bootable restore this way, which is why you'd need to subsequently run the MacOS installer. I agree this is not an ideal option as there could be permission and other metadata issues with the files restored over SMB. I would certainly never use this method (I think Migration Assistant would be far superior), but from a theoretical standpoint, I think it should have a chance of working at a basic level.
