At first sight, it might appear that boot volume groups and overall disk layout in Ventura are exactly the same as those in Big Sur and Monterey. This article shows their similarity, and how they differ significantly.

Intel Macs

On Intel Macs, there’s the traditional hidden EFI partition, and a single APFS container with the bootable system, consisting of:

• the SSV, a mounted snapshot of the unmounted read-only System volume named Macintosh HD, which forms the root of the boot file system. The snapshot is named com.apple.os-update- followed by its UUID;
• the writable Data volume, by default on the internal disk named Macintosh HD – Data, which is normally hidden from view at /System/Volumes and accessed via firmlinks. On Intel Macs, this is given its full name;
• Preboot, where the changes are;
• Recovery, the paired Recovery Volume;
• VM, containing virtual memory caches.

Note that the Seal on the unmounted read-only System volume is normally broken, but it’s the snapshot which is the important one: that should be sealed, unless you have broken its seal intentionally.

Intel Macs still boot into the paired Recovery volume within their boot volume group by holding the Command and R keys during startup. If that fails, the only alternative source of recovery tools is Remote or Internet Recovery, entered with the Command, Option and R keys held.

Apple silicon Macs

The internal SSD in an Apple silicon Mac (M1 and M2) consists of three APFS containers, and lacks the legacy EFI partition. Only the Apple_APFS container is normally mounted, and that has a similar structure to the boot container of an Intel Mac, or that of an external bootable disk. There are two significant differences, though:

• the Data volume isn’t named Macintosh HD – Data, as on an Intel Mac, but plain Data;
• the paired Recovery volume is the primary Recovery system for that copy of macOS, and is supported by the fallback Recovery system in the unmounted Apple_APFS_Recovery container.

Apple silicon Macs are distinct in having this fallback Recovery system which makes them more robust in the event of damage occurring to the boot container on their internal SSD. Note that in Big Sur there is no paired Recovery volume; instead, the Recovery partition on the internal SSD is the main Recovery system for all bootable systems on that Mac. That was changed to paired Recovery with macOS Monterey, and paired Recovery remains in Ventura.

Preboot volume

In Monterey 12.6, this volume in the boot volume group contains just under 1 GB of kernel collections, firmware, and other data required for the boot process. In Ventura, its key additional function is to contain cryptexes, cryptographically sealed extensions that extend the existing signed and sealed System volume (SSV). These have been explored in this random blog article.

Since Apple introduced the SSV in Big Sur, some system files, including Safari and security tools like XProtect data and MRT, have had to be stored off the SSV so they can be updated outside full macOS updates. Recently Apple has started doing this using cryptexes, which can be updated more flexibly while still providing better security protection than that afforded by SIP alone. Ventura not only uses these for Safari, dyld shared caches and components previously stored on the Data volume, but uses them to patch vulnerabilities using its new Rapid Security Response (RSR) scheme.

The Preboot volume is not only accessible through /System/Volumes, but its cryptexes are also linked from a new /System/Cryptexes folder. These are further interlinked, with the Preboot volume now containing more than 17 GB, including:

• Safari and all its supporting components, including WebKit,
• dyld shared caches,
• a dozen driver bundles,
• OpenCL and OpenGL frameworks.

Apple’s plan with cryptexes for RSR is that they will be downloaded by choice, as part of security data updates. They will also be removable, so if you discover problems following an RSR update you’ll be able to revert from it. Security patches included in RSR updates will then be incorporated into the SSV when the next macOS update is installed, and the SSV is rebuilt during its installation.

Firmlinks

System firmlinks are listed as usual in /usr/share/firmlinks and haven’t changed since Catalina:
/Applications <-> Applications
/Library <-> Library
/System/Library/Caches <-> System/Library/Caches
/System/Library/Assets <-> System/Library/Assets
/System/Library/PreinstalledAssets <-> System/Library/PreinstalledAssets
/System/Library/AssetsV2 <-> System/Library/AssetsV2
/System/Library/PreinstalledAssetsV2 <-> System/Library/PreinstalledAssetsV2
/System/Library/CoreServices/CoreTypes.bundle/Contents/Library <-> System/Library/CoreServices/CoreTypes.bundle/Contents/Library
/System/Library/Speech <-> System/Library/Speech
/Users <-> Users
/Volumes <-> Volumes
/cores <-> cores
/opt <-> opt
/private <-> private
/usr/local <-> usr/local
/usr/libexec/cups <-> usr/libexec/cups
/usr/share/snmp <-> usr/share/snmp
/AppleInternal <-> AppleInternal (on Apple engineering systems only)
in each case shown as the system volume path and the Data volume path which are firmlinked.