If your Mac starts to boot but doesn’t get as far as displaying the login window, one of four things should happen:

• if it has been upgraded to macOS 26 Tahoe or later, it might restart into Recovery Assistant;
• it might restart, and repeat the same sequence again;
• it might simply freeze and go no further;
• it might shut itself down again.

The second of those is the most urgent, as it’s in a boot loop, and you need to force it to shut down by pressing and holding the Power button. Although macOS should limit the number of boot loops, don’t leave it to continue looping. If your Mac appears to have frozen, wait for up to an hour before forcing it to shut down, as it could be in the middle of checking and repairing disks, which you shouldn’t interrupt in case it proves successful.

Recovery Assistant

This is a new feature in Tahoe, and uses latest data from Apple to try to recover your Mac automatically. For it to do that it requires an internet connection, preferably over Wi-Fi.

Distinctive to its opening window is its first aid symbol ⊕. Click on the Continue button to move on, and follow its instructions. At the end of that, you should see one of three outcomes:

• no problems were found, and you can restart your Mac back into normal mode;
• problems were found and repaired successfully, so you can restart your Mac back into normal mode;
• problems were found but aren’t fully repaired.

When your Mac restarts, it may show a notification that you need to recover iCloud data. If so, open System Settings and you should see a new item in its sidebar to Recover iCloud Data.

If that doesn’t fix your Mac, you’ll almost certainly need to start up in Recovery and try to fix it there.

Boot loops and freezes

Boot loops happen 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.

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 boot, although it may be shown when you get the Mac to start up normally again.

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.

Advanced tools

Previous tools for the management of kernel extensions included kextload, 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 at least 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 inspect lists all currently installed kernel extensions according to their collection.
• kmutil clear-staging clears the contents of the staging directory /Library/StagedExtensions.
• kmutil unload -p /path/kextname.kext unloads 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 available to manage them is systemextensionsctl. You can use
systemextensionsctl list
to list all known system extensions and their status.

To remove an orphaned system extension, with SIP already disabled, first list those known using
systemextensionsctl list
to provide the teamID and bundleID. Then use those in the command
systemextensionsctl uninstall teamID bundleID
and don’t forget to re-enable SIP immediately afterwards.

Reinstalling macOS

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, that’s generally unwarranted.

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.

Reviving firmware

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 a recent version of macOS, and perform a Revive from there. This is non-destructive of the SSV and Data volume, unlike a full Restore. Apple provides detailed instructions for you to do this yourself, provided you have the necessary second Mac and cable.

The cable used mustn’t be Thunderbolt, but plain USB-C. That’s because DFU mode doesn’t support Thunderbolt or its cable. Connect that to the designated DFU port on the Mac you’re going to Revive. That can be found in Apple’s note, or in Mactracker.

Summary

• If it starts up in Recovery Assistant (Tahoe and later only), ensure an internet connection and continue with that.
• If it’s stuck in a boot loop, force shutdown with the Power button, and disconnect all non-essential peripherals.
• If it appears frozen, leave it up to an hour in case it’s repairing its disk, before forcing shutdown.
• Try starting up in Recovery.
• For Apple silicon Macs in Reduced Security, disable loading of third-party extensions and set it to Full Security in Startup Security Utility.
• Consider running hardware Diagnostics.
• On Intel Macs consider kmutil trigger-panic-medic in Recovery.
• Try Revive in DFU mode to refresh firmware.
• Good luck!