Fixing a Broken SSV Seal MacBook Pro Restored from a Mac mini over Thunderbolt Target Disk Mode

Articles · 2026 · Ioannis (John) Konstas

An Intel MacBook Pro that won't boot, throws a prohibitory symbol, and fails Cmd+R recovery reads like dead hardware — and gets diagnosed that way constantly. It usually isn't. Since macOS Big Sur, every Mac boots from a Signed System Volume: a read-only, cryptographically sealed snapshot of the system files, hashed with SHA-256 into a Merkle tree, with the root hash signed by Apple at install time. A single altered or corrupted byte anywhere in that snapshot changes the root hash, the signature check fails, and the boot chain halts completely. There's no "boot anyway" override, and the seal can't be patched in place — only regenerated by a full install. This is what actually happened to a Late-2019 MacBook Pro with a T2 chip, and how I restored it using a Mac mini (M4 Pro, Apple Silicon) as the host over Thunderbolt Target Disk Mode, entirely from the command line.

How a broken seal presents

The failure mode is why it gets misdiagnosed. Before total failure, the machine is often just unstable — random reboots, freezes, failed updates — which reads exactly like an aging SSD or logic board giving out. It isn't:

Verification happens before the root filesystem even mounts: on Apple Silicon the boot loader checks the seal itself before handing off to the kernel; on Intel Macs with a T2, the boot loader forwards the measurement and signature to the kernel, which verifies it directly. Protection continues at runtime too — data read from internal storage is hashed in the read path and compared against expected values, and a mismatch is never returned. Typical root causes: an interrupted macOS upgrade, third-party tools modifying sealed system files, an interrupted T2 firmware update, or NVMe storage corruption producing hash mismatches. Only the user Data volume can be restored from backup — the System volume has to come from a fresh, seal-generating install. Cloning the live volume or hand-repairing files just produces a snapshot whose hashes no longer match a valid Apple signature, and the machine refuses to boot again on the next restart.

Why the obvious recovery paths don't work

Cmd+R fails because the T2 chip validates the local recovery partition before loading it — a broken seal prevents that environment from initializing at all, hence the black screen or spinning globe. Option+Cmd+R (Internet Recovery) is unlikely to fare better: on T2 Macs, Apple's servers perform the same chip validation before serving the recovery image.

The command-line route looks more promising until it isn't. startosinstall --volume, run from the Mac mini targeting the MacBook's disk over TDM, consistently printed usage text and exited with code 1 — despite --volume being a genuinely valid flag, confirmed by pulling it straight out of the binary with strings. The real cause: Apple Silicon Macs use a different security architecture (SPSB/LocalPolicy), and the startosinstall runtime refuses cross-architecture installs — Apple Silicon host, Intel external target — outright. --eraseinstall and --volume are also mutually exclusive, which rules out the other obvious workaround.

The path that actually works: createinstallmedia

The fix is to skip startosinstall and its security-layer checks entirely and go one level lower, with createinstallmedia — Apple's installer-media tool has no architecture restriction because it operates directly at the disk level.

The under-documented catch: createinstallmedia flatly rejects APFS volumes — "APFS disks may not be used as bootable install media." The target disk has to be erased as HFS+ (Mac OS Extended, Journaled) first, even when the target is the Mac's own internal SSD accessed over TDM.

Rather than burn the whole 500 GB disk as an installer, the disk gets split after the installer is written: a 314 MB EFI partition, a 22 GB HFS+ partition holding the installer, and a 477 GB APFS partition as the actual clean-install target.

The restore, phase by phase

Eight phases, roughly 90 minutes end to end, all run from the Mac mini against the MacBook Pro in Target Disk Mode:

1. Connect (18:00 EDT)

MacBook Pro booted holding T → Target Disk Mode, Thunderbolt symbol on screen. Connected via Thunderbolt to the Mac mini and identified as /dev/disk6 — an external, physical Thunderbolt device. Initial state: an APFS container holding an 847 KB volume named MVVJ2LL, the MacBook's own model number, which is macOS's default TDM volume name.

2. Download the installer (18:02 EDT)

$ softwareupdate --fetch-full-installer --full-installer-version 15.7.7
Installing: 1%...25%...50%...75%...89%...Install finished successfully

~15 GB, landing at /Applications/Install macOS Sequoia.app.

3. Erase the target disk to HFS+ (18:45 EDT)

$ sudo diskutil eraseDisk JHFS+ MyVolume GPT disk6
Started erase on disk6 → Formatting disk6s2 as Mac OS Extended (Journaled)
Initialized /dev/rdisk6s2 as a 466 GB case-insensitive HFS Plus volume
Finished erase on disk6

4. Write the bootable installer (18:46 EDT)

$ sudo /Applications/Install\ macOS\ Sequoia.app/Contents/Resources/createinstallmedia \
    --volume /Volumes/MyVolume --nointeraction
Erasing disk: 0%... 10%... 20%... 30%... 100%
Copying essential files...
Copying the macOS RecoveryOS...
Making disk bootable...
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 100%
Install media now available at "/Volumes/Install macOS Sequoia"

~8 minutes, using the full 499.8 GB disk as the installer for now — that gets split down next.

5. Split the disk (19:13 EDT)

$ sudo diskutil splitPartition disk4s2 2 \
    JHFS+ "Install macOS Sequoia" 22g \
    APFS  "Macintosh HD" 477g
Unmounting disk → Formatting disk4s2 as HFS+ (22 GB)
Formatting disk4s3 as APFS → Finished partitioning

splitPartition reformats the source partition as a side effect — it erases whatever installer content was already there. The installer has to be rewritten to the now-smaller partition immediately after.

6. Rewrite the installer to the smaller partition (19:14 EDT)

$ sudo createinstallmedia --volume "/Volumes/Install macOS Sequoia" --nointeraction
Erasing disk: 0%... 100%
Copying essential files... Copying the macOS RecoveryOS...
Making disk bootable... Copying to disk: 0%... 100%
Install media now available at "/Volumes/Install macOS Sequoia"

~5 minutes; the installer ends up using 17.5 GB of the 22 GB partition.

7. Eject and disconnect (19:25 EDT)

$ diskutil eject disk4
Disk disk4 ejected

8. Boot the MacBook Pro and install (19:26 EDT)

Powered on holding Option (⌥), selected "Install macOS Sequoia" from the boot picker, targeted the 477 GB APFS "Macintosh HD" partition, and let Sequoia 15.7.7 install.

Where the seal actually gets rebuilt

The SSV seal is never manually repaired — it's generated fresh by every macOS installation. When Sequoia writes itself onto that APFS volume, the installer automatically writes the complete system to a new System volume, creates a read-only APFS snapshot of it, computes the hash tree over every system file, seals the snapshot with Apple's signing key, records the seal in the volume's APFS metadata, and from that point on the T2 chip validates it on every subsequent boot. Confirming it worked is one command:

$ diskutil info / | grep Sealed
   Sealed: Yes

The machine booted from its own disk straight into the installer and came out the other side with a valid seal — hardware that had been written off as dead, restored entirely through software.

What's actually worth remembering from this

• startosinstall's architecture restriction is real and silent. The --volume flag exists in the binary — confirmed with strings — but runtime validation rejects any cross-architecture install from an Apple Silicon host to an Intel target. createinstallmedia is the only path that works from that direction.
• createinstallmedia requires HFS+, unconditionally. It refuses APFS-formatted volumes outright, even when the target is the Mac's own internal SSD reached over TDM.
• splitPartition is destructive to the source partition. Treat split-then-reinstall as one mandatory two-step sequence, not two independent steps.
• A T2 firmware password can't be cleared over TDM. It lives in the T2's secure enclave, not on the disk itself, and shows up as a lock icon in the boot picker regardless of what state the disk is in. Clearing it requires Apple Configurator 2 in DFU mode — a different recovery path entirely.

Environment

I perform this recovery as a paid professional service: full macOS restore on unbootable Macs — broken SSV seal, failed updates, prohibitory symbol — including a complete backup of all user files before any destructive step, whenever the disk is still readable. If you've been told your Intel MacBook Pro "needs replacing," it may well be recoverable. Contact: @ikonstas70 · Miami, FL.

References

1. Apple Platform Security — Signed system volume security
2. Apple Support — Create a bootable installer for macOS (createinstallmedia)
3. Apple Support — If your Mac starts up to a circle with a line through it
4. Apple Support — Transfer files between two Mac computers using target disk mode

← All articles

Research and direction by Ioannis (John) Konstas; compiled and finalized with AI assistance.