With careful observation and a little knowledge of the startup sequence of an Apple silicon Mac, you can learn a lot about what can and can’t happen during that sequence. This article explains how, with examples from the log of a Mac mini M4 Pro.

In broad terms, startup of an Apple silicon Mac consists of the following sequence of events:

• Boot ROM, which ends in DFU mode if there’s a problem, otherwise it hands on to
• the Low-Level Bootloader (LLB) and iBoot (Stage 2), the firmware, that should end in validating and running
• the kernel, which initially runs on a single CPU core before starting others up and launching launchd, and later
• unlocking and accessing the Data volume, and progressing to
• userspace.

The opening entry in the log is the boot announcement of
=== system boot:
followed by the boot UUID. There’s then a gap of 5 seconds or more before the next entry, which marks the start of kernel boot. Those seconds are the silent phase during which the LLB and iBoot are doing their thing. They don’t write to the Unified log, but leave fragments of cryptic information known as breadcrumbs, which you can’t make use of. The kernel then writes its usual welcome of
kprintf initialized
and the following four seconds or so are filled by log entries from the kernel.

Wallclock adjustment

During this phase, the system clock is synchronised, and wallclock time adjusted, usually twice in rapid succession. This is obvious by step changes in timestamp, usually putting the clock back by several seconds in the first sync, then putting it forward slightly in the second. These play havoc with the timestamps, as you can have two or even more instances of the same time being recorded in the log. Beware of the entries
=== system wallclock time adjusted

Early during the kernel phase, it starts up all the other CPU cores in the chip, and records that in the log. Entries become progressively more varied after launchd is loaded, and this first userspace boot (without Data volume access).

Data volume unlock

With FileVault enabled, by this stage macOS still doesn’t have access to the Data volume. That means all the code run so far, and almost all the data, are immutable, locked in the firmware or the Signed System Volume (SSV). The firmware does access LocalPolicy from another container in the internal SSD, and there’s always the NVRAM, but there’s no access to anything in /Library, including the many property lists there. This also means that processes running before the Data volume is unlocked and mounted can’t write to storage.

Around 10-15 seconds after the start of booting, the login window is displayed, ready for the user to enter their password. Once that has been entered, there’s a watershed moment:
30.845097 com.apple.loginwindow Attempting to unlock the data volume <LFVolume: 0x6000001b8e40: [UUID]: Data>
30.883172 "AppleSEPKeyStore":3814:0: Sending notification for volume [UUID] unlocked (action 1, handle -842987934)
30.885459 com.apple.login volume <LFVolume: 0x6000001b8e40: [UUID]: Data> was unlocked
30.886129 com.apple.loginwindow Unlocked data volume <LFVolume: 0x6000001b8e40: [UUID]: Data>
30.886154 com.apple.loginwindow FileVault volume unlocked, allow authorization
30.887562 com.apple.loginwindowLite -[LWLSystemUnlock unlockSystem]:439: Authorization was successful
30.887587 com.apple.loginwindowLite -[LWLSystemUnlock unlockSystem]:447: logging in user hoakley
The times on those entries were deliberately delayed, as I pressed the Return key for password entry after 30 seconds had elapsed, a good 10 seconds later than I could have done so.

Shortly after that, the kernel manager shuts down, a great many kernel space processes are handed over to continue in userspace, and you’ll then see the kernel report
userspace boot

Before the Data volume is unlocked, log entries are frequent, but hardly a torrent, at around 1,000 per second, and more than 25% of them are written by the kernel. Once the kernel has booted userspace and the Data volume is accessible, log entries are written far more frequently, at an average rate of 5,000 per second, often even higher, with less than 10% of them coming from the kernel.

Phase summary

• Boot ROM, entering DFU mode or handing over to
• Low-Level Bootloader (LLB) and iBoot (Stage 2) firmware, without log entries, handing over to
• the kernel, with wallclock adjustments, until
• Data volume unlocking, then into
• userspace and access to /Library and user files.