{"id":47312,"date":"2025-04-04T17:11:29","date_gmt":"2025-04-04T21:11:29","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=47312"},"modified":"2025-07-30T14:26:44","modified_gmt":"2025-07-30T18:26:44","slug":"how-external-bootable-disks-work-with-apple-silicon-macs","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/04\/04\/how-external-bootable-disks-work-with-apple-silicon-macs\/","title":{"rendered":"How External Bootable Disks Work With Apple Silicon Macs"},"content":{"rendered":"

Howard Oakley<\/a>:<\/p>\n

\n

Unlike Intel Macs (including those with T2 chips), all Apple silicon Macs always start their boot process from their internal SSD, even when they are set to start up from a bootable external disk. This ensures the security and integrity of that process and prevents an attacker from starting that Mac up without credentials.<\/p>\n<\/blockquote>\n\n

However, this is a problem if the internal SSD isn’t working properly, as happened to me.<\/p>\n\n

\n

In addition to normal requirements for a macOS installation on an external disk to be able to boot a Mac, ownership<\/em> of the boot volume group on that disk is required. This is normally performed when installing macOS on that disk, as explained here<\/a>, and results in the ownership of that boot volume group by an authorised user of that Mac. This is incorporated into a LocalPolicy<\/em> that is saved to the internal SSD of that Mac.<\/p>\n

[…]<\/p>\n

To accommodate the more advanced Secure Boot of Apple silicon Macs, their internal SSDs are divided into three partitions, with an extra six volumes beyond the boot volume group.<\/p>\n

[…]<\/p>\n

Because restoring in DFU mode erases the whole of the internal SSD, it also blows away all saved LocalPolicy for that Mac. Following the restore process, any bootable external disk used with that Mac will need to have its ownership re-established so that a new LocalPolicy can be created for it.<\/p>\n<\/blockquote>\n\n

Howard Oakley<\/a>:<\/p>\n

\n

It’s a common misunderstanding that trying to change Boot Security in Startup Security Utility can help solve Apple silicon boot problems, but if anything it only complicates them. Almost the only good reason for reducing boot security of an Apple silicon bootable system is when third-party kernel extensions are required. Otherwise don’t tamper with Startup Security Utility, as it will only confuse, as we’ll see later.<\/p>\n

[…]<\/p>\n

One important functional difference, which remains relevant to Big Sur boot disks, is that Apple silicon Macs don’t use the paired Recovery volume as their primary Recovery system: booting an Apple silicon Mac running Big Sur into Recovery should instead use the Recovery system installed in their internal SSD, in the Apple_APFS_Recovery partition. In subsequent versions of macOS, that’s used instead for secondary or Fallback Recovery. Thus Big Sur can be a problem when it comes to Recovery, and for this reason is best avoided on Apple silicon Macs. If it’s essential to install a copy of Big Sur, then be prepared for problems with Recovery mode.<\/p>\n

[…]<\/p>\n

Although APFS should be backward compatible, making it relatively safe to make changes to an older version of APFS from a newer system, forward compatibility is more limited. Using older versions of Disk Utility or tools like fsck<\/code> on newer versions of APFS risks errors, failure and at worst damage. The Appendix at the end of this article summarises version numbering in APFS and major changes to beware of.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n