No Mac should ever suffer a kernel panic, and M1 Macs are designed to further reduce their risk, for example eschewing third-party kernel extensions, but occasionally panics do still happen. When they occur following startup, typically when waking from sleep, what normally happens is that your Mac restarts, and once it’s back up and running you’re informed that it shut down abnormally, and presented with the panic log.
When they occur during startup, kernel panics are a bigger problem which can readily lead to repeated restarts and panics – the dreaded boot-loop. This article is about what happens when an M1 Mac panics during startup, and what you can do about it.
For reasons I explain below, when my M1 Mac mini tried to start up, it panicked (although I didn’t of course know that at the time). What I then had was a mini with its power light on, but nothing on the display, which told me there was no video signal and turned off. After a bit of inconsequential fiddling with cables and display controls, I forced the mini to shut down by holding its Power button. I waited a while and tried to start it up again, with the same result. To all intents and purposes, my mini was dead, apart from its power light.
What I did next
I held the Power button again to force the mini to shut down, left it a minute to ensure that it would start up ‘cold’, then started it up in RecoveryOS by holding the Power button until it was loading Options.
I then went through Options to Disk Utility, where I checked both its System and Data volumes, which were healthy, as were all their snapshots. I next went to select the startup disk, where I confirmed that I wanted it to boot from its internal SSD, and restarted it directly from Recovery. It then booted normally, and, apart from the panic log, was back to normal again. I was careful to copy the whole of the panic log into a TextEdit text file and save it.
Why the panic?
I had originally started the mini into RecoveryOS to check out some details of its Secure Boot process for an article which I’ll publish later this week. At that time, it had an external SSD connected via Thunderbolt, and once I had finished in Recovery I restarted the mini. At that stage the startup disk was that external SSD, so when it reached the login window, I shut the mini down and disconnected the external SSD. I then started it up again, assuming that it would boot normally from its internal SSD: it didn’t, and panicked instead.
From the panic log, the panicked task was
kernel_task, and the kernel extensions in its backtrace were com.apple.security.AppleImage4(3.0), with dependencies com.apple.driver.AppleARMPlatform(1.0.2), com.apple.iokit.IOCryptoAcceleratorFamily(1.0.1) and com.apple.kec.corecrypto(11.1). Many kernel extensions had already been loaded, but insufficient for the OS release to have been set, and the immediate cause of the panic was “cannot find IOAESAccelerator”.
I recall seeing that as the immediate cause of the only other panic I have seen in either of my M1 Macs, and that occurred during the difficult upgrades around macOS 11.0.1.
The reason for the panic appears to be that the Mac was expecting to boot from an external SSD, in Secure Boot, but that Startup Volume Group was missing. It was then unable to continue the boot using the internal SSD even though that had been configured and available, and couldn’t throw the Mac into RecoveryOS, which is perhaps the best option if it can’t continue to boot.
Intel Macs are normally quite happy to boot from whatever is available. When the external disk they were expecting can’t be found, they’re easily fobbed off with an alternative. The M1 Secure Boot process isn’t as relaxed or forgiving: if it has been set to boot from a disk which is no longer available, start it up in RecoveryOS and change the startup disk properly before restarting that Mac. Better still, if you know that you’re going to change its startup disk, have the courtesy to tell it that before expecting it to guess what you intend. That said, it would be helpful if instead of panicking, macOS were to return the user gracefully to RecoveryOS rather than panicking during startup.