Any ideas about how I can overcome:
"Self Service" interrupted restart.
To continue restarting, quit "Self Service".
....after the script runs?
@ianmb The script as written should not encounter that error.
Please ensure the & is still at the end of line 173. It should look like this...
/Users/Shared/Install macOS Sierra.app/Contents/Resources/startosinstall --applicationpath /Users/Shared/Install macOS Sierra.app --nointeraction --pidtosignal $jamfHelperPID &
@Rosko I've verified line 173 looks exactly like that.
Do I need to add any specific Restart Options in the JSS policy?
@ianmb Nope, the macOS Installer takes care of the reboot, so that Policy Payload isn't needed.
Did the script work for you before or have you always had this issue?
@Rosko It works fine in our test environment, but not so in live (scoped to a single test machine) so I really don't know where the issue lies currently!
Due to numerous problems with the utility, I've pretty much given up on making a cutesy upgrade path. Now I simply have two policies - one that updates apps to full compatibility (e.g. office patch, etc) and runs a jamf manage, and the second one that brings the user to the mac app store page to download Sierra. They are scoped to a static group, which is also exempted from the "Install OSX.app" restrictions we have. They are published in Self Service and instructions are provided via policy description. This also has the benefit of not requiring a software distribution point for external users.
Was this issue fixed in Jamf Pro 9.99.0 by any chance?
I am also encountering issues when upgrading from 10.11.6 to 10.12.5 installer. When i package the installer in the Users/Shared folder then attach the script to the policy, I'm able to run the policy in self service but the machine does not boot to the installer. The machine boots back to El Capitan and when I check the policy logs everything check out up until "Launching startosinstall..." I keep checking the script for any errors on my end.
@john.sherrod I'd also like to know if 9.99.0 did anything to solve this issue. My cloud JSS isn't scheduled to be upgraded for a few weeks, anybody on 9.99.0 tried doing a regular policy-based 10.12.5 upgrade? Or 10.12.4 for that matter?
Sorry folks. Not resolved in 9.99.0 I'm afraid. Just updated and re-ran my original self service upgrade to 10.12.4 and it still fails due to the brtool issue (see below). 10.12.5 also fails due to the same reason. Am reverting back to the scripts mentioned in this thread which do work (not ideal for us but better than nothing).
Preparing for in-place OS upgrade...
Failed to copy file to the install data folder. Failed to copy /Volumes/OS X Base System/Install macOS Sierra.app/Contents/Resources/brtool to /OS X Install Data/brtool: The file “brtool” couldn’t be opened because there is no such file.
I use startosinstall for auto upgrade Macs (tested on 10.8, 10.9, 10.10, 10.11) and works every time. You need to know that you need to do some workarounds to get it working 100%.
Click HERE for more information.
#!/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
@Rosko I figured this out - I was doing an Update Inventory in the same policy which was holding up the reboot.
Without this, all is working perfectly, thanks!
@ianmb Glad to hear! Thanks for letting me know :)
@Kumarasinghe I'm not sure why you have to launch the installer and then quit it once. I have not seen that before.
And correct @john.sherrod, @znilsson, and @aservadei ...this hasn't been fixed in v9.99.0. We are aware of the issue and have it on our radar, but no timeframe of when it will be resolved. But you all can help by contacting your Jamf Buddy (if you haven't already) and open a case in reference to PI-003792.
@Rosko We had to open the app once as logged in user to get it working properly on older Mac OS versions. it was a known issue (Apple log number: 100147455701)
ISSUE: Upgrade command doesn't work properly (error: Helper tool creashed) on older operating systems than 10.11
When attempting to use the “startosinstall” command for your automated installation, you are seeing several failure messages found in the system.log (com.apple.install.osinstallersetupd, error = 134: Service cannot load in requested session*)
@Rosko I'm now seeing the 'Requirements Not Met' pop-up message on some other machines - one example is an iMac on my desk, so permanently connected to power and there is very definitely more than 15GB free space on the disk (in fact there is hardly anything on the disk as it is a fresh install).
Any ideas?
@ianmb Do those computers by chance have fusion drives? If so, could you run diskutil info / and let me know the output.
@Rosko Turns out those iMacs had failing hard disks according to the S.M.A.R.T. info, so maybe that was it. The Late 2009 iMac I'm trying this morning is working great so far, thanks for your help once again!
@Rosko, Your Script is working for me except it would help if your script could do authenticated restart and prevent the screen saver from starting.
@burdett Yes, I would love to get the authenticated restart working, but unfortunately this problem is with the Apple installer. A bug report is open with Apple, but no ETA on when it will be fixed. More info can be found here.
As for preventing the screen saver, feel free to put in a feature request in on the GitHub page and I can add that in the workflow.
Glad its working for you and thanks for the feedback!
Trying to package the Sierra 10.12.5 installer that I've placed in /Users/Shared using Composer. However the end result is always a file that is zero bytes.
Any ideas? I've tried packaging as both PKG and DMG.
@Taylor.Armstrong
@Jason
@Rosko
I reworked "Check if free space > 15GB" to use Bytes instead to get around the issue where TB could be reported instead of GB.
osMinor=$( /usr/bin/sw_vers -productVersion | awk -F. {'print $2'} )
if [[ $osMinor -ge 12 ]]; then
freeSpace=$( /usr/sbin/diskutil info / | grep "Available Space" | awk '{print $6}' | cut -c 2- )
else
freeSpace=$( /usr/sbin/diskutil info / | grep "Free Space" | awk '{print $6}' | cut -c 2- )
fi
if [[ ${freeSpace%.*} -ge 15000000000 ]]; then
spaceStatus="OK"
/bin/echo "Disk Check: OK - ${freeSpace%.*} Bytes Free Space Detected"
else
spaceStatus="ERROR"
/bin/echo "Disk Check: ERROR - ${freeSpace%.*} Bytes Free Space Detected"
fi
Still testing but seems like that will fix it?
Just a note, but that entire if/then block checking for the OS version to run the correct diskutil command can be avoided with the following code. This gets the correct data regardless of the OS version. Well, at least going back the last 3 or 4 OS releases. I can't vouch for going back further than that.
/usr/sbin/diskutil info / | /usr/bin/awk '/Available Space|Free Space/{print $4}'
or if you want bytes instead of the human readable string
/usr/sbin/diskutil info / | /usr/bin/awk '/Available Space|Free Space/{print $6}' | sed 's/(//'
