Installing macOS on external bootable disks connected to Apple silicon Macs has been one of the most frustrating experiences of my life, and has driven some more experienced than me to abandon their attempts altogether. The latest bug in this was reported by Michael Tsai earlier this week, and can prevent you from installing any version of macOS prior to Sequoia, on an external disk connected to an Apple silicon Mac running macOS 15.3.2, and likely earlier versions of Sequoia.

To reproduce this, I partitioned an external 2 TB SSD connected to my MacBook Pro M3 Pro, which originally shipped with Sonoma 14.1. I have on many occasions installed macOS on that SSD for use with Apple silicon Macs, and hadn’t had a failure with it. To ensure favourable winds, I connected the SSD to the USB-C port at the right of the left side of the case, which isn’t the designated DFU port.

Apple disables installers for previous major versions of macOS from running in more recent versions. Trying to run a Sonoma installer in Sequoia is therefore doomed to fail. Instead, the installer has to be converted into a bootable installer volume, and the Mac booted from that to perform the installation. Although you can use a USB ‘thumb’ drive for that purpose, I prefer to use a 100 GB partition on a convenient external disk, in this case the same SSD on which macOS was to be installed. One of the quirks of bootable installers is that they must still use HFS+ rather than APFS, hence they get a partition of their own.

The three partitions I created were:

• APFS container with two APFS case-insensitive unencrypted APFS volumes in 900 GB
• APFS container with one APFS case-insensitive unencrypted APFS volume in 1 TB
• HFS+ Journaled volume in 100 GB.

I used two Sonoma full installer apps, one for 14.6.1 taken from my library, the other for 14.7.4 freshly downloaded from Apple, both installed from InstallAssistant packages into /Applications. Each was successfully installed individually into the HFS+ volume on the external SSD following the instructions given by Apple.

In each test, I entered the external installer from Recovery mode as detailed by Apple, and started installation to one of the two APFS volumes in the first APFS container on the external SSD. After long periods attempting the installations, both failed with exactly the same error reported by Michael Tsai: com.apple.OSinstallerSetup.error error 702

Between the two attempted installations, both the HFS+ volume and the destination APFS container were erased and set up again. Following those two failures, I successfully installed macOS 15.2 and 15.3.2 direct to the three APFS volumes on the external SSD without any problems, and verified that all three Sequoia installations had been completely successful.

I therefore conclude that, in Sequoia 15.3.2 at least, it’s not possible to install any version of macOS prior to Sequoia 15.0 on an external SSD connected to an Apple silicon Mac. If your experience differs, then please let me know how you did it.

Michael Tsai appears to have been successful only when running the installation from Sonoma. If you do need access to a non-virtualised installation of Sonoma or earlier, it appears the only way you’re likely to succeed is from Sonoma, which would require you to perform a full DFU Restore to revert the Mac to macOS 14.

Useful tricks

• The Mac must be capable of running that version of macOS.
• The external disk must be connected to a port other than the DFU port.
• When installing an older major version of macOS, perform this from an external bootable HFS+ volume as detailed by Apple.
• Use an HFS+J partition on an external SSD rather than a USB ‘thumb’ drive.
• Boot from the installer volume through Recovery mode.
• When using a laptop model, run it from mains power throughout macOS installation.
• If essential, you can revert the Mac’s internal SSD to an older version of macOS and firmware using a full DFU Restore with an appropriate IPSW image file.
• Use a Virtual Machine instead, if you don’t need to be able to run software from the App Store.

This week’s new features in my lightweight log browser LogUI tackle two important areas: initial checks to confirm that the app can access the log, and improving the filtering of log entries using predicates.

LogUI has three key requirements:

• that the Mac is running macOS 14.6 or later, as enforced by macOS;
• that it’s run from an admin account, as that has the privileges required to access the log;
• that there are log records it can access in the path /var/db/diagnostics, as without those it hasn’t got anything to work with.

LogUI 1.0 build 31 now contains code to check the latter two, run soon after launch. If either fails, you’ll see an informative alert, and the app will quit when you click to dismiss that.

LogUI now has internal features to support a wide range of filters that can be applied when fetching log entries. These are an essential means of reducing the number of entries displayed, and of focussing your attention on what’s important.

This is reflected in its Settings, which now refer to Text rather than a Subsystem. The window toolbar now has a Predicate popup menu, and its text box is labelled text rather than Subsystem.

This menu offers the following options:

• none, which applies no filtering and displays all log entries;
• subsystem, which uses the text entered as the name of the subsystem whose entries are to be displayed, as in the previous builds;
• eventMessage, which shows only those log entries whose message contains the text entered;
• processImagePath, which shows only entries whose process name (or path) contains the text entered;
• [Edit], which in future will open an on-the-fly predicate editor, but currently doesn’t filter;
• TimeMachineBasic to blowhole, which use set predicates to display log entries for those features. The first two are different levels of detail for Time Machine backups, error finds entries with that word in their message, kernel finds entries with the kernel as their process, and blowhole finds entries made by my command tool for writing entries in the log.

Text entered is not case-sensitive.

Although it’s currently possible to change and extend those, that involves delicate surgery to LogUI’s preferences Property List, and I don’t intend you to hack that just yet. The next features will provide a proper editor in LogUI’s Settings, and the on-the-fly editor accessed through this menu.

Otherwise LogUI should work just the same as the last build. These new features are documented in its Help book, a separate copy of which is supplied in its Zip archive.

LogUI 1.0 build 31 is now available from here: logui131
and I will shortly be giving it an entry in my log browser Product Page, to make it easier to access. I’m also looking at building an auto-update mechanism into it.

Please let me know how you get on with this, and whether it proves useful to you. Enjoy!

Last week’s security updates to macOS have left some confusion over version numbers, and firmware for T2 Macs. This article attempts to clarify what happened, and where supported versions of macOS are going next.

Security updates 11 March 2025

Apple released:

• macOS 15.3.2 Sequoia
• Safari for macOS 14.7.4 Sonoma
• Safari for macOS 13.7.4 Ventura.

There were no security updates for Sonoma or Ventura other than their Safari updates.

There was also a firmware update included in the 15.3.2 update, changing the version of iBridge firmware in the T2 chip of Intel Macs from 22.16.13051.0.0,0 to 22.16.13060.0.0,0. There were no firmware updates for Apple silicon Macs, nor for Intel models without T2 chips, I understand.

Sequoia

If your Mac is running macOS Sequoia and has been updated, it should now be running 15.3.2 (build 24D81). If it has a T2 chip, it should have updated its firmware to read
EFI 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0)

Safari should be version 18.3.1 (20620.2.4.11.6).

Sonoma

If your Mac is running macOS Sonoma and has been updated, it should still be running 14.7.4 (build 23H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Safari should have been updated to version 18.3.1 or 18.4 (19621.1.14.11.3, 19621).

Ventura

If your Mac is running macOS Ventura and has been updated, it should still be running 13.7.4 (build 22H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Safari should have been updated to version 18.3.1 or 18.4 (18621.1.14.11.3, 18621).

SilentKnight

To keep a complex situation as simple as possible, SilentKnight only considers one firmware version to be current for each model of Mac. If it tried anything more complex, I’d not be able to cope. As there are presently two different ‘current’ and supported versions of T2 firmware in use, SilentKnight goes with the older one. That way it doesn’t complain, but politely remarks for Sequoia 15.3.2:
EFI version found 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0) ;
expected 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Please bear with me until Apple resyncs T2 firmware across the three supported versions of macOS. I’m sure that will return with the release of 15.4, 14.7.5 and 13.7.5. If not, we can all scream together.

Sonoma 14.7.5 and Ventura 13.7.5

Many have been reporting that their Macs have been updated to 14.7.5 or 13.7.5, and some have claimed that those versions have been released by Apple. They are in fact beta-releases of the next scheduled updates to Sonoma and Ventura, and haven’t yet been generally released. If your Mac is running one of those, you might like to check it against recent beta-releases:

• 21 February 2025 betas: Sonoma 14.7.5 (23H510), Ventura 13.7.5 (22H510)
• 10 March 2025 betas: Sonoma 14.7.5 (23H520), Ventura 13.7.5 (22H520)
• 17 March 2025 betas: Sonoma 14.7.5 (23H525), Ventura 13.7.5 (22H525)

App Store full installers

If you download a full installer from the App Store or elsewhere, the current releases are:

• Sequoia 15.3.2 (build 24D81)
• Sonoma 14.7.4 (build 23H420), which will then need Safari updated
• Ventura 13.7.4 (build 22H420), which will then need Safari updated.

How has this happened?

Normally, when the current version of macOS has a security update, the two older versions that are still supported have matching security updates. That would have brought 14.7.5 and 13.7.5 along with 15.3.2. However, in this case the patch to be applied could be supplied in a Safari update for the older two. As that’s much smaller and simpler than a full macOS update, Apple opted to supply those as Safari updates alone, which can’t of course be a new version of macOS.

This is possible because Safari and some of its supporting frameworks and components aren’t part of the Signed System Volume, so updating them doesn’t require the System volume to be rebuilt, turned into a snapshot, and installed as a new Signed System Volume.

However, firmware updates can only be supplied and installed as part of a full macOS update, so it was only possible to update T2 firmware in Sequoia systems being updated the long way to 15.3.2.

I hope this dispels any remaining confusion.

I’m grateful to ExcleX for pointing out that Safari versions can vary according to when you updated.