Attempt Tahoe Update, Break the Seal

TidBITS Talk
1

Does anyone actually understand macOS update security?

My MacBook Pro (M2) is now on macOS 26.6.2 Tahoe. I have a SuperDuper! clone that is macOS 15.7.5 Sequoia. I want to update it to Tahoe.

I could, of course, do a full (asr) re-clone. But this has disadvantages, such as:

  • If the clone fails, now the backup is completely lost
  • ASR clones result in an unencrypted drive, so have to boot up to the clone and to turn FileVault back on, and then it takes time to re-encrypt. For an external drive this means it has to actually encrypt all the data.

With macOS on Intel there was an easier way: apply the macOS update to the clone. There are, in theory, three ways to do this:

  1. Boot into the clone, accept the macOS update in System Preferences > General > Software update
  2. Boot into the clone, run the full macOS updater
  3. Run the macOS updater from the host computer, telling it to update the external volume

Method #1 is preferable; it is a less intensive upgrade if it is offered through Software Update.

And note that regardless of which method is chosen, it didn’t matter what it changed on the Data volume – that volume will get back in sync with the next SuperDuper! Smart Update.

I don’t think I’ve ever been successful with any of these methods on Apple Silicon. But undaunted by past failure, I tried method #1 yesterday:

  1. Booted into the backup (Sequoia) SSD.
  2. Unmounted the internal (Tahoe) drive, just in case.
  3. Opened Software Update
  4. macOS Tahoe 26.6.2 was available. Clicked Upgrade Now.

This failed: it asked for a password, but the dialog just shook when I enter it.

I verified that the password was accepted for other purposes (such as lock and unlock) and that this startup drive had a Secure token enabled for the user account I was entering the password to, and that the cryptographic users for that disk has a Local Open Directory User and Volume Owner that matched that same user. So why didn’t it accept the password and continue the upgrade?

It gets worse. I tried restarting (still with the Sequoia drive as the Startup drive), and when it got to the window to unlock the drive, it wouldn’t accept my password there either!

So I gave up and changed the startup back to Tahoe. And that’s when I discovered that the seal on the Sequoia signed-sealed-volume was broken.*

But it must have been OK when I first booted to that Sequoia drive yesterday. This implies to me that Software Update broke the seal.

This is concerning to me: that merely trying to run Software Update and apply a macOS update can render your drive unbootable.

Where did I go wrong?

* There is some question of whether the seal is really broken. I’ve seen before where diskutil will say it is broken, but it is in fact OK, because the seal is actually applied to a snapshot of the volume. But I compared diskutil’s report to a Ventura clone, on Ventura, and it said the seal was OK there. So, I’m tentatively concluding that in Tahoe I can trust diskutil.

2

The seal will be broken for any volume that isn’t the current startup disk, simply because the System volume could be mounted read-write. As you surmised, it’s the System volume snapshot whose seal matters, and that snapshot is only mounted when you’re booted from the associated startup volume. So the seal being “broken” is probably just a red herring in this case. It shouldn’t affect Software Update, either. When you apply an update, the System volume gets replaced and the macOS Installer creates a new, sealed snapshot; the state of the old System is (should be) irrelevant.

Can you install updates via softwareupdate -i -a in the Terminal?

Edit: My bad, I see you actually don’t have a bootable Tahoe disk at this point, so the suggestion above is probably moot.

3

Timely topic as I just recently had a similar experience. I have an external boot drive with an older version of Sequoia. It was created with SuperDuper. Attempts to update through the normal Software Update would fail because of the password. I did an online search (perplexity.ai) and realized that it had something to do with the secure enclave security policy but the rest was above my pay grade.

A few days ago, I tried again to update to 15.7.9. This time I booted into Recovery Mode and tried the install. This worked and the drive is now at 15.7.9.

Earlier today I tried to update to 15.8 but, as before, the password was not accepted. I started the Recovery Mode method but it was too slow (estimated 9 hours and increasing) so I quit. I’ll try again after the servers are less loaded.

Edit: Changed secure enclave to security policy. Also, the upgrade finally finished.

4

That makes sense. So there’s some other reason why I can’t boot the Sequoia (not Tahoe) disk now.

My internal Tahoe drive is fine.

My plan is to go for the full asr clone. I’m just wondering what’s going on here.

5

Just out of curiosity and to offer a data point, I booted from a CCC-created bootable copy of Tahoe. Very specifically:

  • Booted from Golden Gate (I don’t think this matters, but that’s the volume my Mac was booted from)
  • Created the copy with the newer CCC 7.2 that came out today (this might be the missing link)
  • After completing the ASR copy, I set the Tahoe copy as the startup disk and authorized users (which specifically calls out software update not working if you don’t complete that step)
  • Once booted into Tahoe (26.6), I was able to apply the 26.7 update (it’s installing right now)

When I started poking around in documentation and whatnot, I noticed that the CCC and SuperDuper websites had conflicting blog posts today. SuperDuper dev reported that he couldn’t make bootable copies on Golden Gate, CCC dev reported he could create bootable copies on Golden Gate. [Edit: I knew I had a point here :zany_face: – The difference was whether the copy shows up in Startup Disk; if it doesn’t show up there, you can’t “Authorize users”, which is necessary for Software Update]

Initially I didn’t think Golden Gate would be related, but I’ll have to try my test again tomorrow while booted from Tahoe (the original 26.6 source) to make the clone to see if it makes any difference. I’ll repost with an update tomorrow, it’s late.

6

Do it the easy way.
Get another drive.
Do a brand new clone.
Now you have BOTH – new and old (for archival purposes).

1 Like
7

Following up with the results of my tests – they’re basically inconclusive. I created two bootable Tahoe copies (CCC and SD) while booted from the Tahoe source volume, both had no trouble installing the 26.7 software update. I definitely remember seeing trouble with this in the past, I just can’t seem to connect the dots in this case.

8

I had no idea what “signed-sealed-volume was broken” meant, so I searched Google. I got this response:

You can likely ignore this error message, as it is usually a harmless bug (“red herring”) in macOS. ®

If you ran diskutil apfs list or a terminal check on an Intel-based Mac, the tool often misreports the Signed System Volume (SSV) status as “Broken” even when the operating system is completely healthy and secure. ©

How to Verify if Your System is Actually Secure

To check the real security and cryptographic integrity status of your Mac, open the Terminal app and run the following command: Apple Community

bash

crutil authenticated-root status

Use code with caution.

  • If it says Authenticated Root Status: ENABLED :
    Your system volume is perfectly intact, signed, and secure. You do not need to take any action.
  • If it says DISABLED (and you didn’t turn it off yourself: Your system partition may have been modified or corrupted. The Eclectic Light… +2
9

Google’s reference to a “red herring” may have come from this very thread :grinning_face:

10

This blog post from Mike Bombich should be required reading for bootable clones and Golden Gate Bootable copies live on in macOS Golden Gate

The key takeaways seem to be that 1) the latest CCC 7.2 can create bootable clones, 2) these clones can only be updated whilst source and destination are of the same macOS version, 3) the bootable clone needs to be recreated after any system update.

Mike is suggesting that bootable clones are for those that want a redundancy strategy, not backup strategy. See the “Is a bootable backup right for me?” section in the blog post.

There is no suggestion that the clones can be updated with the Apple update process - they must be recreated whenever the source macOS has been updated.

3 Likes
11

Yes. It is (for the most part) automating what we used to have to do manually:

  • Create a bootable backup (via ASR) for the initial backup
  • Make incremental backups of the Data volume
  • When the macOS system volume changes (after an update), redo the above from scratch (blowing away the Data volume backup history) so the backup will boot into the new version.

The big deal here is that you used to have to do this with two backup tasks (or by manually changing one of the tasks), and remembering to run the correct one based on whether or not macOS has changed. Now, a single task will do all of the above without you needing to manually change anything.

For those who want/need their backups to be bootable, this is about as good as you’re going to be able to get.