Skip to main content
Solved

Issue running script from policy

J
Forum|alt.badge.img+6

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? 

Best answer by jrogersnh

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!

View original
    Did this topic help you find an answer to your question?

    7 replies

    ljcacioppo
    Forum|alt.badge.img+17
    • ljcacioppo
    • Contributor
    • 183 replies
    • March 2, 2022

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

    aparten11
    J
    2 people like this
    • aparten11
      aparten11
    • J
      jrogersnh
    Hugonaut
    Forum|alt.badge.img+15
    • Hugonaut
    • Esteemed Contributor
    • 574 replies
    • March 2, 2022

    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)

     

     

    Looking for a Jamf Managed Service Provider? Look no further than Rocketman Tech! Virtual MacAdmins Monthly Meetup - First Friday, Every Month
    aparten11
    The_Burg
    2 people like this
    • aparten11
      aparten11
    • The_Burg
      The_Burg
    J
    Forum|alt.badge.img+6
    • jrogersnh
    • Author
    • Contributor
    • 13 replies
    • March 2, 2022
    ljcacioppo wrote:

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


    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 

    J
    Forum|alt.badge.img+6
    • jrogersnh
    • Author
    • Contributor
    • 13 replies
    • March 2, 2022
    Hugonaut wrote:

    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)

     

     


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

    Hugonaut
    The_Burg
    2 people like this
    • Hugonaut
      Hugonaut
    • The_Burg
      The_Burg
    mm2270
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • 7880 replies
    • March 2, 2022

    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.

    aparten11
    Hugonaut
    The_Burg
    3 people like this
    • aparten11
      aparten11
    • Hugonaut
      Hugonaut
    • The_Burg
      The_Burg
    J
    Forum|alt.badge.img+6
    • jrogersnh
    • Author
    • Contributor
    • 13 replies
    • March 2, 2022
    mm2270 wrote:

    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.


    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

    aparten11
    1 person likes this
    • aparten11
      aparten11
    J
    Forum|alt.badge.img+6
    • jrogersnh
    • Author
    • Contributor
    • 13 replies
    • Answer
    • March 3, 2022

    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!

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings