Catalina Upgrade Via Self Service - Stuck On "Running"

[john_sherrod]

Would love some wisdom on this. I've got a fairly simple Self Service policy to allow my users to upgrade to Catalina. Just a simple Files & Processes commend like so:

 '/Applications/Install macOS Catalina.app/Contents/Resources/startosinstall' --agreetolicense --nointeraction --forcequitapps &

Part of the time when a user kicks off that policy everything works properly and the computer reboots and begins the installation process. But in many instances, nothing happens. Self Service just says the policy is "Running" for several hours.

Does anyone have any insight into what causes this and how to mitigate it?

[sdagley]

@john.sherrod Take a look at macOSUpgrade as it does a great job of pre-flighting the upgrade process and will be much more informative if something goes wrong than the Files & Processes approach.

[arnoldtaw]

Try these:
Make sure there are no "Restricted Software" that is blocking the process (example: osinstallersetupd) or application name (example: Install macOS Catalina.app) for that machine. Close/Kill the Self Service Application after initiating the policy. (i.e: don't leave the Self Service Application after clicking "Wipe" (or defined BUTTON NAME BEFORE INITIATION).

[john_sherrod]

To provide a little more info, when a Mac gets in this situation where it shows as "Running" in Self Service, the policy log shows that the computer is still in Pending status. It's like it never actually kicks off the policy correctly in the instances where this happens.

[mm2270]

Any policy that doesn't "complete" will still show as Pending in the server. For a policy to show as Complete or Failed requires that the policy executes, exits and uploads a log to the server so the server knows the final status (Complete or Failed), otherwise it remains at Pending. Jamf Pro doesn't know the live status of a policy. Only that it ran and is finished in one way or another, or still needs to run.
A common way this is seen is with policies that kick off an immediate restart of a Mac after executing. If the policy doesn't have an opportunity to upload a final log, then it remains as Pending in the policy log.

All this is to say that it's not unusual to see these remain as Pending in the case of a policy that gets stuck or doesn't run to completion, which is what it sounds like is happening here.

What I might try here is, on one of the affected machines, kill any Jamf running policies in Terminal, and then run the same command you have in your Execute Command field directly in Terminal. See if there is any error in Terminal or if any messages pop up that would clue you in to why it's failing on those machines. You never know, it might reveal something pertinent.

I would also look to see if there is a pattern on the machines it won't run on, like the same OS version for example. Maybe it's an issue with upgrading to Catalina from an older OS, or maybe there is some common application installed/running on these machines that's interfering.

[jonconn]

I've run into a similar experience with doing self-upgrades to Mojave in our environment. I traced it to a stuck Self-Service app. To overcome this, I included the following line in my upgrade script one line before the command to execute the upgrade:

osascript -e 'quit app "Self Service"'

That resolved the issue for me the majority of the time. Any other remaining issues were the result of an end user not responding to a file dialog.

Hope this gets you over the hurdle!

Best,

Jonathan

[john_sherrod]

Thanks, @sdagley! I had actually used that process in the past, but ran into similar issues with it as well.

[john_sherrod]

Thanks, @arnoldtaw! I double-checked and I don't have any restricted software settings in place that would be interfering with this.

[john_sherrod]

Thanks, @mm2270 and @jonconn! That definitely gives me something else to try.

[jonconn]

@john.sherrod - Always happy to be of service! Let me know if there's anything else I can do to lend a hand! :-)

Best,

Jonathan

[mconners]

Hello @jonconn a question about your command to quit self service. Do you use a conditional situation where IF self service is running, you run the command to quit? I ask because I have a separate script to quit self service but when I run this via Jamf Remote, self service isn't running on the computer and I get an error saying no matching processes. I know this is true because self service isn't running in this case.

I was hopeful to find a way to determine if self service is running and if it is, quit self service so I am not throwing an error.

[jonconn]

@mconners - I haven't included one m'self, as my script runs exclusively in Self-Service. I've set up a variant that I use for manual activation via Jamf Remote. A quick search for options here included this thread - perhaps it can help in your situation with some modification?

https://www.jamf.com/jamf-nation/discussions/25154/script-to-check-if-application-is-open-and-quit-using-script-parameter

[mconners]

Thank you @jonconn I ended up creating a different policy for remote upgrades/installs and another for working in self service. I was hoping to keep it a single policy, but that's fine. I am at least recycling the same script. Thank you for the reply.

[jonconn]

@mconners - Sure thing! If you need anything else, I'll do my best to lend a hand. :-)

[msalvaleon]

@mconners Could you kindly share your self service script with me?

[ckulesza]

After working with JAMF support we got this to work with a cached install. One policy for the cache no self service. The other policy self service for the install of the cached package.
sudo /Applications/Install macOS Catalina.app/Contents/Resources/startosinstall --agreetolicense --nointeraction && killall Self Service

[mconners]

Hello @msalvaleon I am trying to find the original script I used as I have modified it to fit our environment. I hate to post too much information here. Once I discover it, I can post the link here. If you wish, you can send an email to mconners@madisoncollege.edu and I can send it over that way too.

I found the link to the article and script via Github. Here you go.

This is used for both our self service installs and our automated installs which are done remotely.

[zubair_kasim]

Hi @john.sherrod, I was wondering if you managed to work out what was causing the issue? I'm having the same problem myself. I had a test group of 6 machines - 4 worked a charm but 2 got stuck in "running". I ran the same command '/Applications/Install macOS Catalina.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps' in terminal and no problems, upgrade to Catalina kicks off! I've rolled it out to a few more people and of them 3 have worked without any problems, 3 have got stuck. No logs in Jamf to give any guidance, jamf.log doesn't show much, install.log doesn't show any errors either. It's as if the process just stops working!
We did have a restrict software policy for Install OS Catalina.app which I removed at the beginning of the week. I'm really at a loss with this one.
Jamf Support are looking into it too but at the moment, it's not looking good!
Any help would be handy :)

[john_sherrod]

@zubair.kasim Unfortunately I never got to the bottom of it. I eventually got close enough to having my fleet fully updated that I just manually kicked of the install on the remaining few. I had planned to revisit with Big Sur this Fall and see if the issue persists there.

[zubair_kasim]

Thanks @john.sherrod, I'm having to run the upgrade manually on the bulk of our machines too. I've got a support case open so if anything promising comes out of it, I'll post it here. Otherwise, good luck with Big Sur!

[asulliva]

Hello,
@zubair.kasim I had the same issue, and it's still not perfect, but you might consider trying the -rebootdelay [delay int] vs the -pidtosignal option for starttoinstall, and then backgrounding it with the &, and then closing self service. Also, I threw in a jamf flush command to remove the restricted policy from the local machine, since the restriction isn't enforced on the server side, but resides locally. Otherwise if you remove a computer from the restricted software group, and then run the upgrade, the local restriction is still there. All that said, I'm still trying to polish my upgrade script. It works 70 percent of the time, but when it hangs, it's usually because "Self-Service interrupted the restart"

[GabeShack]

I keep wondering if there is a way to show some sort of percent complete install meter during either a policy or a self service download/install.

That would be a great boon to our users.

Gabe Shackney
Princeton Public Schools

[john_sherrod]

I wanted to return to this thread since we never found a resolution to it, but I THINK I may have found what was causing the issue. I've been deploying macOS Big Sur to a small group of early testers. It's been going great for most of them, but two of them had this same old issue re-occur. They manually start the update to Big Sur via Self Service, and it just sits and hangs and never reboots to complete the update. I did some new digging on the issue and came across this thread over on GitHub. A lot of great discussion there, and there are some posts about a LaunchAgent from a previous macOS install potentially causing the issue: /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist. I checked and my user in question did indeed have that LaunchAgent present on her Mac.

One of the participants in that thread posted a script that looks to see if that LaunchAgent is present, and unloads it if so. I added that as a Before script to my Big Sur install policy and my user was then able to run the update from Self Service with no issues. Here's the script:

#!/bin/bash

if [[ -e "/Library/LaunchAgents/com.apple.install.osinstallersetupd.plist" ]]; then
    /bin/echo "LaunchAgent detected, checking for logged in user..."
    loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' )
    if [[ "$loggedInUser" != "" ]]; then
        /bin/echo "User $loggedInUser is logged in, unloading LaunchAgent..."
        sudo -u "$loggedInUser" /bin/launchctl unload /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist
    fi
    /bin/echo "Deleting LaunchAgent..."
    /bin/rm -rf "/Library/LaunchAgents/com.apple.install.osinstallersetupd.plist"
else
    /bin/echo "LaunchAgent not present, exiting..."
    exit 0
fi

I'll continue monitoring as more of my users upgrade to Big Sur, but wanted to add this to the discussion in case it's helpful for anyone else. Cc: @zubair.kasim

[zubair_kasim]

Wow, this will prove to be an amazing find and resolution if this is what has been causing the issues all this time! Congrats and well done @john.sherrod and to all those involved! Reading through the original posts on GitHub and beyond, it looks promising!
I'm going to be testing Big Sur with a handful of staff in the new year, one of our business applications is incompatible with Big Sur so we're still waiting for the green light. I will definitely let you know once I've tried it. It'll be interesting to know if anyone else has greater success with roll outs compared to previous OS's?