Issue running script from policy

[jrogersnh]

Hey All - 

I'm running into a weird issue where during testing, I had my upgrade workflow to get our computers upgraded to the newest version of Monterey via a pkg file. All went perfectly during testing. However, when I pushed it live this morning, all users received this error that the process was killed when it attempts to call startosinstall:

"/Library/Application Support/JAMF/tmp/upgradeRebootWarning.sh: line 20: 60521 Killed: 9 /Applications/Install\ macOS\ Monterey.app/Contents/Resources/startosinstall --agreetolicense --nointeraction Error running script: return code was 137."

For reference, this is all the script is doing:

#!/bin/bash

#get logged in user info
loggedInUser=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`
loggedInUserUID=$(id -u "$loggedInUser")
echo "The current logged in user is $loggedInUser and their UID is $loggedInUserUID"

#create applescript string
userPopup="display dialog \
\"Your machine has finished the download and will need to reboot in order to begin the macOS upgrade process. Please save all work you may have open and keep your computer plugged into power throughout the duration of the upgrade.\n\
The upgrade will begin after clicking the OK button. It can take upwards of 30 minutes before the reboot occurs while the installation happens.\" \
buttons {\"OK\"} \
default button \"OK\""

#call applescript for user popup
upgradePrompt=$( /bin/launchctl asuser $loggedInUserUID sudo -u "$loggedInUser" /usr/bin/osascript -e "$userPopup" )
#gather user input information
echo $upgradePrompt

/Applications/Install\ macOS\ Monterey.app/Contents/Resources/startosinstall --agreetolicense --nointeraction

Any idea why this would happen after it was working perfectly just days before, without any changes to the policies or script? 

[ljcacioppo]

Do you happen to have a restricted software entry in place for Monterey for the computers that failed?

[jrogersnh]

I did have one, but removed the scope prior to scoping this policy to machines. Another script runs before the above one which does call flushCaches and manage to remove & sync before this runs so it should have correctly removed any software restrictions on the local machine 

[Hugonaut]

Was this on Intel or M1?

For M1 macs you need to modify the startosinstall command to pass administrator credentials on the machine

echo ${ADMINNAME} | '/Applications/Install\ macOS\ Monterey.app/Contents/Resources/startosinstall' --nointeraction --agreetolicense --forcequitapps --user ${ADMINPASS} --stdinpass

also for loggedInUser I recommend

loggedInUser=$([[ $3 ]] && echo "$3" || defaults read /Library/Preferences/com.apple.loginwindow lastUserName)

[jrogersnh]

All Intel based macs - haven’t tackled software updates on M1s yet, lol! Thankfully no m1s in the field… yet :) 

[mm2270]

Quick question, but do you know if the users are seeing the prompt come up and then it fails, or does the prompt not show at all? If it's the latter, then it may be an issue trying to display the Applescript dialog. Usually using the launchctl asuser syntax just as you have it works ok.

But honestly in this case as you aren't making use of any specific Applescript functions, like a drop down or user input, you'd be better off using jamfHelper for the dialog, since you don't need to have it run as the logged in user to work.

If the users ARE getting the prompt but then it fails, then clearly it's something in the startosinstall command it's not liking. Offhand, I don't see any issues with it though. The only real difference in my OS upgrade script is I also pass the --forcequitapps flag to startosinstall to make sure nothing blocks the upgrade.

[jrogersnh]

They do get the popup, so I can isolate it to the startosinstall... I originally did have forcequitapps as part of that string, but in my testing removed it to see if it'd help it take which it hasn't yet. AppleScript seems to be fine, it just won't fully kick the installation off and seems to kill the process after that command is called

[jrogersnh · Accepted solution]

Not sure what happened, but I was able to fix this by just creating a new policy, copying everything over and deleting the old policy. Something must have become corrupted or sticky in that old one that was causing all the issues. Go figure, had nothing to do with the script. 

Thanks everyone!