© Francis Mascarenhas/Reuters
If your Mac starts to boot but doesn’t get as far as displaying the login window, one of four things should happen:
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.
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:
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 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.
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.
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:
Login
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 usesystemextensionsctl list
to list all known system extensions and their status.
To remove an orphaned system extension, with SIP already disabled, first list those known usingsystemextensionsctl list
to provide the teamID and bundleID. Then use those in the commandsystemextensionsctl uninstall teamID bundleID
and don’t forget to re-enable SIP immediately afterwards.
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.
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.
kmutil trigger-panic-medic in Recovery.
Last week’s outstanding news was the discovery of a potential treatment for Huntington’s disease, that killed Woodie Guthrie at the age of 55, a tragedy I learned of from his son Arlo’s movie Alice’s Restaurant (1969).
That treatment is so complex that even James Gallagher’s diagrammatic account doesn’t do it justice, but it provides a much clearer picture than some of the treatment offered for our Macs. Although in a different league, our novel treatment of the week is Device Recovery Assistant, as I showed here on Friday. It’s sufficiently new that Apple hasn’t quite gone firm on what to call it. Its sole account refers to it as Recovery Assistant, in accordance with the menu command used to open the app in Recovery mode. But when it’s running, it claims to be Device Recovery Assistant, which sounds like it might also be good for your iPhone or iPad, but isn’t. That’s a similar feature added to iOS and iPadOS 26, as explained here.
I’m still a little wary of magic healing tools in Recovery mode. The first is there even now, waiting to catch those who’ve taken AI a little too seriously, and think running repairHomePermissions might be a good idea. Whatever you do, please don’t try this one at home, as its effects can be devastating. I now only run it in a disposable virtual machine, as reversing its changes would be so time-consuming.
In Recovery mode, typing repairHomePermissions into Terminal launches a GUI app to ‘repair permissions’ in a selected Home folder in the Data volume. Far from repairing them, each time I have tried this it locks me out of every folder in my Home folder and wreaks havoc elsewhere. Yet somehow this historical remnant has been left behind in Recovery mode to catch the unwary.
(Device) Recovery Assistant doesn’t appear to do anything so disastrous, but Apple is completely opaque as to what it actually does. Even its description for macOS 26 beta testing used the same words, “Recovery Assistant is a new way to recover your device if it doesn’t start up normally. It can look for problems and attempt to resolve them if found.”
Just what “issues” can it discover, and how might it attempt to “resolve” them? One thing I can report is that it doesn’t attempt to repair the damage done by repairHomePermissions, and doesn’t see anything wrong with a user not having permissions to access their own folders. Maybe it isn’t that smart yet.
One small clue given by Apple is that it can leave your iCloud connection in need of a further recovery process run when back in normal user mode. Once again, though, information is lacking as to what that does, and why it might be needed.
Of course, if your Mac does have an appropriate problem that prevents it from starting up normally, and it instead puts itself into Recovery Assistant, you have little option but to give it a whirl and hope that it fixes whatever was causing the problem. But why might you want to run Recovery Assistant voluntarily from Recovery mode? Is this something worth doing for specific reasons, or is it just a universal panacea?
With Apple silicon Macs, we’re running out of panaceas. If you don’t know of a specific fix for a problem, most of the old tricks such as resetting NVRAM and SMC, repairing permissions, installing the Combo updater, and re-installing macOS have either become impossible or demonstrably futile. We’re currently left with the innocuous procedure of starting up in Safe mode, and quickly run out of ideas after that.
I’m not suggesting for a moment that Recovery Assistant is a placebo, but until we know more about it, neither can it be a new panacea.
If your Mac starts up in this new Recovery Assistant, or you use it manually in Recovery mode, please let us know what happened and whether it did resolve your problem.
One of the features new to macOS 26 Tahoe that you won’t find in Apple’s list is an enhancement to Recovery mode, in Device Recovery Assistant (DRA). This article explains what it is and how to use it.
When you put your Mac into Recovery mode from Tahoe, you should notice that Apple has changed the disk icon there, to one intended to more closely resemble an SSD rather than a hard drive, although of course it’s still quaintly named Macintosh HD.
If your Mac (upgraded to Tahoe) has problems starting up correctly, it should now automatically restart and open DRA. You can also enter it manually by starting up in Recovery, passing through to Options, and using the Recovery Assistant command in the Utilities menu there, where its app menu identifies itself as Device Recovery Assistant. DRA requires an internet connection to function. If you’re asked to choose a connection, opt for a Wi-Fi network if possible.
Distinctive to DRA’s opening window is its first aid symbol ⊕. Click on the Continue button to move on.
The next window invites you to send data to Apple for diagnostic purposes. Make your choice as you move on.
If your startup Data volume is protected by FileVault, you’ll then be prompted for the password to unlock it. Once that has been provided, DRA attempts to perform a ‘recovery’.
At the end of that, you should see one of three outcomes:
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 DRA doesn’t fix your Mac, you’ll almost certainly need to start up in Recovery and try to fix it there. You can also quit DRA to return to Recovery if you wish.
Apple’s support note doesn’t give any further information about what DRA does.
