Boot loops and freezes are two of the most worrying mishaps that can happen to Macs, as they occur when you have least indication of what’s going on, and have least control.
Boot loops are when a kernel panic occurs during the boot process, before the login window is displayed. When the Mac tries to restart as a result, it hits the same kernel panic, and starts the cycle again. Boot freezes are the opposite: instead of repeatedly cycling through reboot-panic, the boot process comes to a complete halt, normally showing a stuck progress bar on the display. Thankfully neither is in the least common, and should have become even rarer with the introduction of the Signed System Volume (SSV) in Big Sur and later, and the deprecation of third-party kernel extensions.
Although macOS should limit the number of boot loop cycles a Mac goes through, and force it to shut down instead, don’t wait for that to happen. Once you realise your Mac is in a boot loop, press and hold its Power button to force it to shut down so you can work out what to do next. In the case of a freeze leave the Mac up to an hour before giving up on its making further progress. If it’s checking and repairing disks or Time Machine snapshots, the boot could have been delayed trying to repair errors. When you’ve given up all hope of it making further progress, press and hold the Power button to force it to shut down.
What you do next on an Apple silicon Mac depends on whether it’s trying to load third-party kernel extensions. As Intel Macs don’t enjoy the same secure boot process, dealing with them is more difficult.
When an Apple silicon Mac is running at Full Security, the only kernel extensions that it loads are those provided in macOS, whose integrity is checked during the boot process. Any third-party kernel extensions included in the Auxiliary Kernel Collection in /Library/KernelCollections remain untouched.
Likely causes of kernel panics during booting in Full Security mode include failure of validation of the on-disk root hash of the SSV, and hardware faults or errors, either internal or external.
An Apple silicon Mac running at Reduced Security can load third-party kernel extensions from the Auxiliary Kernel Collection in /Library/KernelCollections when that is explicitly enabled in Startup Security Utility. In the absence of any more probable reason for a kernel panic occurring during booting, it should be assumed that the cause is a third-party kernel extension, and that should be disabled in Recovery mode. This can only be done in paired Recovery, following a single long press of the Power button, not in fallback Recovery.
Restarting in Full Security should then complete normally, and allow the third-party kernel extension to be updated or uninstalled as needed.
Diagnostics and Recovery
In most cases, boot loops and freezes are best assessed by disconnecting all suspect peripherals, running Diagnostics and Disk Utility’s First Aid in paired Recovery mode. If that isn’t available, then Fallback Recovery can be used instead. Unfortunately, the most valuable diagnostic tool for kernel panics, the panic log, usually isn’t accessible when a panic has occurred during the boot process.
Before starting up in Diagnostics, disconnect all peripherals, except those that are essential such as keyboard, mouse/trackpad and any primary external display. Ensure a good Wi-Fi network connection can be made. If the problem occurred when trying to boot from an external disk, or if that Mac had previously been booting from one, it may be better to leave that connected; historically, some older combinations of firmware and macOS panic when an external boot disk has been disconnected but is still expected for the next boot.
On Apple silicon Macs, Diagnostics is unique in relying on a hidden key combination: at the initial Recovery screen, hold Command-D until the Diagnostics Loader starts. This may require download of the disk image from Apple’s servers before testing can proceed. Once loaded, there’s a hidden option for extended diagnostics that can be triggered by holding the Command-E key combination.
Disk Utility is accessed as usual from the main Recovery window.
Previous tools for the management of kernel extensions included
kextunload and others. In Big Sur and later, these have been replaced by a single command tool
kmutil, which is inevitably complex to use. Full details are given in its man page, which is extensive and an excellent source of additional information.
There are four
kmutil commands that could prove useful:
kmutil trigger-panic-medic, only available in recoveryOS, clears the AKC at /Library/KernelCollections and forces it to be rebuilt, requiring each kernel extension to be re-approved before it can be loaded. This is intended to be used to recover a system following a kernel panic generated by one of the kernel extensions in the AKC.
kmutil inspectlists all currently installed kernel extensions according to their collection.
kmutil clear-stagingclears the contents of the staging directory /Library/StagedExtensions.
kmutil unload -p /path/kextname.kextunloads the kernel extension specified by /path/kextname.kext. This terminates and unloads it, but doesn’t remove the original kernel extension or any staged copy. Unless you also remove the kernel extension and remove it from its collection, it’s likely to load again at the next boot.
In theory, removing the original kernel extension by removing the app which contains it, or deleting it from /Library/Extensions, should trigger
kernelmanagerd to remove it from the Auxiliary Kernel Collection and the staging directory /Library/StagedExtensions. However, that won’t take effect until after the next reboot. If the kernel extension isn’t then removed, it may be worth using
kmutil clear-staging, and if necessary
kmutil trigger-panic-medic in Recovery mode. Remember that kernel extensions may be left unused in staging, and are protected there by SIP, making manual removal tedious at best, and possibly pointless.
While system extensions shouldn’t cause kernel panics or freezes during the boot process, the command tool used to manage them is
systemextensionsctl, but its man page is still devoid of information, so you’ll have to view its usage information using
for example. You can use
to list all known system extensions and their status.
To remove an orphaned system extension, with SIP already disabled, first list those known using
which provides the teamID and bundleID. Then use those in the command
systemextensionsctl uninstall teamID bundleID
and don’t forget to re-enable SIP immediately afterwards.
The following diagram summarises actions undertaken by the kernel during booting of an Apple silicon Mac.
Historically, reinstalling macOS has often been advocated as a means of addressing boot loops and freezes. In Macs that perform full checking of the integrity of the SSV, Intel Macs with a T2 chip and Apple silicon models, this is generally unwarranted.
The one possible exception is when problems appear to be the result of a Rapid Security Response (RSR). Although those can be reverted using System Settings, Apple hasn’t documented any method of doing so in Recovery mode. Reinstalling the last release of macOS prior to the RSR should have the same effect, in reverting all Cryptexes to what they were at that time.
Another option worth considering might be starting up in Safe mode, as that blocks the loading of most third-party components that could cause conflicts before the login window is loaded.
One well-known if rare cause of boot looping is a problem with firmware. For Intel Macs with T2 chips and Apple silicon Macs, the preferred solution to that is to boot the Mac in DFU mode, connect another Mac running Apple Configurator 2, and perform a Refresh from there. This is non-destructive of the SSV and Data volume, unlike a full Restore, and is detailed in the Apple Configurator 2 Help book, and online for Apple silicon and Intel T2 models.
- Force shutdown by holding the Power button.
- If an Apple silicon Mac is loading third-party kernel extensions, start up in paired Recovery and return it to Full Security using Startup Security Utility, then try restarting.
- Disconnect all non-essential peripherals.
- Start up in Recovery, run Diagnostics, then Disk Utility’s First Aid.
- Consider putting into DFU mode and using Apple Configurator 2 to Refresh the firmware.
- Reinstalling macOS might address problems resulting from an RSR.