Major system upgrades always remind me of visiting the dentist to have a tooth extracted: you know it’s unlikely to be entirely pleasant, and if you’re unlucky it’ll end up as a bloody mess. Having just completed three quite different upgrades to macOS 11.0.1, you may find my experience in the surgery useful for when it’s your turn.
If you’re upgrading from 10.15.7 or a beta-release of 11.0, this is one of the smoothest that I have experienced for some years.
If you’ve already decided that you will upgrade soon, and all your key apps and peripherals are supported, there’s no reason to delay any further. All three of my active Macs, including my production system, are now running Big Sur.
Apple Silicon Macs
These currently ship with macOS 11.0 pre-installed, and need to be updated to 11.0.1 before you start using them for anything serious. What I do in this situation (and will be doing with my M1 Macs when they arrive early next week) is to set the Mac up with a user account with the same name, short name and password as the user account I’m going to migrate from. I then decline to migrate when initally setting the new Mac up, and let it create an empty account.
I then install the pending update, and only when I’m happy that’s installed do I use Migration Assistant (in /Applications/Utilities) to migrate from the other system. Once you’ve done that, you can perform your post-installation checks as below.
Apple Silicon Macs also require a different technique for reinstalling macOS using Apple Configurator 2.
Stop! Macs with problems
If you’re intending to upgrade a MacBook Pro 13-inch late-2013 or mid-2014 (model MacBookPro11,1), then wait a while before doing so. Although many have upgraded without problems, a few haven’t coped well and have become ‘bricked’, probably as the result of a failed firmware update. I recommend that you postpone upgrading until this has been fully resolved. As of yesterday, 19 November, Apple released a new version of macOS 11.0.1, build 20B50, which now excludes these models from upgrading to Big Sur, while it investigates what is going wrong.
Although some officially unsupported Macs can be upgraded, that’s complex and not something that I have any experience of. If you want to try that, I wish you every success.
Presuming that you’ve already worked through my previous articles about preparing to upgrade to Big Sur, your final steps are to ensure that all your main apps are fully updated, satisfy yourself that your Mac’s boot disk is in good health (maybe with a quick First Aid in Disk Utility), then making those last complete backups.
Last minute app updates are common and numerous. They’re worth checking, as the version which you updated to a couple of days ago, which claimed to be compatible with Big Sur, could suffer a crashing bug, which might make it hard to update once your Mac’s running Big Sur.
Before you even start downloading the update, step through in your mind what you’d do if your Mac had a firmware problem – do you have another Mac, Apple Configurator 2, and know how to use it to recover your Mac? What if the problems you encounter are so severe that you decide to revert to your previous version of macOS? Don’t get obsessed with these, but cover your rear in case you need to retreat.
Once your Mac has downloaded it and the installer app opens, I make at least two copies of the Install macOS Big Sur app before allowing it to continue. By default, that app deletes itself once the installation is complete. Making copies lets you perform additional installations and upgrades without having to download it again.
The upgrade itself is likely to take at least an hour, once it has completed downloading, and you should allow two hours or longer, together with time to resolve any problems arising from the upgrade. It’s best to start any major upgrade early in a day when you have flexibility in what you have to do later. Don’t try to squeeze it into a tight two-hour slot, as you can guarantee it will overrun, and you’ll panic, or have to shut down and come back another day.
Once the upgrade has started and checked itself, performed unpacking, and generally fiddled around for 15 minutes or so, it should begin by updating your Mac’s firmware. On T2 Macs, this is the phase during which the Mac plays dead, as it powers down the whole of its Intel system to update the T2 firmware, leaving you staring anxiously at a black screen and wondering whether it has been bricked. It’s best to go and do something else for a few minutes; when you return, it should have powered up the Intel side again and be progressinng the rest of the installation.
After the firmware update, the installer creates Big Sur’s new System volume, which takes much the same time as with other full installs. But the installer’s job isn’t finished with that: new for Big Sur is its Sealed System Volume (SSV). To seal the system, the installer then has to calculate cryptographic hashes for everything on the System volume in a tree, ending up with the top-level Seal “to rule them all”. It then checks that with Apple’s official hash for the whole SSV. That’s what the installer is spending much of those last ten minutes doing.
With the System volume sealed, the installer makes a snapshot of it, makes the volume read-only (and protected by SIP), then unmounts the volume and mounts that snapshot, before it can boot from it. The great advantage at this stage is that the installation is checked automatically: if anything has been corrupted or gone wrong during the installation, the Seal won’t match that prescribed by Apple, and you’ll be invited to start all over again. Every System volume created in this way should be identical and perfect.
Big Sur brings major changes to Time Machine which you should already have incorporated into your planning. I chose to abandon my previous Time Machine backups, as they were limited, and I have two other backup systems using Carbon Copy Cloner and ChronoSync. With the preferred option in Big Sur of backing up to APFS, I was starting from scratch.
I therefore turned Time Machine backups off before starting installation, then once my Mac was running Big Sur, I formatted my old backup SSD in APFS, and set that as the new backup store. If you’re sticking with backing up to HFS+, I still recommend turning backups off before the installation, and manually turning them back on afterwards.
As soon as your Mac is running again, check the version of macOS installed, for example in System Information. That should read
macOS 11.0.1 (20B29)
or later (latest is 20B50). If it reads build number 20B28 or earlier, you will need to run Software Update to download the update to take it up to the current version before doing anything else: see below about the perils of upgrading Macs which have been running betas.
Once you’re happy with the version of macOS, check whether it needs any security or other updates. Inevitably, this is when I run my own free utility SilentKnight. The current upgrades for Big Sur will leave your Mac running MRT 1.69.2, so you need to ensure that it’s upgraded back to the current version, 1.72.
The story with Gatekeeper versions is more complicated. As with the other security data files, these aren’t stored on the sealed System volume, but on the Data volume. If you perform a completely clean install with a fresh Data volume, then the version of Gatekeeper you will get is an old default one supplied with the Big Sur installer. If you upgrade an existing macOS installation, with its Data volume, then Big Sur will inherit the last version of the Gatekeeper database which was installed on that, typically version 181. There’s no way to force any update from an older version, though. In any case, that database is unused in Catalina and later, so an old version doesn’t matter.
Because, for the moment, Macs upgraded to Big Sur will have new firmware installed, but those remaining with Catalina and Mojave won’t, the database used by SilentKnight continues to quote versions for the older macOS. However, SilentKnight doesn’t complain when you have newer firmware. I expect that Apple will bring all three supported versions of macOS in line in the coming weeks, with Security Updates for 10.14 and 10.15, and will update the online database then. If you want to check that your Mac has the latest firmware, please use this article as reference.
Then open Disk Utility and check the layout of your boot disk. This should consist of a single Container, within which are the two volumes
Macintosh HD and
Macintosh HD - Data (or similar if yours has a custom name). Within the first of those should be the mounted System snapshot named
com.apple.os.update- followed by a long string of letters and digits.
If you have multiple Data volumes, such as
Macintosh HD - Data and
Macintosh HD - Data Data, then you’ll need to ensure the correct Data volume is grouped with the System volume, and delete the superfluous one.
If you want to use the same Installer app for other Macs, it’s easy to move the Installer app around from Mac to Mac. I like to use AirDrop for this purpose, but it has one major disadvantage: it sets the quarantine flag on whatever you transfer. When you’re moving notarized apps around, that makes little difference; with unnotarized apps it’s a bit tedious opening them the first time. But with Apple’s Installer apps, this often spells disaster. macOS subjects them to Gatekeeper’s full first run checks, which they are likely to fail! If you want to move them around using AirDrop, you’ll have to strip their quarantine flags – something I’ll walk through tomorrow morning.
The alternative is to turn the Installer app into a bootable installer on a USB ‘stick’ or small external storage device. Apple hasn’t yet updated its support article for Big Sur, but that should point you in the right direction, and there are apps to do the same thing. The major disadvantage now is that Macs with T2 chips will probably need their security settings changed in Recovery to enable them to boot from external storage.
If you’ve been beta-testing Big Sur, upgrading to the release version may prove more tricky. My MacBook Pro, which had previously been running betas, was the first of my systems to be upgraded. Being aware of potential problems, I obtained the Installer app via the App Store on Friday 13 November, once Apple’s update server problems had resolved. Oddly, that installer doesn’t install the regular release version of 11.0.1, but the previous build number 20B28.
The MacBook Pro seems perfectly happy with that, and won’t offer any update to 20B29. Another system I’ve been using for beta-testing decided that it needed a further update to bring it to build 20B29. My iMac Pro, on which I never run beta versions of macOS, decided that it needed to be updated to 11.0.1, but it was only on the second download of the update that it finally made it to build number 20B29.
The moral of the story is that the best option with beta-test systems is to perform a clean install whenever you can.
I wish you a trouble-free upgrade and joy with Big Sur!