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
- Your 'High Sierra' (HS) guest VM, back in working order {e.g., restored from backup, or a prior snapshot}.
- The official 'Security Update 2020-005 (High Sierra)' standalone disk image, downloaded from Apple's Support Downloads site.
- 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.
- In your HS guest VM's Settings, attach that other HS bootable disk file as secondary SATA storage.
- 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.}
- 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.
- 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'}.
- If desired, you could also now similarly apply the Security Update onto that (now non-boot) secondary disk too.
- In your closed HS guest VM's Settings, detach that secondary disk (and re-attach it to the other HS guest VM if applicable).
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:
- 'On my iMac with HIgh Sierra 10.13.6 the update would notinstall and I could not restart my computer until I restored it from a backup disc. Has anyone else had this problem?' [Apple SCs > … > macOS High Sierra; 2020-09-27]
- 'Unable to boot after 2020-005' [Apple SCs > … > macOS High Sierra; 2020-09-27]
- 'Macbook Pro 17 inch late 2011 installed latest High Sierra 2020-05 security update.' [Apple SCs > … > macOS High Sierra; 2020-09-29]
- 'Security Update 2020-05 has made my Mac unusable. it won’t finish the boot cycle after 30 minutes (so far).' [Apple SCs > … > macOS High Sierra; 2020-09-29]
[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).]