macOS' "Failed to personalize" error may have been me being an over-eager deleter

I had been tracking the macOS public beta on my M2 MacBook Pro for a little while in the hopes they were fixing a particularly painful issue with Linux Rosetta support.

Because I've experienced some serious pain before running a beta as my daily driver, I opted to run the beta in a partition and leave my production macOS alone. This worked pretty well for a time, but then I decided to clean it up.

Inside Disk Utility's partition dialog, I saw

1. my main macOS partition,
2. my beta macOS partition,
3. an unlabeled "container disk1" that was 524 MB, and
4. an unlabeled "container disk2" that was 5.37 GB.

Deleting the beta macOS partition was a no-brainer. But the other thing I did was notice that Disk Utility allowed me to delete the 5.37 GB partition, so I did. I rebooted, and all was well. My computer continued to work just fine under macOS 13.2.1, looking like this:

That is, until macOS 13.3 RC came out and I decided to try to pull it in as my daily driver.

I was entirely unable to install the upgrade. It would start downloading, then fail with the message "failed to personalize the software update". I tried lots of other options, including building a bootable installer—it would boot, but not install. I started to fear I'd be stuck in 13.2 land forever.

After spending a few days on this problem, I thought back to the partition that I'd deleted. I have an M1 Mac mini, so I went back to it and peeked at its partitioning. It had both "extra" partitions. I realized I'd probably made a mistake.

I routinely end up on Howard Oakley's The Eclectic Light Company blog reading about the systems underlying the Macs I use on a daily basis. Howard had, of course, covered the purposes of these partitions:

The three containers on an M1 Mac’s internal storage have distinct functions.

The first, Apple_APFS_ISC, is the iBoot System Container (iSC), and supports the iBoot firmware in the early boot process, as well as providing trusted storage for the Secure Enclave within the M1 SoC…

The Apple_APFS_Recovery container is dedicated to providing [1 True Recovery], which is stored on its Recovery volume. This includes a second part of iBoot and all that’s necessary for the M1’s full Recovery Mode. That Recovery volume is designated for recovery, but this container doesn’t have a separate booter volume.

A quick trip to "diskutil list" and I saw a problem, if not the problem—on my MacBook, I still had "Apple_APFS_ISC", but I'd deleted the "Apple_APFS_Recovery" partition entirely.

The part I don't know is whether that partition was actually required for this mysterious "personalization" phase of installing a macOS update, but it seemed likely.

I routinely keep several Time Machine backup (including to an SSD drive that makes recovery so much faster than spinning rust) and was still in a position to update those backups, so I thought my most effective way to get my MacBook's partitions back in order was to start over.

Now, maybe a regular old erase and reset might've done the trick (and I definitely recommend you try this first if you end up where I did), but I've been messing around with restores with Apple Configurator lately, and I decided to give that a spin to start this MacBook from scratch.

A little while later, I was back in business. I have all the partitions I need, and when macOS 13.3.1 rolled around very recently, it installed without a hitch.

Are you likely to run into this problem? Probably not, unless you like to mess around in places you probably shouldn't. But despite the time it took to reset and come back, I've learned a lot about the bits and pieces under the hood on my Mac and I'm glad I had the opportunity.

Plus, I'm one of those weirdos who enjoys doing clean installs every so often, and this was definitely one of the cleanest.