macOS 10.13.6 'High Sierra' guest VM versus Security Update 2020-005

Discussions about using Mac OS X guests (on Apple hardware) in VirtualBox.
Post Reply
paulmc
Posts: 72
Joined: 28. Aug 2019, 18:43
Primary OS: Mac OS X other
VBox Version: VirtualBox+Oracle ExtPack
Guest OSses: Mac OS X, Linux, Windows
Location: Earth (Guyana / USA / South Africa)
Contact:

macOS 10.13.6 'High Sierra' guest VM versus Security Update 2020-005

Post by paulmc »

Recently, there have been many reported problems after applying Security Update 2020-005 ('Mojave') to even physical Macs running macOS 10.14.6 'Mojave', depending on whether the companion Safari 14.0 update was installed first. Fortunately, Apple has since resolved these problems by issuing a subsequent patch.

This post is a heads-up about a different set of issues that might arise when applying Security Update 2020-005 ('High Sierra') to a macOS 10.13.6 'High Sierra' guest VM, in VirtualBox 6.1.16. Typically, there could be an inability to boot when the installation process first tries to restart, leading to just a prohibitory ('no entry') symbol or a blank screen with no progress indication, etc. Indeed, I was bitten by this very problem (a prohibitory symbol upon restart) when recently attempting to apply that update to my otherwise up-to-date 'High Sierra' guest VM! {I didn't investigate deeply, so I'm not sure whether Apple has introduced a new incompatibility with VBox's EFI emulation, or there's some other underlying cause.}

If your macOS 10.13 guest VM has been affected by this kind of problem, then there's a fairly straightforward workaround available. Recall that it has long been possible to apply a Security Update from a downloaded standalone disk image file ('.dmg') onto a volume other than the current boot one, as long as they have the same macOS major version installed.

There are a number of techniques with a VBox VM to achieve this installation onto a non-boot volume, but here's one way that allows having all the GUI convenience of the Finder, System Preferences and so on {BTW, in the procedure below, I'm assuming the use of the HFS+ file system (i.e., no APFS nor Core Storage) throughout, as that's what I currently use in my older Mac Pro 2012 tower system, whether for physical or virtual volumes (and I don't yet have any 'Mojave' or later guest VMs); no doubt, appropriate adjustments could be made for other file systems or logical volume schemas as needed}:

Prerequisites
  1. Your 'High Sierra' (HS) guest VM, back in working order {e.g., restored from backup, or a prior snapshot}.
  2. The official 'Security Update 2020-005 (High Sierra)' standalone disk image, downloaded from Apple's Support Downloads site.
  3. A secondary HS virtual bootable disk, e.g., obtained in one of the following ways:
    • If there's another working HS guest VM, then (in its Settings) detach its boot disk file ('.vdi', etc.) from the SATA controller.
    • Or, make a clone of your HS guest VM's boot disk file, either via the GUI VBox Manager's Tools section (or Virtual Media Manager)'s 'Copy' button, or with a 'VBoxManage clonemedium …' command in the Terminal utility.
    • Or, make a brand new HS boot disk via any working recent macOS guest VM, by (in its Settings) creating & attaching a new virtual disk, starting up that VM, installing mac OS 'High Sierra' onto that new disk from scratch, closing the VM, and detaching the new (now bootable) disk.
Procedure
  1. In your HS guest VM's Settings, attach that other HS bootable disk file as secondary SATA storage.
  2. Boot your HS guest VM from that secondary disk. {If instead it starts from the original boot disk, then either: (A) under VBox 6.1.x, just use the 'Startup Disk' pref pane to choose that secondary disk (NVRAM settings are now persistent in VBox 6.1.0+) and reboot; or, (B) reboot & immediately keep pressing practically any non-modifier key to drop into the EFI Boot menu, choose 'Boot Maintenance Manager > Boot From File', select that secondary disk (likely the third listed HFS+ entry but might involve some guesswork), and then its 'System > Library > CoreServices > boot.efi' file.}
  3. Once booted from that secondary disk, simply mount the downloaded Security Update disk image, open the Security Update package file, select your HS guest VM's original disk as the target when prompted, and proceed with the installation.
  4. Reboot your HS guest VM from its now-updated original disk (reselecting it via 'Startup Disk' if you'd switched it earlier), and in the Finder verify that the update was successful by inspecting the OS build number {i.e., in the 'About This Mac' dialogue, click on the macOS version to reveal the build number, which in this case should be '17G14033'}.
  5. If desired, you could also now similarly apply the Security Update onto that (now non-boot) secondary disk too.
  6. In your closed HS guest VM's Settings, detach that secondary disk (and re-attach it to the other HS guest VM if applicable).
Alternatively, if your HS guest VM's original boot disk does have an intact Recovery volume, it should be possible to just restart from that {e.g., via the EFI Boot menu, choose 'Boot Maintenance Manager > Boot From File', select the Recovery partition (should be the second listed HFS+ entry), and then its 'com.apple.recovery.boot > boot.efi' file}, and then apply the Security Update package file onto your original boot volume in a similar manner {although, since the Finder's GUI convenience wouldn't be available, the package file would need to have been copied out from the mounted disk image in the Finder beforehand, or the disk image would now need to be mounted with an 'hdiutil attach …' command in the Terminal utility to obtain the package file, etc.}.

Or again, if your HS guest VM's original boot disk happens to already have a secondary HS bootable partition, then of course that could be used (via 'Startup Disk' or the EFI Boot menu) instead of the secondary disk described above.

Good luck to everyone.

{P.S.: Interestingly, there have been some reports of related problems occurring with this Security Update and even physical Macs too, especially older models. {Although, luckily I didn't have any problems applying it to either of my Mac Pro 2012 tower's two physical 'High Sierra' volumes, in one case applied normally as the current boot via the Mac App Store, and in the other case applied as a non-boot.} For example, see the following threads in Apple's Support Communities: The advice given tended to be along the lines of installing via an official standalone Security Update disk image (downloaded from Apple's Support Downloads site), while started up in Safe Boot mode.}

[Edited shortly after initial posting, to clarify some aspects of my older Mac Pro 2012 tower system, and my own luckier experience with physical volumes (in the PostScript section).]
Post Reply