Rebuilding your macOS Recovery volume or partition with create_macos_recovery
I recently got an email from a former colleague, requesting assistance with a problem they were seeing. They were cloning drives with macOS Catalina, but their cloning process was not including the Recovery volume. Was there a way to create a new Recovery volume on a macOS Catalina boot drive that didn’t have one?
I did some research on this and found that there was a script to do this on High Sierra and Mojave, but it didn’t appear to work anymore.
With some more digging, I was able to figure out why. The script was downloading and expanding a macOSUpd10.13.6.RecoveryHDUpdate.pkg installer package from Apple’s Software Update service in order to get access to a dm tool included with the installer package. This installer package was no longer available from the Software Update service, but a similar package named SecUpd2019-005HighSierra.RecoveryHDUpdate.pkg with the same dm tool was available.
Once I verified that I could get the same results using the SecUpd2019-005HighSierra.RecoveryHDUpdate.pkg installer package, I wrote a script (based on the original one I had found) to help automate the process of rebuilding a macOS Recovery volume or partition. For more details, please see below the jump.
Suppressing the Screen Time pop-up window with a profile on macOS Catalina
Apple has introduced a number of pop-up windows in various OS versions, which appear the first time you log into a Mac and sometimes also after OS updates. For macOS Catalina, Apple has introduced one for Screen Time.
To stop the Screen Time pop-up window from appearing for your home folder, run the command shown below:
defaults write com.apple.SetupAssistant DidSeeScreenTime -bool TRUE
Since you normally will be able to run this command only after you’ve seen the Screen Time pop-up window, I’ve posted a profile for suppressing it. For more details, please see below the jump.
Managing macOS Catalina’s FileVault 2 with fdesetup
Since its initial release in OS X Mountain Lion 10.8.x, Apple’s main tool for managing FileVault 2 encryption has been fdesetup. With the transition from managing Core Storage-based encryption on HFS+ to managing the native encryption built into Apple File System completed, this well-developed toolset continues to be Apple’s go-to tool for enabling, configuring and managing FileVault 2 on macOS Catalina.
With its various functions, fdesetup gives Mac administrators the following options for managing FileVault:
- Enable or disable FileVault 2 encryption on a particular Mac
- Use a personal recovery key, an institutional recovery key, or both kinds of recovery key.
- Enable one or multiple user accounts at the time of encryption
- Get a list of FileVault 2-enabled users on a particular machine
- Add additional users after FileVault has been enabled
- Remove users from the list of FileVault enabled accounts
- Add, change or remove individual and institutional recovery keys
- Report which recovery keys are in use
- Perform a one-time reboot that bypasses the FileVault pre-boot login
- Report on the status of FileVault 2 encryption or decryption
For more details, please see below the jump.
Certificate used to sign older Apple software expiring on October 24, 2019
On February 10, 2015, a number of Mac admins noticed that Apple was re-issuing a number of software updates. The updates themselves hadn’t changed, but were being reposted.
The reason was because part of the chain of certificates Apple was using to sign installers used by Apple’s software updates was expiring on February 14th, 2015.
The new expiration date was set as October 24, 2019 at 1:27 PM US Eastern Daylight Time, which is eight days from the date of this post.
Time marches on and once again, Apple is re-signing and re-issuing updates ahead of the October 24th 2019 expiration date.
It looks like the re-signed installers have an expiration date of April 14th, 2029 at 5:28 PM US Eastern Daylight Time.
The certificate expiration will also affect macOS installers or boot media that are signed with the certificates which expire on October 24th. In testing by @neilmartin83, these installers will not work properly following the certificate expiration.
Apple will also be re-signing these installers though, so the fix in most cases will be to download new copies of the relevant macOS installers from the Mac App Store or Software Update.
The macOS user template directories have a new filesystem location on macOS Catalina
New users on a Mac have a certain set of default settings which are copied into their user profiles the first time they log in. Starting with Mac OS X 10.0.0, these settings have been stored in the following location:
/System/Library/User Template
Inside the User Template directory are a number of language-specific directories where the default settings for various languages are stored. This allows the new user’s default settings to be appropriate for their language and keyboard configuration.
As of macOS Catalina 10.15.0, the location of the User Template directory has changed to the following:
/Library/User Template
The reason for the change is that the /System directory is now stored in Catalina’s read-only volume for the OS. By moving it to /Library, the User Template directory and its enclosed language-specific directories remain readable and writable for those folks who prefer to deploy settings by making changes to the user template directories.
Enabling root on a Mac which hasn’t gone through macOS Catalina’s Setup Assistant
On certain occasions, it may be necessary to configure settings on a Mac which has not yet gone through Apple’s Setup Assistant. This process usually involves enabling the root account and setting a password for it, since no user accounts with admin rights exist yet. For more details on how to do this on macOS Catalina, please see below the jump.
Most Apple apps installed with the OS have a new filesystem location
Starting with Mac OS X 10.0.0, Mac apps have traditionally been installed into /Applications or /Applications/Utilities. It appears to be the same on macOS Catalina, but appearances can be deceiving.
As part of implementing a read-only volume for the OS, Apple has moved the apps it installs along with the OS from /Applications to a new location on the read-only volume: /System/Applications
For operations in the Finder, this move won’t make a lot of difference because Apple has made sure that the applications in question still appear in /Applications and /Applications/Utilities.
However, if a script or other command line tool is referencing an app in /Applications or /Applications/Utilities, the new /System/Applications and /System/Applications/Utilities path must be referenced. In my case, I ran across this as part of a script that as part of its work was referencing the Keychain Access app in the following location:
/Applications/Utilities/Keychain Access.app
The script failed because Keychain Access is no longer available at that location on macOS Catalina. To fix this, I updated the script to use the following location:
/System/Applications/Utilities/Keychain Access.app
Once that was done, the script ran without problems again.
This new location on the read-only volume only applies to apps which Apple installs as part of the OS or which are only updated by OS updates. For example, because Safari may be installed or updated separately, the Safari app is not located on the read-only volume in /System/Applications. Instead, Safari remains in /Applications as /Applications/Safari.app.
Recent Comments