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?
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.
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: 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?
@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.
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
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!
@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.