Safe Booting in Catalina has changed

A few weeks ago, I considered here whether starting up in Safe Mode (with the Shift ket held) checks and repairs disks, as it has done in the past. I concluded then that macOS Catalina no longer does that. This article looks at what Catalina’s Safe Mode actually does.

Apple’s current support page detailing Safe Booting was written over two years ago, and clearly hasn’t been updated for 10.15 yet. According to that, entering Safe Mode at startup does three things:

  1. it verifies the boot disk and, if there are any directory issues with it, it attempts its repair;
  2. it blocks the loading of many kernel extensions, startup and login items, and user-installed fonts;
  3. it deletes font caches, the kernel cache, and other system caches.

The second of those limits its usefulness, as some of the blocked items prevent some sub-systems from working normally. If you’re trying to isolate a problem which affects one of those sub-systems, Safe Mode won’t help.

I’ve now performed Safe Boots on a MacBook Pro 2017 (without T2 chip) running both 10.15 and 10.15.1, and conclude that no useful check of the integrity of storage is performed any more, have compiled a list of kernel extensions which aren’t loaded in Safe Mode, and looked at some of the ‘caches’ which it rebuilds. Let me step you through some typical log entries from starting up in Safe Mode. As usual, times are given in decimal seconds, in local time UTC+0100.

As with all startups, the log entries open with two characteristic waypoints:
3.000000 === system boot: [UUID]
3.000000 === log class: in-memory begins

Note that the UUID/GUID given here appears to be unique to that startup, rather than any for that machine.

The first indication of Safe Booting appears very early in the log. I’ve always been uncertain how long to hold the Shift key for. In this case, less than a second from initiating the startup should have been fine.
3.054764 kernel SAFE BOOT DETECTED - only valid OSBundleRequired kexts will be loaded.

In 10.15, you will then see scattered entries referring to kernel extensions which haven’t been loaded, such as
3.352849 Kext is not loadable during safe boot; omitting its personalities.
In 10.15.1, there’s now a full listing by subsystem of all the kexts which aren’t loaded, which I reproduce at the end of this article.

Almost exactly one second after the initial log entry, the new Catalina Volume Group is prepared and mounted (just as in a regular startup):
4.080006 ROSV: apfs mounted RO and is the system volume of a volume group and mounted as the root fs: creating the shadow fs_root
4.080063 apfs_vfsop_mount:1463: mounted volume: Macintosh HD
4.081282 attempting kernel mount for data volume...
4.084126 attempting kernel mount for vm volume...

There are no log entries which report that fsck_apfs is being run, nor of any results of that. This is almost unnecessary anyway: compare the time taken for Safe Boot in Mojave with that in Catalina, particularly if you have any snapshots which need to be checked. Safe Booting in Catalina – on my system at least – takes little longer than a regular startup. If you experience any different, please let me know.

One major task which appears in Safe Boots is a thorough rebuild of OpenDirectory databases. This is heralded by the log entry:
6.504643 opendirectoryd Safe boot is enabled

Every startup is followed by a quick clean-up of temporary files, which is performed by the Directory Helper:
6.516512 dirhelper Cleaning T/ older than 3 days
6.516518 dirhelper Cleaning TemporaryItems older than 3 days

Another new and important service which takes note of the Safe Boot is Endpoint Security:
6.517115 endpointsecurityd Safe Boot mode detected
As this subsystem is so new, and little-used still, the implications of this aren’t clear yet.

Shortly after that, the OpenDirectory rebuild swings into action, with a great many log entries such as
6.816245 opendirectoryd PlistFile Database '/private/var/db/dslocal/nodes/Default/sqlindex' passed integrity check
6.816455 opendirectoryd PlistFile Database closing '/private/var/db/dslocal/nodes/Default/sqlindex'
6.816568 opendirectoryd PlistFile Database removed '/private/var/db/dslocal/nodes/Default/sqlindex' along with journal file
6.823589 opendirectoryd PlistFile re-indexing '<private>' with type 'computers'
6.833248 opendirectoryd PlistFile re-indexing '<private>' with type 'users'

repeated many times, progressing through sharepoints, config and groups.

Many of the caches which are cleared as user-specific, so don’t appear until after login. That process is marked by distinctive entries such as
loginwindow main | Login Window Application Started
loginwindow -[SessionStateMonitor setLoginState:] | ************* login state: InitialStartup

Unfortunately, once user processes start up, finding anything among them to indicate specific caches being cleared is like looking for a needle in a haystack. When I have plenty of time (!), and fancy browsing the 58 MB of log entries again, I may revisit this. But I have no reason to doubt Apple’s claim that various user caches are cleared.

To return to Apple’s original list of what happens in Safe Mode, as far as Catalina goes:

  1. if any verification of the boot Volume Group does take place (which doesn’t appear to be the case), it’s performed in secret;
  2. it blocks the loading of many kernel extensions (listed below), startup and login items, and user-installed fonts;
  3. it deletes font caches, the kernel cache (which I think is started afresh on the VM volume anyway), and other system caches;
  4. it rebuilds OpenDirectory databases.

Appendix: List of Kernel Extensions Which Aren’t Loaded in Safe Mode (10.15, 10.15.1)

AppleCameraInterface.kext – this means a built-in camera can’t be used
AppleThunderboltEDMService.kext – these may prevent use of some Thunderbolt devices
eficheck.kext – this means that firmware integrity checks aren’t performed on non-T2 models
msdosfs.kext – this makes the Mac unable to access MS-DOS file systems
and user-installed kernel extensions. Apple hasn’t yet explained what will happen with loading of its new ‘SEXTs’, but I suspect that they too will be blocked.