There was a time when macOS drew attention to a kernel panic, with a distinctive multi-lingual explanation shortly before the Mac restarted. These days, it’s like a guilty secret: your Mac restarts for no apparent reason, then a minute or so after it’s back up and running you’re invited to send some technical information to Apple. It’s really easy to agree to that without saving the panic log, and remaining none the wiser as to what happened or why.
If your Mac restarts spontaneously in this way, look out for that panic log, and before agreeing to send it to Apple (or not), select its contents, copy and paste them into a text document, using TextEdit if necessary. Save it somewhere safe, and only then click on your chosen button in the panic log window. These panic logs used to be saved more obviously, and you may still be able to find them in one of several locations accessible from Console, but in many cases they just seem to vanish without trace once they’ve been sent to Apple.
Unfortunately, if you’re only logged in as a ‘regular’ user, and don’t have admin privileges, you’re not deemed worthy of seeing the panic log (thanks to John for reminding me of this serious omission).
Apple’s advice on what it terms “unexpected restarts” is here.
If your Mac seems to be running normally again, there’s now no need to run hardware diagnostics, repair its disks, or try to hunt the needle in its haystack. When you get a moment, read through the panic log that you’ve saved, looking for a probable cause. This article explains how to understand the log.
If your Mac remains unstable, particularly if it panics again, the first thing to rule out is a hardware fault, or a failing disk. Run its Diagnostics, as explained here, and watch for any disk which might be in trouble. After that, you’re into a hunt for the cause, such as a third-party kernel extension or something else which has pushed the kernel beyond that point of no return.
The worst panics by far are those which occur during startup, as they can result in a boot loop: each time your Mac panics, it restarts. However, when it reaches that same point during the boot process, it panics again, and so on. In theory, macOS should reach a limit of panics and shut down instead of restarting. As Apple puts it “If the issue causes your Mac to restart every time it attempts to start up, your Mac might eventually shut down.” But when it has shut down you’re only likely to try to start it up again, putting it back into the boot loop.
Your first response to any boot loop panic like this should be to shut your Mac down, so you can assess the situation. Press and hold its Power button for at least ten seconds, until the display goes black and the Mac powers itself off. Only in extremis should you ever consider turning the mains power off, or disconnecting it from power, as that’s very likely to cause more problems.
Three less uncommon causes of boot loop panics are:
- Starting an M1 Mac up from a missing external boot disk.
- iBridge firmware problems in T2 Macs.
- Corrupt or damaged boot disks in Macs running macOS Catalina or earlier.
Currently, one fairly consistent way to put an M1 Mac into a boot loop is to start it up from a bootable external disk, with that disk set as the startup disk, shut it down, disconnect the external disk, and then start it up. Instead of entering Recovery mode as you might expect, it’s likely that the Mac will enter a boot loop, from which the only relief is to shut it down.
Failed T2 firmware updates have also been known to cause boot loops in the past, but it’s some time since I last heard of that happening.
Because of their Sealed System Volume, Big Sur and later macOS shouldn’t enter a boot loop if that becomes damaged or corrupt. Should that happen, the Seal should fail, causing the Mac to enter Recovery mode for macOS to be reinstalled. However, older versions of macOS don’t have sealed systems, so can rarely enter a boot loop.
Starting up after a boot loop
Without taking any remedial action, trying to start your Mac up again after it has entered a boot loop is normally no improvement: chances are it will re-enter the boot loop.
If you disconnected the external boot disk from an M1 Mac, this is an excellent time to reconnect it if you can, and your Mac may then start up as if nothing had happened.
Otherwise, while it’s still shut down, this is a good time to disconnect any peripherals which are non-essential and could be exacerbating the problem. This applies particularly to those more likely to cause problems, including docks, hubs, most other USB-C and Thunderbolt devices, and sometimes external displays.
While that alone could break the boot loop, it’s usually best to try starting up into Recovery. If that’s successful, you can then use Disk Utility to check and repair your boot disk, maybe install macOS if you think that might help and you’re running Catalina or earlier. On an M1 Mac, you can then change its startup disk back to the internal SSD and restart it from that.
If that fails on an Intel Mac, try Remote Recovery, holding down the Command-Option-R keys. Although much slower, that will provide the same tools.
On an M1 Mac which has already undergone at least one macOS update, try Fallback Recovery instead. Engage that by pressing the Power button briefly once, and immediately pressing and holding it in until Options start loading. Fallback Recovery is the previous version of Recovery, created when a new recoveryOS is installed by a macOS update. It’s functionally complete, apart from its Startup Security Utility, which doesn’t work.
If all else fails, and it has a T2 chip or is an M1 Mac, shut it down, then start it up into DFU mode, connect it to another Mac running Apple Configurator 2, and try a non-destructive Refresh. If that doesn’t help, then you may need to perform a full Restore, which will completely wipe the internal SSD and set it back to factory condition.
If none of these helps, then I’m afraid it’s off to Apple Support or your nearest official Service Provider, although on some older Intel Macs you might have success juggling around with removable memory as a last ditch measure.