Hi,
just want to share what I have found. I want to be as close as possible to the standard install process. Solution like mentioned above to launch the Install App once and quit it after some seconds feels not like a nice solution...
For those that still have the problem with FV2 enabled machines and the auth restart via startosinstall.
I figured out, that on the first launch of the High Sierra Installer app, Apple launches a LaunchAgent with a mach service "com.apple.install.osinstallersetupd". So why not launch this agent for our own in our workflow. I submitted the LaunchAgent to launchd and then started the installation via startosinstall. Auth restart process works as expected. Cool!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.install.osinstallersetupd</string>
<key>LimitLoadToSessionType</key>
<string>Aqua</string>
<key>MachServices</key>
<dict>
<key>com.apple.install.osinstallersetupd</key>
<true/>
</dict>
<key>TimeOut</key>
<integer>Aqua</integer>
<key>OnDemand</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>/Applications/Install macOS High Sierra.app/Contents/Frameworks/OSInstallerSetup.framework/Resources/osinstallersetupd</string>
</array>
</dict>
</plist>
Try it yourself ...
@Rosko
I have stripped down everything but the startosinstall commands and still having an issue
I installed the app in Shared/ and called it from there with this:
sudo /Users/Shared/Install macOS Sierra.app/Contents/Resources/startosinstall --applicationpath "/Users/Shared/Install macOS Sierra.app" --nointeraction
I get a long 'Preparing 1.670' to a 'Preparing 89.093' and then the error System reboot failed.
I want to test it working from Terminal before moving to a policy... Any ideas? I am using 10.12.6 installer
Any help is much appreciated.
Michael
Wow,
this is still a problem,time to start looking at jamJAR
@alex030cc
Well spotted!
It turns out the Sierra v10.12.6 installer has the same file:
$ ls -l /Applications/Install macOS Sierra.app/Contents/Frameworks/OSInstallerSetup.framework/Resources/osinstallerset*
-rwxr-xr-x 1 root wheel 76304 Jul 15 00:22 /Applications/Install macOS Sierra.app/Contents/Frameworks/OSInstallerSetup.framework/Resources/osinstallersetupd
-rwxr-xr-x 1 root wheel 104272 Jul 15 00:22 /Applications/Install macOS Sierra.app/Contents/Frameworks/OSInstallerSetup.framework/Resources/osinstallersetupplaind
$
The interesting question: Will this work if no user is logged into the console?
Guys, this version of startosinstall doesn't have a "--volume" argument. Take it out of the script and try again. I had to look at it over and over again just to realize this. Also add "--agreetolicense" to the script.
So does anyone have a finalized working script for 10.12.6? I’ve been looking @bp script and it seems to be able to accomplish an authenticated restart.
Hey @Rosko
I added a part at end to see if if the startosinstall fails and kills the jamfHelper window.
I noticed that was very helpful the handful of users that had an issue with the upgrade.
What do you think?
while [[ $(pgrep startosinstall) ]]; do
# echo macos installer in progress
sleep 3
done
if [[ -d "/macOS Install Data/" ]]; then
echo Ready for macOS install
else # no instllall data
echo macos Install Data Is not there, Preperation failed
#kill the full screen window
killall jamfHelper
## Remove Scripts
/bin/rm -f /usr/local/jamfps/finishOSInstall.sh
/bin/rm -f /Library/LaunchDaemons/com.jamfps.cleanupOSInstall.plist
/bin/rm -f /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist
/bin/echo "Launching jamfHelper Dialog (Preperation failed)..."
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -title "$title" -icon "$logo" -heading "Preperation failed" -description "We're sorry, we were unable to prepare your computer for $macOSname. Please restart and try again at a later time from Self Service.
If you continue to experience this issue, please contact the Service Desk. Thank you." -iconSize 100 -button1 "OK" -defaultButton 1 -timeout 600
fi
killall jamfHelper
@mrhollywoodgates,
You could probably just use "$USER", or "$LOGNAME".
And "$UID", or "$EUID". They're already set. Just FYI.
@cubandave I actually didn't do that just because I let the startosinstall binary handle the closing of jamfHelper and want the script to actually complete prior to startosinstall. In my testing, if startosinstall finished and tried to reboot while the script was still running I would get multiple errors from Self Service. I haven't tested this recently, but thats what I used to get and as such just left it that way cause it continues to work great.
But if you need to modify it to make it work a certain way in your environment that is totally cool! Glad it is working for you :)
@Rosko
All Thank you all for you hard work on this. I seem to be struggling and being a newbie I am at a loss.
I have performed the following:
- Created two policies:
-- 1.) One to cache the Install macOS High Sierra.app in the /Applications folder - works successfully
-- 2.) The current self-service policy to install the OS using the script provided by Rosko from GitHub https://github.com/kc9wwh/macOSUpgrade
Issue: the Splash screen appears "Please wait as we prepare your computer for the macOS High Sierra..... This splash screen sat here overnight.
Troubleshooting:
- Looking through the install.log from /var/log/install.log I do not see any errors or the startosinstall
- Looking through the JAMF.log it says "Executing Policy CPA-AllCampus-macOS High Sierra Upgrade
- In JAMF I receive the following:
What am I missing?
Thank you in advance!
@lee.smith Take a look at the issues listed on GitHub, specifically:
- startosinstall sometimes does not run
- Can't find start osinstall via JAMF
There have been some issues around the AssetCacheLocatorService, but we're not sure whats causing it. If you issue lines up, please try some of the suggestions their. If they work I'll add them into the script.
@Rosko
Thank you for getting back with me. I apologize for not getting back with you sooner.
I found the issue.
There was something wrong with the install macOS High Sierra.app. I could not even launch it manually. I created it on a VM using Extended Journal. So, this might had something to do with it. I grabbed another physical computer and built it from there. Seems to be working now.
I also had to hard code the User Variables in the script. As they were not working when inputting them into JAMF.
But hey, it is working now. Woo Hoo!
Hey all, I just started working on this and a bit confused. I dont see anything about how when you use the cache option it does not install the installer in the Applications folder. What do I need to do to get it from the hidden JSS folder to the Applications folder? Mind you it is a DMG. I am following these directions, although they are all fairly similar as I clicked on the links above.
https://github.com/kc9wwh/macOSUpgrade
@rkovelman Searching for The button section in the following may help: Reinstall a clean macOS with one button.
@rkovelman you do not "cache" the installer in the traditional Jamf sense. Meaning, in the policy to cache the installer you do not choose "Cache" on the package. If you follow the instructions on the GitHub page, you use Composer to package up the installer, whether as a DMG or a PKG. If you install that PKG/DMG it does not run the OS installer, it simply places it where you want it.
So if you want the installer in /Applications, just install your DMG file. It will copy the OS installer into the folder and it will be there for the script to run against.
Make sense?
@stevewood i get what you're saying but I don't at the same time. As of right now the machines that need the upgrade have the 5GB installer in that hidden JAMF folder. Could I execute a script to open the DMG, and copy the contents of that into the Applications folder? Once that is done I can then have it delete the DMG file? I would think the whole point is to cache the file to the machine 1st, and then unpackage it. I dont see a way with the composer to have it install the file in the Applications folder.
@rkovelman First make sure the OS installer is in the main Applications folder where you want it to go, then in Composer, drag the installer into the sidebar (Sources) list. It will copy the installer in and create a new source, that you will likely want to rename, then build the package as a pkg or dmg file.
When the package gets deployed it will 'install' the installer into that location, but not run it. That's what the script is for.
Incidentally, you could install the installer in any location you want to, but would need to slightly modify the script to point to the correct location as well as using a different sed command to get the installer name. I'm doing that in my version of the script for this process. The main Applications folder is not a hard fast rule, just a suggestion and the script has some hardcoded stuff in it that expects it to be there. But it can be changed if you prefer.
@rkovelman Here's a screenshot of @mm2270's suggestion. (I prefer to build as a DMG.)
@dan.snelson I did that and clicked DMG. From a cache perspective, it still places it in the hidden folder. My guess is to run the cached policy and it will throw it in the Applications folder? From there it should work as normal, no? I think that is the missing step most fumble on?
@rkovelman the problem is you need to use "install" in the policy as the action for the package, not "cache". If you use cache then yes the package will just sit in that folder until something acts on it. Change it to install and when it runs it will place it in the Applications folder.
Edit: I think to add, where you're getting tripped up is that this isn't a real "cache" as in a Jamf caching process. Think of it like installing an app like Firefox or Google Chrome. You wouldn't (normally) set up a policy to cache that, then install it later, unless there was a specific reason for that. Usually you just tell the policy to install FF or Chrome and it lands in the Applications folder. This is the same thing, just that it's installing the Install macOS High Sierra.app. Folks here use the term 'cache' because it needs to be differentiated between running the actual app and "installing" High Sierra on the Mac. Make sense?
@rkovelman When you drag "Install macOS High Sierra.app" to Composer, is it located in the Applications folder or your hidden folder? (Please see mm2270's instructions above.)
@mm2270 thanks, setting up a test machine and will do that!
@dan.snelson its in the applications folder. By default when you cache a policy it goes to a hidden or locked JAMF folder. As mentioned above it sits there waiting to be executed on.
@rkovelman Thanks for clarifying. As mm2270 mentioned, your policy should install the DMG, not cache it.
So running the cache seems to work. Since I am using the script from Josh, is there a line that states its already installed. Reading over the script it seems like it will try to download it and then install it. Since the .app is already installed, it just needs to execute on it.
