Errors Deploying 10.13.3 Combo Update

[ammonsc]

I am having issues deploying the 10.13.3 Combo Update.

Loaded the combo .pkg into Jamf Admin

Tried creating policy to install and it just fails
Created Policy to Cache Package then install same issue as before
Created Cache Policy and the Install policy that runs the command

installer -pkg /Library/Application Support/JAMF/Waiting Room/macOSUpdCombo10.13.3.pkg -target /```

That ran fine on one machine but on another machine it fails with

Result of command:<br/>installer: Package name is macOS High Sierra 10.13.3 Update Combo<br/>installer: Upgrading at base path /<br/>installer: The upgrade failed.

How is everyone else deploying this?

[ammonsc]

If I try to install via the package in a policy or in a policy as a cached package I get the same error every time. It states:

Installation failed. The installer reported: installer: Package name is macOS High Sierra 10.13.3 Update Combo<br/>installer: Upgrading at base path /<br/>installer: The upgrade failed.

[PhillyPhoto]

I put it in Self Service, and mine says the .pkg file installed fine, but my test machine still says it's 10.13.0....

Wed Jan 24 14:36:59 MYMACBOOK jamf[49441]: Checking for policy ID 123...
Wed Jan 24 14:37:02 MYMACBOOK jamf[49441]: The management framework will be enforced as soon as all policies are done executing.
Wed Jan 24 14:37:02 MYMACBOOK jamf[49441]: Executing Policy macOS High Sierra 10.13.3 Combo Update
Wed Jan 24 14:38:11 MYMACBOOK jamf[49441]: Verifying package integrity...
Wed Jan 24 14:38:16 MYMACBOOK jamf[49441]: Installing macOSUpdCombo10.13.3.pkg...
Wed Jan 24 14:38:49 MYMACBOOK jamf[49441]: Successfully installed macOSUpdCombo10.13.3.pkg.
Wed Jan 24 14:39:09 MYMACBOOK jamf[49441]: Blessing i386 OS X System on /...

The machine reboots, but the upgrade doesn't show up.

[gmce87]

@ammonsc I get the same issue, tried deploying to five machines so far and all five failed the first time, however if I flushed each machine they tried again and it worked this time.

Two machines had this in Self Service, the other three are just from a recurring check-in policy. I'm pushing out to several more machines currently to see if this is happening to all of them.

My machines are all update to date, including the 10.13.2 supplemental update recently, although I think I have a few machines still lagging behind, so I'm about to try deploy to those and see if there's any difference.

[PhillyPhoto]

Mine seems to have worked the second time around. I noticed that the Startup Disk was "Current Startup Disk", but haven't had a problem using this in the past. I wonder if it has to be set to "macOS Installer" to work properly. I'll try some other devices tomorrow.

Of course selecting "macOS Installer" results in the following warning:

If "macOS Installer" is chosen as the Startup Disk, Restart Options on this pane will not be applied to computers with macOS 10.12.4 or later.

[StoneMagnet]

Are people using a Restart Options payload to initiate a restart after the update applies? If so, have you tried using "Currently Selected Startup Disk (No Bless)" as the Startup Disk setting rather than the default "Current Startup Disk" so that the payload doesn't step on any startup changes the installer may make?

[gmce87]

@StoneMagnet I've tried that and get the same result unfortunately.

[bentoms]

This actually came up on munki-discuss too, with @gregneagle replying:

Nothing new to offer you except this: https://support.apple.com/kb/DL1953?viewlocale=en_US&locale=en_US Which update should I install? Choose the macOS High Sierra 10.13.3 update that corresponds to your Mac: If you have an iMac Pro, please install the macOS High Sierra 10.13.3 iMac Pro Update. If you have another Mac computer running macOS High Sierra 10.13.2, please install the macOS High Sierra 10.13.3 Update. If you have another Mac computer running macOS High Sierra 10.13 or 10.13.1, please install the macOS High Sierra 10.13.3 Combo Update. IOW, Apple doesn't recommend installing the Combo Update on computers running macOS High Sierra 10.13.2. I don't know if that's the actual issue here, though. -Greg

And:

I replicated your issue without Munki being involved. I ssh'd into a Mac running 10.13.2 and installed the package while the machine was at the login window:

installer -pkg /Volumes/macOS High Sierra 10.13.3 Update Combo/macOSUpdCombo10.13.3.pkg -target /

installer: Package name is macOS High Sierra 10.13.3 Update Combo installer: Upgrading at base path / installer: The upgrade was successful. installer: The install requires restarting now. humantorch:Downloads root# shutdown -r now Shutdown NOW! FINAL System shutdown message from root@humantorch.com System going down IMMEDIATELY After reboot I ssh'd back in and the OS version is unchanged.

sw_vers

ProductName: Mac OS X ProductVersion: 10.13.2 BuildVersion: 17C205 So this is not a Munki issue, really. This is an Apple package being installed in a way Apple did not consider or test for. I think if you manually install this package in a GUI session it sets up things that are supposed to be triggered at logout. Munki logs out first and then installs the package, and then restarts. So the "things" never get triggered. I think you'll need to stick with the softwareupdate method of doing this update. -Greg

So... appears to be a change from Apple's end in regards to the combo updaters

[ammonsc]

Because of issues we see with our proxy that I have yet to figure out it is better for me not to use Software Update so what if instead of using installer I could just force the package to open in the GUI and let the user proceed from there. Issuing this instead.

open /Library/Application Support/JAMF/Waiting Room/macOSUpdCombo10.13.3.pkg

[gmce87]

After reading @bentoms post above, I've downloaded the macOS High Sierra 10.13.3 Update instead of the Combo Update, as 90% of our estate is on 10.13.2, however I'm getting the same mixed results when deploying. Some devices complete the first time, but most still fail with the same "installer: Upgrading at base path /<br/>installer: The upgrade failed" error, until you flush the failed jobs and try again.

[PhillyPhoto]

@bentoms I installed the combo update through a policy on a 10.13.0 machine. It didn't actually upgrade until the second attempt.

[gbourse]

hi guys,

we have found the solution for deploying and installing (macOSUpdCombo10.13.3.pkg)
here are the steps to follow : - create a DMG with composer. (the pkg is localized in users/shared)
- create a policy with a DMG
- create a new policy with a payload Files and Processes "execute command line" (installer -pkg /Users/Shared/macOSUpdCombo10.13.3.pkg -target /)

it's working with self-service

Gael

[dpertschi]

@gbourse With that, how are you doing the restart? Is the user doing so manually or are are you using the Restart payload in the policy and getting the update to kick off properly during the reboot?

The High Sierra nightmares just keep coming. I can't believe this.
Installing the .pkg directly, if I use shutdown -r now it reboots and installs properly the first time, but the policy logs never update to show completed because the abrupt reboot prevents the policy from reporting back to the JSS. Grrrrr!

[gbourse]

hi dpertschi,

with the self service the post restart automatically
without the self service I have to perform a manual restart and a popup appears
exactly with the shutdown -r the installation is not done

[ClassicII]

For this update you do not need to add a reboot policy. The installer will reboot the machine automatically and do a FV2 authenticated reboot.

We had an issue where before the machine rebooted it got stuck at trying to reboot and the black screen progress bar status "Installing Software Update" at 10%.

Ended up being the com.jamfsoftware.jamf.daemon.plist preventing the restart.

[dpertschi]

@ClassicII Like a (not very fun) game of whack-a-mole: Self Serve policy does nothing more than install the combo update package, but then Self Serve blocks the packages auto reboot.

[donmontalvo]

If not FV2 encrypted, this gets it done:

softwareupdate --install --recommended && shutdown -r now

Of course Recon On Reboot would be most welcome under this scenario.

¯_(ツ)_/¯

Now if we can only get this Jamf feature to play nice with these updates that boot into Runtime...

http://docs.jamf.com/9.101.0/casper-suite/administrator-guide/Policy_Payload_Reference.html

[PhillyPhoto]

Of course Recon On Reboot would be most welcome under this scenario.

May I suggest my feature request for this exact issue @donmontalvo?

[donmontalvo]

@PhillyPhoto thanks, and yes happy to vote up your feature request!

Currently we have two packages, one that runs on every reboot (creates a launch daemon, runs recon, deletes the launch daemon), and one that runs on every login (creates a launch agent, runs recon, deletes itself)...definitely would like to see this functionality built in to Jamf Pro.

[CAJensen01]

Have been seeing this on at least one device, too. Here's the install.log

2018-02-01 11:23:11-05 admins-mbp installer[1204]: JS: my.target.isDisallowedForCoreStorageOperations = false
2018-02-01 11:23:11-05 admins-mbp installer[1204]: JS: my.target.isDisallowedForCoreStorageOperations = false
2018-02-01 11:23:11-05 admins-mbp installer[1204]: Product archive /Library/Application Support/JAMF/Waiting Room/macOSUpdCombo10.13.3.pkg trustLevel=501
2018-02-01 11:23:11-05 admins-mbp installer[1204]: Will do post-logout install for package with trust 501
2018-02-01 11:23:11-05 admins-mbp installer[1204]: Starting post logout install with document at path /Library/Application Support/JAMF/Waiting Room/macOSUpdCombo10.13.3.pkg
2018-02-01 11:23:11-05 admins-mbp installer[1204]: Product archive /Library/Application Support/JAMF/Waiting Room/macOSUpdCombo10.13.3.pkg trustLevel=501
2018-02-01 11:23:11-05 admins-mbp softwareupdated[768]: Adding client SUUpdateServiceClient pid=1204, uid=0, installAuth=NO rights=(), transactions=0 (/usr/sbin/installer)
2018-02-01 11:23:11-05 admins-mbp system_installd[1215]: installd: Starting
2018-02-01 11:23:11-05 admins-mbp system_installd[1215]: installd: uid=0, euid=0
2018-02-01 11:23:11-05 admins-mbp system_installd[1215]: PackageKit: Adding client PKInstallDaemonClient pid=768, uid=200 (/System/Library/CoreServices/Software Update.app/Contents/Resources/softwareupdated)
2018-02-01 11:23:11-05 admins-mbp softwareupdated[768]: Attempting to adopt manual product: macOS High Sierra 10.13.3 Update Combo
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: JS: my.target.isDisallowedForCoreStorageOperations = false
2018-02-01 11:23:13-05 admins-mbp suhelperd[771]: Verifying package at path: /Library/Updates/_ManualUpdate/macOSUpdCombo10.13.3.pkg
2018-02-01 11:23:13-05 admins-mbp suhelperd[771]: packageWithPath returned nil!
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: SoftwareUpdate: Preparing bridgeOS update for manual product at /var/folders/zz/zyxvpxvq6csfxvn_n00000s0000068/C/softwareupdated/com.apple.SoftwareUpdate/localhost/AdoptedManual/macOSUpdCombo10.13.3.pkg
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: Token successfully added to approvedStashingTokens set.
2018-02-01 11:23:13-05 admins-mbp installer[1204]: ManualAdoption: Adopted /Library/Application Support/JAMF/Waiting Room/macOSUpdCombo10.13.3.pkg
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: Adding client SUUpdateServiceClient pid=1223, uid=0, installAuth=NO rights=(), transactions=0 (/System/Library/PrivateFrameworks/SoftwareUpdate.framework/Versions/A/XPCServices/ManualProductStasherService.xpc/Contents/MacOS/ManualProductStasherService)
2018-02-01 11:23:13-05 admins-mbp system_installd[1215]: PackageKit: Adding client PKInstallDaemonClient pid=768, uid=200 (/System/Library/CoreServices/Software Update.app/Contents/Resources/softwareupdated)
2018-02-01 11:23:13-05 admins-mbp installer[1204]: ManualAdoption: Authorization established successfully for ManualProductStasherService
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: Token consumption request is valid and is found in the trusted cache set, stashing permitted!
2018-02-01 11:23:13-05 admins-mbp installer[1204]: ManualAdoption: Stashing succeded! 2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: Successfully holding Pre-logout Display sleep assertion for 15 minutes

2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: SULocalProduct: _ManualUpdate is not completely downloaded (7 remaining).  Package(s) <PKDistributionPackageReference com.apple.pkg.BridgeOSUpdateCustomer>, <PKDistributionPackageReference com.apple.update.fullbundleupdate.17D47>, <PKDistributionPackageReference com.apple.pkg.macOSUpdCombo10.13.3.RecoveryHDUpdate.17D47>, <PKDistributionPackageReference com.apple.pkg.FirmwareUpdate>, <PKDistributionPackageReference com.apple.pkg.update.os.Combo10.13.3.17D47>, <PKDistributionPackageReference com.apple.pkg.EmbeddedOSFirmware>, <PKDistributionPackageReference com.apple.pkg.BridgeOSBrain> not found:

2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: Cannot register _ManualUpdate for post-logout install since not fully downloaded
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: Set products to install at logout: No products to install
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: We didn't register all updates for post-logout
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: No products remaining for post-logout - aborting post-logout install.
2018-02-01 11:23:13-05 admins-mbp installer[1204]: ManualAdoption: Error registering adopted product for post-logout install
2018-02-01 11:23:13-05 admins-mbp installer[1204]: Failed to adopt update: POST_LOGOUT_PREPARATION_FAILED
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: Removing client SUUpdateServiceClient pid=1204, uid=0, installAuth=YES rights=(system.install.apple-software, system.install.software, com.apple.SoftwareUpdate.modify-settings), transactions=0 (/usr/sbin/installer)
2018-02-01 11:23:13-05 admins-mbp softwareupdated[768]: Removing client SUUpdateServiceClient pid=1223, uid=0, installAuth=YES rights=(system.install.apple-software, system.install.software, com.apple.SoftwareUpdate.modify-settings), transactions=0 (/System/Library/PrivateFrameworks/SoftwareUpdate.framework/Versions/A/XPCServices/ManualProductStasherService.xpc/Contents/MacOS/ManualProductStasherService)

[CAJensen01]

@dpertschi

That isn't new behavior--have seen it since 10.13.1. I opened a case with JAMF about it and they just threw their arms up and said "well we're not going to make changes, we'll let admins solve this as they see fit." And then suggested I kill Self Service at the end of the install via command. So that's what I'm doing. It's sad to me that a vendor suggest that as an official workaround, ..but it works.

And then if you need to force the update I do a background killApps command right before the installer starts.

[CAJensen01]

Here's another log that gave me more info when the same situation was encountered. It almost looks like Apple hard-coded references to these packages, and if they're not downloaded/available, cannot complete the upgrade process.

softwareupdated[681]: SULocalProduct: _ManualUpdate is not completely downloaded (7 remaining). Package(s) { Identifier = "com.apple.pkg.BridgeOSUpdateCustomer"; MD5 = ""; Size = 0; URL = "file:///Library/Updates/_ManualUpdate/macOSUpdCombo10.13.3.pkg#BridgeOSUpdateCustomer.pkg"; Version = "10.13.3.1.1.1516347890"; }, { Identifier = "com.apple.update.fullbundleupdate.17D47"; MD5 = ""; Size = 0; URL = "file:///Library/Updates/_ManualUpdate/macOSUpdCombo10.13.3.pkg#FullBundleUpdate.pkg"; Version = "1.0.0.0.1.1516347890"; }, { Identifier = "com.apple.pkg.macOSUpdCombo10.13.3.RecoveryHDUpdate.17D47"; MD5 = ""; Size = 0; URL = "file:///Library/Updates/_ManualUpdate/macOSUpdCombo10.13.3.pkg#macOSUpdCombo10.13.3.RecoveryHDUpdate.pkg"; Version = "1.0.0.0"; }, { Identifier = "com.apple.pkg.FirmwareUpdate"; MD5 = ""; Size = 0; URL = "file:///Library/Updates/_ManualUpdate/macOSUpdCombo10.13.3.pkg#FirmwareUpdate.pkg"; Version = "10.13.3.1"; }, { Identifier = "com.apple.pkg.update.os.Combo10.13.3.17D47"; MD5 = ""; Size = 0; URL = "file:///Library/Updates/_ManualUpdate/macOSUpdCombo10.13.3.pkg#macOSUpdCombo10.13.3.pkg"; Version = "1.0.0.0.1.1516347890"; }, { Identifier = "com.apple.pkg.EmbeddedOSFirmware"; MD5 = ""; Size = 0; URL = "file:///Library/Updates/_ManualUpdate/macOSUpdCombo10.13.3.pkg#EmbeddedOSFirmware.pkg"; Version = "10.13.3.1.1.1516347890"; }, { Identifier = "com.apple.pkg.BridgeOSBrain"; MD5 = ""; Size = 0; URL = "file:///Library/Updates/_ManualUpdate/macOSUpdCombo10.13.3.pkg#BridgeOSBrain.pkg"; Version = "10.13.3.1.1.1516347890"; } not found:

[CasperSally]

It's worth reading this relevant discussion over on munki discuss. I read this as an apple issue, not a jamf or munki one. If you want to push out combo updates, it looks like the only way to do that would be via softwareupdate commands.

Obviously, caching the update locally is ideal. If you haven't already put in a ticket with apple support on how to do this, I would.

@donmontalvo can I mention your ticket number in my enterprise case from this other relevant thread

[donmontalvo]

@CasperSally wrote:

@donmontalvo can I mention your ticket number in my enterprise case from this other relevant thread

Yes thanks!

[CasperSally]

@donmontalvo am i missing the ticket number somewhere?

[CasperSally]

@ammonsc @donmontalvo @CAJensen01 I tested today caching the pkg installer.

In JSS, I navigated to settings, computer management, packages, clicked on macOSUpdCombo10.13.3.pkg and checked box for "requires restart."

Then created 2 policies, 1 for self service to install all cached packages, and one that installs all cached packages via login trigger.

Both updated ok to 10.13.3. Let me know if I'm missing something? The install took 20 minutes which means we'll have a hard time really deploying this in our few thousand macbook airs in laptop carts, but that's another story.

I did vote up the FR to add update inventory option on restart. Seems like if Jamf could offer a checkbox that also says to update inventory on install/restart that would make sense.

[donmontalvo]

@CasperSally sorry for the late response...

https://www.jamf.com/jamf-nation/discussions/27003/with-all-due-respect-to-our-wonderful-apple-rep-t...

[ThijsX]

Hi,

Anytips for the 10.13.4 installer / combo installer .pkg 's through Self Service?

[donmontalvo]

Jamf's position (at least when we open tickets about Combo Updates not getting past auth restart) has been to push the Full Installer.

It works.

[ammonsc]

@donmontalvo So you download the full 10.13.x installer from the App Store and push that instead of an update? That would at least lower the number of packages I would need.

[jimmy-swings]

Proxy?

https://support.apple.com/en-us/HT207567

This documentation highlights a few hostnames that need to be whitelisted through corporate proxies although in my testing there also some additional hostnames that also need to be added.

[gabester]

I ended up here because I'm trying to troubleshoot an issue installing High Sierra Security Update 2019-001 on some T2-equipped MacBook Pros which shipped with High Sierra and cannot migrate yet to Mojave... "packagewithpath returned nil" appears to be the start of my troubles but they continue with the likes of:

SoftwareUpdate: request for status for unknown product _ManualUpdate
bridgeOS prepare summary... "An error occurred during preflight."... NSUnderlyingError=0x7fe757ca0e10 {Error Domain=BridgeOSSoftwareUpdateError Code=19 "MSU - 2 (Failed to personalize with options.);MSU - 2 (Could not personalize boot/firmware bundle.);AMAI - 3099
SUBridgeOSUpdateManager repeats that... SoftwareUpdate: Error preparing bridgeOS update for manual product at /var/folders/zz/zyxvpxvq6csfxvn_n00000s0000068/C/softwareupdated/com.apple.SoftwareUpdate/localhost/AdoptedManual/SecUpd2019-001HighSierra.pkg
softwareupdated[#]: Manual product is nil, therefore an error occured, stashing token will NOT be created...
installer[#]: ManualAdoption: Error adopting /Library/Application Support/JAMF/Waiting Room/SecUpd2019-001HighSierra.pkg: Error Domain=SUErrorDomain Code=602 "An error occurred installing the update."

I'm reading far too many similar threads from far too many users having similar sounding issues without clear resolution. While I understand Apple's made a determination to expect full connectivity to and every device downloading updates from their 17.0.0.0/8 network, it's discouraging that they don't recognize the reality of restrictions (bandwidth and networks) where this isn't possible and updates need to be reliably deployable in multiple ways with well documented solutions and troubleshooting.

In the meanwhile perhaps the comment about finding and disabling all proxying will help someone else: https://discussions.apple.com/thread/8477051?page=2