I've been trying to do this a couple of times now, following the instructions on https://www.jamf.com/blog/reinstall-a-clean-macos-with-one-button/ to the point, but it just gives back
> Result of command:
> Usage: startosinstall --volume <target volume path>
in the JSS log.
And the machine does nothing, Self Service still in focus. No difference if I add the '--volume' flag, it behaves the same. The command runs just fine if I type it directly into Terminal on the machine that I want to reinstall.
And yes, the machine has an APFS disk.
Any suggestions? Thx.
@larsc you need to quit Self Service as part of the script, since JAMF 10 this does not stop already initiated policeis from completing.
Something like as follows.
#!/bin/bash osascript -e 'tell application "Self Service" to quit' /Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall --applicationpath /Applications/Install macOS High Sierra.app --eraseinstall --newvolumename "Macintosh HD" --agreetolicense --nointeraction
Try the Erase&Install.app from ProWareHouse via https://bitbucket.org/prowarehouse-nl/erase-install/
Super cool application that wrapped the "oneliner" in a single app. Create a external disk, with the app and installers on it and you are done.
Or scope it to people that are going to offboard your organisation with the application, required Mojave/High Sierra installers and let them erase them self.
There are many options within this application, like unmanaging the device in Jamf or removing it etc.
I had that error a few weeks ago then i used Greg Neagle's python script to download the HS installers and had no issues after that. I suggest you give that a try, it's a very useful script.
I'm seeing this too, and can't figure out what's wrong. If I create a bootable USB drive using the same disk image it works fine.
If I try to open it from /Applications I get a message stating "This copy of the Install macOS application is too old to be opened on this version of macOS".
Downloading the installer using the "installmacos.py" script results in the same error.
@walts.9, you have a couple of unnecessary options in your screenshot. Possibly, because you've included them, you're seeing the wrong behavior.
Don't include the
You want to include the
--newvolumename option is... um... optional.
I have tried implementing this and I have a computer that is stuck in pending to deliver the installer app. I am not sure why it is not moving beyond pending. Any thoughts as to where I can look to find out why it is stuck in pending or any information I can provide on my setup to see what I might have done wrong? I am very new to JAMF and have been tasked at looking at how JAMF can help us with managing and imaging our computers. Thanks!
@franton if you are testing and want the script to delete, do I need to make this variable .. yes? And also have the --erase in parameter 4
It appears there is some important data missing in the instructions. Caching the package (silently installing) does not place the installer into the Applications folder on the device, it will place it in the Waiting Room (Library>Application Support>JAMF).
Anything after that improper instruction will not work.
More detail as to how to get the Install macOS High Sierra or Install macOS Mojave.app on the computers needs to be specified.
@mhegge Actaully, if you read it closely it never mentions caching the installer. From the instructions, step 4:
4. Next, make a policy to run the package and deliver the installer silently onto the target Macs ahead of time.
After uploading the package created in Composer in step 1 you actually run that package, or install it. Since that package is simply dropping the installer into the Applications folder the macOS installer does not run, it just gets dropped to Applications.
Otherwise it would require an additional policy to run the cached package. Which would be inefficient.
@mhegge Cache is simply a term being used here and is commonly utilized in the IT world to various degrees.
The only point to this that I see could be argued to change is the one time where it states "identify whether the Mojave installer has been cached to your Macs" and change to "identify whether the Mojave installer has been copied to your Macs". The others are fine as they're listed for Display Name and a Smart Computer Group. They're nothing more than labels describing what's intended to occur and the terminology fits even if it doesn't fit with the Jamf cache feature.
Not to sound like I'm judging or anything but anyone administering Jamf should understand that and be reading instructions carefully to understand what's going on as well as test, test, test before a real deployment.
I know my vote doesn't count but while I don't think it's a bad idea to change it I also don't think it's a necessity.
Looking over this process to see if our group will implement. I do have a few questions.
The process does seem to work from me just not sure I have it setup the correct way. Catalina pkg created and uploaded to Jamf Policy "Cache Install macOS Catalina.app" created which installs pkg if in scope, excluded if Catalina version is already in Applications. Policy "Upgrade to macOS Catalina" with Command '/Applications/Install macOS Catalina.app/Contents/Resources/startosinstall' --agreetolicense --forcequitapps. (Not erasing in this setup)
It takes about 10 minutes for the policy in Self Service to complete and reboot before the upgrade starts. After install Catalina 10.15.6 is the new version and data is intact. After reboot this policy is still in self service due to frequency set to ongoing.