10.10.3 Update By Any Other Method Than App Store - BROKEN

dgreening
Valued Contributor II

This thread is a compilation of my findings from https://jamfnation.jamfsoftware.com/discussion.html?id=14003.

I have confirmed that either installing the 10.10.3 combo update via Self Service or running Software Update via Self Service coupled with the "Reboot Immediately" items WILL NOT reboot the machine, and results in a barely functional machine until a manual reboot. No bundled apps will launch, and any you try to launch will prevent a manual reboot until you force quit them. I also tried adding a /sbin/reboot command to the combo update policy, and it does nothing. I have also tried the non-combo 10.10.3 update with the same result.

Running "softwareupdate -ai” locally on the machine via terminal produces the exact same result. While this method does grab the updates and installs them, once its finished and gives you the "You have installed one or more updates which requires that you restart your computer...", if you don't reboot and try to launch any of Apples included apps or utilities, they never launch and must be force quit before you can manually reboot.

Right now it looks like the only valid method for updating to 10.10.3 in a manner that works as expected is to do it via the App Store, where it will download it, prompt you to reboot, and does the install at the Software Update screen post-logout.

Any thoughts as to what could be causing this? We really need to be able to point people to Self Service for updates as we have done in the past. Our branded Self Service app is front and center in terms of the Mac Teams visibility, and not being able to use it for the 10.10.3 update breaks our successful run of offering both specific OS updates and being able to kick off Software Update. If we cannot fix this we are going have to disable all Self Service based and Push based Software Update policies for 10.10 machines in the JSS, and hope that users will go to the App Store and install the updates from there.

JAMF confirmed this - "SWU policy with 10.10.3 hard freezes Mac at policy completion" (D-008920)

22 REPLIES 22

denmoff
Contributor III

One option would be to use Munki for Apple updates. The latest version handles the combo update correctly.

dgreening
Valued Contributor II

Yeah, I'd love to move to Munki or Resposado. We are all ASUS on Minis for now.

denmoff
Contributor III

Not too difficult to use Munki for just Apple updates. https://github.com/munki/munki/wiki/Apple-Software-Updates-With-Munki

dgreening
Valued Contributor II

Unfortunately we wont be making the move soon, so I'm hoping that JAMF can come up with a solution. I wonder if grabbing the separate install packages from ASUS and playing with the order in a policy will get me somewhere...

joecurrin
New Contributor III

We added a reboot script to the end of the software update policy.

shutdown -r now

Seems to be successful for a workaround for now.

dgreening
Valued Contributor II

ooo cool! I'll give that a try.

dgreening
Valued Contributor II

Well that looks like it worked when used on a SUS policy pushed from the JSS at check-in! I'll test using Self Service tomorrow and report back! Thanks!!

guidotti
Contributor II

We are also seeing this.
Unsure why we have to force a reboot as we never had to do that with previous updates...

Lotusshaney
Contributor II

The "shutdown -r now" method always works compared to the hit and miss "Reboot Immediately"

In the years I have been using Casper I have never seen "Reboot Immediately" work correctly.

joecurrin
New Contributor III

We deployed updates to our Technicians last night. This has given us mixed results. Shutdown now will definitely restart the computer. The problem is the system will not update the policy to inform JSS that the policy completed. Thus sticking the computer into a reboot loop and re-running the policy at check-in every time.

To fix that problem we added in the recon command and excluded 10.10.3 systems from the policy so that the reboot loop would stop.

We aren't very happy with the results and the massive amount of work arounds required for this update. We are delaying the update until JAMF/Apple figure out whats broken.

dgreening
Valued Contributor II

Yeah I am definitely not seeing a log for policy completion on the SUS based update policy, though it does seem to restart now. We are testing the 10.10.3 combo via Self Service with the "shutdown -r now" command.

mm2270
Legendary Contributor III

You could try using the following in the script instead:

/sbin/shutdown -r +2
exit 0

This should start the reboot sequence with a 2 minute delay and push it to the background, then exit the script, which would allow the policy to close out and upload a log to the JSS about it completing as well as a full recon. Usually inventory submission doesn't require more than 2 minutes (hopefully). You may be able to reduce that to +1 instead of +2 (1 minute delay versus 2 minutes) if you have a light recon process that completes pretty quickly.

EDIT: Ampersand isn't needed, so I removed it.

dgreening
Valued Contributor II

Nice I'll try that out as well.

joecurrin
New Contributor III

Yea we tried +1 before giving up. Sometimes the script wouldn't execute. The update was just too inconsistent.

dgreening
Valued Contributor II

We have been having good luck with tacking on "/sbin/shutdown -r +1" to the Files & Processes section, but for the Combo and Self Service initiated SUS install. We end up with logs on both counts, a successfully rebooted machine, and 10.10.3 with working Recovery Drive. We are going to let fly soon after excluding 10.10 machines which are not 10.10.3 from any/all SUS push policies.

guidotti
Contributor II

I concur with @dgreening 's advice. On some systems I do see that it tries to issue a reboot after my shutdown command already kicked in. In any case, it doesn't matter.
Do we think this is completely an Apple problem with the combo update?

RobertHammen
Valued Contributor II

Not sure if it's the OS update, the firmware updater embedded into the OS update package, or the Recovery update, but another +1 to including the /sbin/shutdown -r +1 at the end of your update policy.

jgalante
New Contributor III

I have had the same experience with 10.10.3 on Casper 9.71. Has anyone tried on 9.72 yet?

adhuston
Contributor

Same problem here, we are using Repasodo for our SUS server. I can confirm it does appear to be something with the combo update, machines installing the standard 10.10.3 update don't seem to be having this issue. Just appears to be something with the combo update. Haven't tried 9.72 yet though.

adhuston
Contributor

So a bit more interesting information. This is happening in my thin imaging script. The last thing that happens is the jamf recon command is called in the script before the script reboots the computer. It appears to be getting hung when it's trying to update inventory. Is anyone else updating inventory after the upgrade? Is this the point that you guys are seeing this happen?

adhuston
Contributor

Just got confirmation of an open defect for the issue. Let's hope it's fixed soon.

jgalante
New Contributor III

I was able to work around this issue:

  • Downloaded 10.10.3 ComboUpdate, copied installer .pkg to Casper Admin.
  • Created smart computer group for OS 10.10.2 or lower
  • Smart group is scope for two scripts: 1 - (recurring/once per computer) to cache installer and configured restart options: no user = immediate; user = restart (we allow user to delay 60 min.) 2 - (at log out/once per computer) to run cached installer. Restart options configured: no user = immediate; user = restart.

Maybe not the most elegant deployment but it has worked well for us. I am testing this same method with 10.10.4 ComboUpdate