Skip to main content

With version 9.2 of the Casper Suite we have the option to add the "Install OS X Mavericks.app” to the Casper Admin to easily create create an upgrade package. This is a great functionality but I’m facing a very strange problem. I followed all the steps in how to accomplish this with Casper Suite:
http://www.jamfsoftware.com/sites/default/files/Deploying-OS-X-v10.7-or-Later-with-the-Casper-Suite.pdf



When I start the upgrade, via Self Service, the computer reboots and starts the OS X Installer I need to manually click continue, agree with the software license agreement, select the disk and click install.



Strange this is that this behaviour is exactly the same with the createOSXinstallPkg package. In the past I have used createOSXinstallPkg to upgrade to 10.7 and 10.8 with succes.



I’ve seen this in all environments and I’ve reached out to JAMF Support and they are experiencing the same thing here in Europe. The U.S. is not seeing this kind of behaviour.



I’m kind of stuck here. Has anyone else seen this kind of behaviour? Has anyone been successful to upgrade to Mavericks fully automated in Europe?



Thanks!

The date formatting in my script was to just keep the format consistent with the format the OS X Installer writes to the OSXInstallAttr plist. I would not recommend offsetting the time, as this will break for others around the world.



The main problem as it is filed in the defect is that the timestamp needs to be set to the current UTC time, and it was instead set to local time, represented as local time with UTC formatting.



When I run this script as part of the policy that performs the installation and reboot to the OS X Installer, the OS X Installer is properly automated.


My point is the formatting and the '-u' flag have no effect -- IAEndDate is stored as an NSDate, not a string:



bash-3.2$ one=date
bash-3.2$ two=date -u
bash-3.2$ three=/bin/date -u +"%Y-%m-%dT%H:%M:%SZ"



bash-3.2$ defaults write com.foo one -date "$one"
bash-3.2$ defaults write com.foo two -date "$two"
bash-3.2$ defaults write com.foo three -date "$three"



bash-3.2$ defaults read com.foo
{
one = "2013-12-20 05:26:09 +0000";
three = "2013-12-20 05:26:15 +0000";
two = "2013-12-20 05:26:12 +0000";
}



Note they are all the same (minus a few seconds difference -- I can only type so fast!)


Hi there,
i did some testing here - first in a VM (because its easier) and then on an actual test MacBook Pro (to avoid issues caused by the VM). This way i tested all versions of the script. But it never worked. Only if i manually run the script before rebooting. Could it be that there is anything overwriting this file again after the Policy is done?



Another issue is - the Upgrade starts automatically then - but it never finishes. I left it running for hours.



Now i am confused....maybe its just an issue in my environment. If i don't automate - just run the Installer, then the Upgrade takes place. Could anyone confirm if the Upgrade work for him - automated and in EMEIA?



EDIT: going to download 10.9.1 now and test again with this one.


So - a update on this one. I don't think it is related to the OS X Version. But now, instead of using the script to change the Content of that file - which was not working somehow - i just added on line to set the timezone to America/Chicago



systemsetup -settimezone America/Chicago


Now the Installation runs automatically. Another Policy will run at startup and set the timezone back to my timezone. Thats working for me until its fixed.



Another issue i experience is: even tho i tell the Policy to restart - it does not restart. I get some errors in the Syslog with a launched-error..... still investigating on this one....


@jomo, are you on 9.22?



From other reports it looks like there may be an issue with restarts & 9.22.


Reply