@VladCabrera We're running ours via a Self Service policy.
Thanks @dan.snelson I plan to eventually do something similar I think (just need time). Basically will check if there is already the "Install macOS Sierra.app" in the Applications folder and if the version matches use that. Otherwise we'll download (call another policy) to download the latest version we have and use that for the process. Shouldn't take much to do, just time.
@VladCabrera All my testing was done using Self Service (so, basically script is run as root). As you have stated, it appears to be hanging on the startosinstall command. What version of the macOS Sierra installer app file are you trying to use and on what OS version? Also, with the installer on the end-point, can you try running the below command and see if the command itself works?
/path/to/Install macOS Sierra.app/Contents/Resources/startosinstall --volume / --applicationpath /path/to/Install macOS Sierra.app --nointeraction
You can also check out /var/log/install.log to see if there is any other errors there, but running this manually you should see a lot more information.
@TylerC @stevewood
any luck on this error? i got the same error
Error:
Script result: Helper tool creashed...
By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms.
If you do not agree, press CTRL-C and cancel this process immediately.
No matching processes were found
Error running script: return code was 1.
@Dalmatian if you look at my last post, the only time I was able to successfully utilize that method was if I triggered the installation via a Login trigger on the policy. I did not try using Self Service, if I recall.
How are you triggering this? And have you looked at the other methods mentioned? Like Rich's method I posted in the first post I did. I've been using that method since 10.10 with no issues.
@stevewood
I've tried with a mixed trigger. but just changed it to Login only.
and funny thing is, i ran the command line manually in terminal and still got error, and upgrade can't proceed.
any idea?
@Dalmatian can you post the line in your script where you are calling the installer? It should be like what is posted above:
/path/to/Install macOS Sierra.app/Contents/Resources/startosinstall --volume / --applicationpath /path/to/Install macOS Sierra.app --nointeraction
I would take that line and try running it from within Terminal to see if it works.
running startosinstall manually will ask for my password to confirm I want to continue. Same thing with running Joshua's script sudo ./MacOS10.12upgrade.sh. I put both the script and the installer app in the same folder. The new policy is a command #/bin/sh -v -x /Users/Shared/MacOs10.12upgrade.sh
Execute Command
Command to execute on computers. This command is executed as the "root" user
/bin/sh -v -x /Users/Shared/MacOs10.12upgrade.sh
I put it in this location and remove the script because my understanding is that when it is in the script section the policy will run as the current user.
@VladCabrera Is it working for you when running the script that way? I unfortunately haven't seen this issue anywhere else so kinda at a loss of how to suppress that as it should be done via the -nointeraction switch.
I also wanted to clarify that when ever you run a script from the JSS whether in a check-in policy or via Self Service it is run as root when executed.
@Rosko When in doubt start from the beginning. That's my quote of the day.
I downloaded the script from GitHub again. This time I didn't open it with TextEdit. My default TextEdit format is .rft. So think my original issues may have been with how TextEdit change file data. Can't confirm but didn't care after working on 2 mac mini's this time around.
My new JAMF policies are:
1. download a copy of the Installer Sierra.app file into /Users/Shared and update inventory.
2. Enable the script as a Self Service policy for the logged on user to run from Self Service
This method has worked great thus far during lab testing. I was comfortable in the results enough to attempt another type of policy in which the policy is not available to the user in Self Service for an upgrade button. The idea is to force the upgrade from 10.10 and below OS. Let say a user loves their maverick machine and doesn't want to upgrade even if its available. As Mr. bad guy I can say your machine is being upgraded anyway.
@VladCabrera Awesome! Glad to hear everything is working now. This issues was bothering me, so glad its working now :)
Have a great weekend!
~Josh
The script uploaded by Josh from JAMF seems to never complete on some of my machines. Here is the output log from the JSS:
[STEP 1 of 5]
Executing Policy macOS Sierra Upgrade
[STEP 2 of 5]
Running script macOS_Sierra_10.12.x_upgrade.sh...
Script exit code: 0
Script result: Power Check: OK - AC Power Detected
Disk Check: OK - 962GB Free Space Detected
Launching jamfHelper as FullScreen...
Launching startosinstall...
[STEP 3 of 5]
[STEP 4 of 5]
Inventory will be updated when all queued actions in Self Service are complete.
[STEP 5 of 5]
The JAMFHelper screen just stays up, but self-service has finished running the policy. I'm lost as to why its working on some machines but not others. I have not modified the script
The script uploaded by Josh from JAMF seems to never complete on some of my machines. Here is the output log from the JSS:
[STEP 1 of 5]
Executing Policy macOS Sierra Upgrade
[STEP 2 of 5]
Running script macOS_Sierra_10.12.x_upgrade.sh...
Script exit code: 0
Script result: Power Check: OK - AC Power Detected
Disk Check: OK - 962GB Free Space Detected
Launching jamfHelper as FullScreen...
Launching startosinstall...
[STEP 3 of 5]
[STEP 4 of 5]
Inventory will be updated when all queued actions in Self Service are complete.
[STEP 5 of 5]
The JAMFHelper screen just stays up, but self-service has finished running the policy. I'm lost as to why its working on some machines but not others. I have not modified the script .
Hi @bpavlov I would go that route except one of our requirements was zero user interaction. As we have FV2 enabled the above workflow would require users to authenticate against FV2 to finish the installation.
I actually was able to get the script working by flushing user and system caches via policy.
Thanks for the feedback though!
With 10.12.4 Updater Apple changed some things with startosinstall:
--volume argument is not needed.
On OS X 10.11.6:
--volume is not a valid option if you run on a OS X 10.11 Mac and command will fail.
Upgrade tool works fine without --volume argument
On OS X 10.8.5:
--volume available on 10.8
Upgrade command doesn't work properly (error: Helper tool creashed)
To get it working you need to open the Installer app once via GUI and then run the command.
We have an active AppleCare Enterprise Services case about this.
To get 10.12.4 upgrade working via scripted method we have to do 2 things:
1. Let it open the installer app and close quickly.
2. Run the startosinstall command with no --volume argument.
#!/bin/sh
# All Glory and Thanks to Jesus!
macOSinstallerAppPath="/Applications/Install macOS Sierra.app"
CurrentloggedInUser=$(/usr/bin/python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");')
# There was an issue with startosinstall command that "Install macOS..app" needs to be opened once by logged in user to get it working properly
effectiveUserID=$(/usr/bin/id -u "$CurrentloggedInUser")
/bin/launchctl asuser "$effectiveUserID" sudo -u "$CurrentloggedInUser" /usr/bin/osascript <<EOT
tell application "${macOSinstallerAppPath}" to activate
EOT
# Wait for 5 seconds to settle down then quit the app
/bin/sleep 5
/bin/launchctl asuser "$effectiveUserID" sudo -u "$CurrentloggedInUser" /usr/bin/osascript <<EOT
tell application "${macOSinstallerAppPath}" to quit
EOT
# Run upgrade command
"${macOSinstallerAppPath}/Contents/Resources/startosinstall" --applicationpath "${macOSinstallerAppPath}" --rebootdelay 30 --nointeraction
# Reboot immediately if it has not rebooted by 'startosinstall'
/usr/local/jamf/bin/jamf reboot -background -immediately
exit 0
Apple also changed the way how Internet Recovery works.
Initial Internet Recovery will recover to the macOS it came with and once you have upgraded to macOS 10.12.4 the next Internet Recovery attempt will recover to 10.12.4 instead of the OS it came with.
@Rosko , Josh, I showed Leslie last week what we are trying to do with the installer. We noticed that when we use the script in a policy then as a executed command (Files and Processes) it will not complete because it can't not close open applications.
We have a policy that downloads the installer and the script into /Users/Shared/ then a second that Executes the bash script.
What would be your preferred method of sending a killall command to the machine? User script in the same policy?
@VladCabrera As it sounds like the workflow has been modified, I really can't speak entirely too it without seeing it. But you shouldn't have to do a killall since there should be a & at the end of the line that calls the startosinstall in the script like this /Users/Shared/Install macOS Sierra.app/Contents/Resources/startosinstall --applicationpath /Users/Shared/Install macOS Sierra.app --nointeraction --pidtosignal $jamfHelperPID &.
This ensure that the macOS Sierra Installer will run as a background process and not "hold up" the script.
My policy and script script are working fine. However, when the 10.12.5 Install macOS Sierra.app starts (from /Applications folder) I get this error below.
Is it booting/installing from the wrong volume?
Has anyone seen this before?
I got the 10.12.4 installer to work using Rosko's vanilla workflow. Using the 10.12.5 installer I kept seeing the following errors in the policy log:
"/Users/Shared/Install macOS Sierra.app/Contents/Resources/startosinstall" --applicationpath "/Users/Shared/Install macOS Sierra.app" --nointeraction
By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms.
If you do not agree, press CTRL-C and cancel this process immediately.
Error: __28-[OSISClient targetForPath:]_block_invoke, Couldn’t communicate with a helper application.
Error: could not find target...
Helper tool creashed...
In the system's install.log I saw this:
osinstallersetupplaindn2321]: Multiple clients attempting to connect to osinstallersetupd
So I added this bit of code before the startosinstall command
/usr/bin/killall osinstallersetupplaind
/bin/sleep 2
This seems to resolve the issues I had
This post by @jbourdon did the trick for me.
https://www.jamf.com/jamf-nation/discussions/21563/macos-install-in-place-error
Let me start out by saying that we're not a jAMF shop yet, trying to convince my bosses to go this route.
What I ended up doing was creating a payload-free package, with the Sierra Installer App in the Scripts folder along with a few other bits.
The postinstall script looks like this:
#!/bin/bash
WORKDIR=$(dirname $0)
APP="$WORKDIR/Install macOS Sierra-10.12.5.app"
if [[ -d "$APP" ]]; then
logger -s "Starting Sierra InPlace Upgrade..."
"$APP/Contents/Resources/startosinstall" --applicationpath "$APP" --agreetolicense --rebootdelay 10 --nointeraction
sleep 5
logger -s "Shutting Down osinstallersetupd Process.."
sudo killall "osinstallersetupd" 2>/dev/null
logger -s "Beginning Authenticated Reboot..."
/usr/bin/fdesetup authrestart -inputplist < "$WORKDIR/authrestart.plist"
else
logger -s "$APP not found. Aborting..."
exit 1
fi
exit 0
We have a full-screen Cocoa app I created, that prevents the user from interacting with the system while the initial steps are taking place (think jAMF helper). This effectively blocks any soft-reboot from startosinstall. Apparently, when it reaches the stage where the rebootdelay kicks in, startosinstall is already done and the postinstall moves on to the next item in the script.
At that point, we perform an authenticated reboot ourselves, which will sigkill all running applications.
Since the installer binary unpacks the package to a temp directory and then cleans up after it's done, we don't have to bother with removing the macOS Sierra Installer app, or the plist used to do the authreboot.
Just wanted to share this alternate approach, since I've learned a lot from the members of this forum!
AIR.
Has anyone experienced with the 10.12.5 installer that some machines will run the startosinstall prep the drive but when it restarts it will boot back to the old OS. In other words, the upgrade will not run during the reboot. I have tested with just the startosinstall command and switches.
Running command /Users/Shared/Install macOS Sierra.app/Contents/Resources/startosinstall --applicationpath "/Users/Shared/Install macOS Sierra.app" --nointeraction...
Result of command:
By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms.
If you do not agree, press CTRL-C and cancel this process immediately.
Preparing to run macOS Installer...
Preparing 1.492537...
Preparing 1.492537...
Preparing 1.492537...
Preparing 1.492611...
Preparing 2.388166...
Preparing 3.283721...
Preparing 4.179275...
Preparing 5.074830...
Preparing 5.970384...
Preparing 6.865939...
Preparing 7.761493...
Preparing 8.657048...
Preparing 9.552602...
Preparing 10.448157...
Preparing 11.343711...
Preparing 12.239266...
Preparing 13.134821...
Preparing 14.030375...
Preparing 14.925930...
Preparing 15.821484...
Preparing 16.717039...
Preparing 17.612593...
Preparing 18.508148...
Preparing 19.403702...
Preparing 20.299257...
Preparing 21.194811...
Preparing 22.090366...
Preparing 22.985921...
Preparing 23.881475...
Preparing 24.777030...
Preparing 25.672584...
Preparing 26.568139...
Preparing 27.463693...
Preparing 28.359248...
Preparing 29.254802...
Preparing 30.150357...
Preparing 31.045911...
Preparing 31.941466...
Preparing 32.837020...
Preparing 33.732575...
Preparing 34.628130...
Preparing 35.523684...
Preparing 36.419239...
Preparing 37.314793...
Preparing 38.210348...
Preparing 39.105902...
Preparing 40.001457...
Preparing 40.897011...
Preparing 41.792566...
Preparing 42.688120...
Preparing 43.583675...
Preparing 44.479230...
Preparing 45.374784...
Preparing 46.270339...
Preparing 47.165893...
Preparing 48.061448...
Preparing 48.957002...
Preparing 49.852557...
Preparing 50.748111...
Preparing 51.643666...
Preparing 52.539220...
Preparing 53.434775...
Preparing 54.330329...
Preparing 55.225884...
Preparing 56.121439...
Preparing 57.016993...
Preparing 57.912548...
Preparing 58.808102...
Preparing 59.703657...
Preparing 60.599211...
Preparing 61.494766...
Preparing 62.390320...
Preparing 63.285875...
Preparing 64.181429...
Preparing 65.076984...
Preparing 65.972539...
Preparing 66.868093...
Preparing 67.763648...
Preparing 68.659202...
Preparing 69.554757...
Preparing 70.450311...
Preparing 71.345866...
Preparing 72.241420...
Preparing 73.136975...
Preparing 74.032529...
Preparing 74.928084...
Preparing 75.823638...
Preparing 76.719193...
Preparing 77.614748...
Preparing 78.510302...
Preparing 79.405857...
Preparing 80.301411...
Preparing 81.196966...
Preparing 82.092520...
Preparing 82.988075...
Preparing 83.883629...
Preparing 84.779184...
Preparing 85.674738...
Preparing 86.570293...
Preparing 87.465848...
Preparing 88.361402...
Preparing 89.256957...
Preparing 90.152511...
System going down for install...
The machine reported back in with having 10.10 installed.
@VladCabrera yes we are seeing this also. It seems to work. When you run the script a second time.
@a.stonham Any thoughts as to why that happens. I'm reviewing the log from the time that the installation started and comparing it to one that I ran the installer manually. Thus far nothing is jumping out at me.
Let me just say that it is COMPLETELY RIDICULOUS that Jamf has not updated their built-in reboot options to support macOS Sierra upgrades. Sierra has been out for almost a year, and ever since 10.12.4 this functionality is BROKEN. So much for zero day support, eh guys?
I'm sure they will blame Apple... Tell you what, you guys are the device management system which Apple pretty much suggests that customers go with, yet there are many many MANY open PIs which affect core functionality. Even Munki has a workflow which works for Sierra upgrades. We CANNOT wait for 10 for the multitude of things which are currently broken to be fixed. It looks bad for Jamf when we have to try to hack around what used to be standard and streamlined processes.
