Upgrade of Mojave Deployed via Jamf - requires log user to log in to complete upgrade

[mhollands]

after deploying Mojave via Jamf with a script to install, the package installs and returns to logon screen as expected. (presuming the install has complete)

The user logs in, then the install continues with a time of around 15 mins to finish.

If I download installer from the app store, this installs without this step. I also tested the installing locally the same .pkg file I have used in my deployment via jamf and do not run into this issue. It appears to be only when deployed via Jamf.

Our suppliers of Jamf told us to raise a case with Apple directly, but they have not had this reported and have told me it should be to do with Jamf as there install works without issue.

Our Jamf suppliers say the issue is not with Jamf?

I can not see anything online in regards to this issue, has anyone else come across this?

[mark_mahabir]

I've been seeing this in recent times with our High Sierra upgrade option in Self Service (i.e. users upgrading from 10.11 or 10.12). We have a policy to place the .app bundle on clients, and then a Self Service upgrade policy scoped to an appropriate smart group.

However, it doesn't always happen; sometimes the installation process is complete by the time the user logs in.

[jtrant]

You don't mention how you are scripting the install, but what about adding --nointeraction --agreetolicense when calling the installer?
As Mark mentioned above, we cache the installer and then use a Self Service policy to run it scoped to clients with the installer cached.

[mhollands]

thank you for your response,

this is already part of my script

/Applications/Install macOS Mojave.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS Mojave.app --agreetolicense --nointeraction

[mark_mahabir]

@jtrant I am using the --nointeraction and --agreetolicense flags and still seeing the issue mentioned. The installer was downloaded from the Mac App Store in the last few days.

@mhollands I think the --applicationpath flag is deprecated in Mojave....

[mhollands]

@mark.mahabir

I have had this response from my Jamf suppliers,

"The issue is all down to apple's installers rather than anything to do with Jamf. One of my colleagues had the same issue on their personal laptop, which wasn't enrolled in Jamf.

If you are running into this issue as I'd said please do contact Apple Support and see if they have any insight into the issue.

And no the application path flag is not deprecated in Mojave, a quick test gives:
./startosinstall --applicationpath
startosinstall: option `--applicationpath' requires an argument

And either way it shouldn't have any effect on the install like this."

so it appears the application path flag is not depreciated.

I downloaded Mojave from the app store and run the installer locally on a macbook (like a personal user) and didn't have to log in to complete the install, so I am well and truly baffled?

[mark_mahabir]

@mhollands Weird. This is the output from Jamf of my Mojave install script, if I leave the --applicationpath part in:

[STEP 6 of 9] Running script in-placeUpgrade_mojave.sh... Script exit code: 1 Script result: WARNING: "--applicationpath" is deprecated in macOS 10.14 and greater. Please remove it from your invocation. 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.

[PhillyPhoto]

Do you use FileVault? It might be the unlock screen and then continues to install once unlocked. Have you tried using the built-in install within a policy with the authenticated reboot option checked?

[mhollands]

thank you @PhillyPhoto - these are imacs im testing this install which do not have FV2 enabled, so that option is not checked either

[wmehilos]

The same thing happened on my lab Macs doing a remote startosinstall policy to go from Sierra to High Sierra. It seems to be a quirk of the installer process, undocumented of course.

[mark_mahabir]

I also see the issue on MacBooks which are FV2 encrypted; I have the authenticated reboot option ticked in the upgrade policy.

After logging in, the installation process continues for about 10-15 minutes.

[LovelessinSEA]

Adding to the pile, same thing is happening in our environment. I'm using the below script with jamfhelper:

#!/bin/bash

##Heading to be used for jamfHelper

heading="Please wait as we prepare your computer for macOS Mojave..."

##Title to be used for jamfHelper

description="

This process will take approximately 5-10 minutes.

Once completed your computer will reboot and begin the upgrade."

##Icon to be used for jamfHelper

icon=/Users/Shared/Install macOS Mojave.app/Contents/Resources/InstallAssistant.icns

##Launch jamfHelper

/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType fs -title "" -icon "$icon" -heading "$heading" -description "$description" &

jamfHelperPID=$(echo $!)

##Start macOS Upgrade

/Users/Shared/Install macOS Mojave.app/Contents/Resources/startosinstall --volume / --applicationpath /Users/Shared/Install macOS Mojave.app --nointeraction --pidtosignal $jamfHelperPID &

exit 0

[mack525]

@LovelessinSEA Are you using this after you've dropped the .app in the /users/shared directory?

[steveevans]

Same here....when deploying our upgrade to Mojave via Self Service, user has to login after machine is restarted in order for installation to complete.

We are using a JAMF OS upgrade script. Checking in the script --agreetolicense --nointeraction are both set.

[scottlevitt]

I'm seeing the same thing, as well as another 2 minute installation after a reboot once the installation appears to be complete.

[mark_mahabir]

Does anyone with an Apple Support contract - we don't have such a thing - fancy pinging them for further advice?

[LovelessinSEA]

@mack525 Yeah, I push the package to that location then have the self service script scoped to the group that has installed that package.

[mack525]

@LovelessinSEA Great! Have you noticed any issues with non admin users? osinstallersetupd window prompts standard user accounts to enter admin credentials.

[agoss]

I just wanted to chime in to say that we're experiencing this issue on our campus as well, through both Self Service upgrades and pushing the install to run automatically as part of a policy. Unfortunately this behavior will mean we'll either have to script an auto-login after the upgrade for our lab systems, or log in manually to them after the upgrade to complete the setup. If anyone is able to find further information about this that would be awesome!

[mack525]

@agoss I was able to get this accomplished by using https://github.com/jamfprofessionalservices/MakeMeAdminPy and adding that as part of our upgrade workflow policy. We also have a "Demote non approved admins to standard" script that runs on login which then demotes them after machine logs in. Its a bit funky but it has worked without any issues.