Hi Martin,
we're upgrading to Mavericks using createOSXinstallPkg (in Germany, UK & US) and i've never seen that happening so far...
But we're on 8.73.
What could be different between Europe and the US?
OS language/regional settings of the user running Self Service?
Ours are mostly set to US English, but I can't imagine that this matters to the upgrade process.
Weird...
I didn't want to just echo Chris but we haven't had an issue either.
I took the /Applications/Install OS X Mavericks.app and dragged it into Casper Admin and sorted out the metadata.
I cached the package out to a target machine and ran Recon on it afterwards.
I created a policy with the app/scope/selfservice that installed from cache.
I ran it within SelfService and it rebooted the machine.
Upon reboot it started the installation which took about an hour.
Once the machine was back up, it presented a login to the end user, and they logged in without bother, after selecting to sign-in to iCloud.
So that was my experience and, yes, I also referenced the same document to a degree.
Thank you both for your information. I'm located in the Netherlands. Computers have Dutch or English as default language and that does not seems to be the issue.
Hi Martin,
I experienced the exact same thing in the US using Casper Suite 9.21. Used self-service but the install was not automated and I had to go through the normal process of selecting a disk, agree with the software license, etc. As of yet I haven't been able to resolve the issue. Would really like to know more.
I followed JAMF's new guide specifically for 10.9 here: http://www.jamfsoftware.com/libraries/media/casper-suite-in-place-upgrades_1920x1080.mov
I am seeing the same here in Germany. I was not able to test more on it but would also be interested in a solution or explanation :)
I did a clean install of OS X 10.8 and used createOSXinstallPkg to create the OS X 10.9 Installer. I manually installed this one and that worked. The problem could be within the bless command of the Policy because the policy overwrites the bless command the the createOSXinstallPkg uses. I extracted the NVRAM parameters just before the restart:
$ nvram -xp
<?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>LocationServicesEnabled</key>
<data>
AQ==
</data>
<key>SystemAudioVolume</key>
<data>
MA==
</data>
<key>bluetoothActiveControllerInfo</key>
<data>
CAAPDoQ4NVNXLQ==
</data>
<key>efi-boot-device</key> <string><array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>25B8F381-DC5C-40C4-BCF2-9B22412964BE</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict><dict><key>IOEFIBootOption</key><string>config="OS X Install Datacom.apple.Boot"</string></dict></array></string>
<key>efi-boot-device-data</key>
<data>
AgEMANBBAwoAAAAAAQEGAAARAQEGAAAEAxIKAAAAAAAAAAQBKgACAAAAKEAGAAAAAACQ
YOYEAAAAAIHzuCVc3MRAvPKbIkEpZL4CAn//BAA=
</data>
<key>fmm-computer-name</key>
<data>
TWFydGlu4oCZcyBNYWM=
</data>
<key>install-product-url</key>
<data>
eC1vc3Byb2R1Y3Q6Ly8wQTgxRjNCMS01MUQ5LTMzMzUtQjNFMy0xNjlDMzY0MDM2MEQv
T1MlMjBYJTIwSW5zdGFsbCUyMERhdGE=
</data>
<key>platform-uuid</key>
<data>
AAAAAAAAEACAAAAMKUa09w==
</data>
<key>prev-lang:kbd</key>
<data>
RW5nbGlzaDow
</data>
</dict>
</plist>
At this very moment I can not compare these nvram settings with the bless command of the Policy.
Decode of the efi-boot-device key:
<array>
<dict>
<key>IOMatch</key>
<dict>
<key>IOProviderClass</key>
<string>IOMedia</string>
<key>IOPropertyMatch</key>
<dict>
<key>UUID</key>
<string>25B8F381-DC5C-40C4-BCF2-9B22412964BE</string>
</dict>
</dict>
<key>BLLastBSDName</key>
<string>disk0s2</string>
</dict>
<dict>
<key>IOEFIBootOption</key>
<string>config="OS X Install Datacom.apple.Boot"</string>
</dict>
</array>
The postflight script of the createOSXinstallPkg blesses the OS X Installer boot files so that on reboot, the machine boots into the OS X Installation environment (which is a fancy boot-from-dmg arrangement). If bless is run again before the reboot and changes parameters, then all bets are off as to what will happen next.
Apologies.. This solution suits re-imaging from a NetBoot standpoint and not a Self Service policy.
I was having this issue as well. Casper Imaging was not allowing Greg's package to run as long as a valid system was installed. In the end, I created a package w/postflight which removes the CoreServices folder in order to allow re-imaging. The folder needs to be dealt with in order to allow the formerly blessed 'OS X Install Data' folder to remain as the successor.
This is the output of the NVRAM after the Self Service Policy followed by the JAMF Software manual:
$ nvram -xp
<?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>SystemAudioVolume</key>
<data>
Ww==
</data>
<key>backlight-level</key>
<data>
3wE=
</data>
<key>efi-boot-device</key>
<string><array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>ACE3324E-F6BC-48F9-A5E9-19F8060FB6CD</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict><dict><key>IOEFIBootOption</key><string>config=/OS X Install Data/com.apple.Boot.plist</string></dict></array></string>
<key>efi-boot-device-data</key>
<data>
AgEMANBBAwoAAAAAAQEGAAIfAxIKAAAAAAAAAAQBKgACAAAAKEAGAAAAAAAg1RU6AAAA
AE4y46y89vlIpekZ+AYPts0CAn//BAA=
</data>
<key>install-product-url</key>
<data>
eC1vc3Byb2R1Y3Q6Ly9CQzg3NTExMy03NUFGLTM2MEUtOTBERS1BRDhFNDMxRUJFNEEv
T1MlMjBYJTIwSW5zdGFsbCUyMERhdGE=
</data>
<key>prev-lang:kdb</key>
<data>
ZW46MA==
</data>
</dict>
</plist>
Decode of the efi-boot-device key:
<array>
<dict>
<key>IOMatch</key>
<dict>
<key>IOProviderClass</key>
<string>IOMedia</string>
<key>IOPropertyMatch</key>
<dict>
<key>UUID</key>
<string>ACE3324E-F6BC-48F9-A5E9-19F8060FB6CD</string>
</dict>
</dict>
<key>BLLastBSDName</key>
<string>disk0s2</string>
</dict>
<dict>
<key>IOEFIBootOption</key>
<string>config=/OS X Install Data/com.apple.Boot.plist</string>
</dict>
</array>
So far I can not see any difference. I do noticed a difference in the minstallconfig.xml file:
createOSXinstallPkg creates:
<?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>InstallType</key>
<string>automated</string>
<key>Language</key>
<string>en</string>
<key>Package</key>
<string>/System/Installation/Packages/OSInstall.mpkg</string>
<key>Target</key>
<string>/</string>
<key>TargetName</key>
<string>Macintosh HD</string>
<key>TargetUUID</key>
<string>0A81F3B1-51D9-3335-B3E3-169C3640360D</string>
</dict>
</plist>
Casper Suite creates:
<?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>ChoiceChanges</key>
<string>MacOSXInstaller.choiceChanges</string>
<key>InstallType</key>
<string>automated</string>
<key>Language</key>
<string>en</string>
<key>Package</key>
<string>/System/Installation/Packages/OSInstall.mpkg</string>
<key>Target</key>
<string>/Volumes/Macintosh HD</string>
<key>TargetName</key>
<string>Macintosh HD</string>
<key>TargetUUID</key>
<string>BC875113-75AF-360E-90DE-AD8E431EBE4A</string>
</dict>
</plist>
After launching the OS X Installer on reboot I opened the Insteller Log and noticed this line:
Ignoring stale automation file /Volumes/Image Volume/OS X Install Data/minstallconfig.xml (time since IA = -3471.239602)
Looking into the OSInstallAttr.plist file (located within the OS X Install Data folder):
<?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>IAEndDate</key>
<date>2013-12-12T11:13:59Z</date>
<key>IALogFile</key>
<string>/OS X Install Data/ia.log</string>
<key>OSIAutomationFile</key>
<string>/OS X Install Data/minstallconfig.xml</string>
<key>OSSourceDiskUUID</key>
<string>BC875113-75AF-360E-90DE-AD8E431EBE4A</string>
</dict>
</plist>
Compared to the createOSXinstallPkg:
<?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>IAEndDate</key>
<date>2013-12-11T10:31:13Z</date>
<key>IALogFile</key>
<string>/Volumes/Macintosh HD/OS X Install Data/ia.log</string>
<key>OSIAutomationFile</key>
<string>/Volumes/Macintosh HD/OS X Install Data/minstallconfig.xml</string>
<key>OSSourceDiskUUID</key>
<string>0A81F3B1-51D9-3335-B3E3-169C3640360D</string>
</dict>
</plist>
Changed Target key in minstallconfig.xml to / doesn't make a difference.
For now I created a workaround:
- Create install package with createOSXinstallPkg
- Cache package on client
- Install Cached package on client via Self Service
- Do not reboot the client via the predefined Restart options but configure Files and Processes and Execute Command "shutdown -r now"
So that definitely points to something Casper is doing as part of the predefined Restart options -- it's altering the blessed boot in some manner.
This bit:
Ignoring stale automation file /Volumes/Image Volume/OS X Install Data/minstallconfig.xml (time since IA = -3471.239602)
Means it's been too long since the OS X install automation file was created; the machine needs to be rebooted within a few minutes after this file has been created, or the install automation is skipped and you are presented with the Recovery partition-style OS X Utilities window.
I don't know how long counts as "too long". 30 minutes is definitely too long; 5 minutes seems not to be.
Thanks for making that clear. The policy was set to restart immediately so the installation will take place within 5 minutes. Due to testing the message was captured at a later time. Will try to capture the log asap the OS X Installer starts for the first time.
We have seen a similar, but slightly different issue. We have test about 40 machines an it works like we want without user interaction on about 36 of them, but about 4 of them were prompted to agree to terms and select disk to install to. Our configuration is the same with the install cached being the way that the user installs from Self Service.
Still trying to find out what is causing this. I started the upgrade (again) as described by the JAMF document:
After launching the OS X Installer on reboot I opened the Insteller Log and noticed this line:
Ignoring stale automation file /Volumes/Image Volume/OS X Install Data/minstallconfig.xml (time since IA = -3493.212313)
Opened Terminal:
-bash-3.2# date
Tue Dec 17 04:53:34 PST 2013
-bash-3.2# ls -la /Volumes/Image Volume/OS X Install Data/
total 10366320
drwxr-xr-x 13 root wheel 442 Dec 17 04:50 .
drwxr-xr-x 31 root wheel 1122 Dec 17 04:48 ..
-rw-r--r--@ 1 root wheel 1037 Dec 17 04:50 .disk_label
-rw-r--r--@ 1 root wheel 4157 Dec 17 04:50 .disk_label_2x
-rwxr-xr-x 1 root admin 5290551900 Dec 17 04:31 InstallESD.dmg
-rwxr-xr-x 1 root admin 182 Dec 17 04:50 MacOSXInstaller.choiceChanges
-rwxr-xr-x 1 root wheel 481 Dec 17 04:50 OSInstallAttr.plist
-rwxr-xr-x 1 root admin 4308 Aug 24 18:40 PlatformSupport.plist
-rwxr-xr-x 1 root admin 505400 Aug 24 22:31 boot.efi
-rwxr-xr-x 1 root admin 398 Dec 17 04:50 com.apple.Boot.plist
-rwxr-xr-x 1 root admin 491 Dec 17 04:50 index.sproduct
-rwxr-xr-x 1 root admin 16451177 Oct 16 21:27 kernelcache
-rwxr-xr-x 1 root admin 630 Dec 17 04:50 minstallconfig.xml
These is a time difference of just 3 minutes between the creating of the minstallconfig.xml file and the start of the OS X Installer. Still it's ignoring the automation file.
Ok, I finally found what it causing this issue!
It's the IAEndDate key that is located in the OSInstallAttr.plist file.
Date was set to 2013-12-17T15:05:13Z by default.
I set the date to 2013-12-18T15:05:13Z but apparently this just works the other way around because now I got:
Ignoring stale automation file /Volumes/Image Volume/OS X Install Data/minstallconfig.xml (time since IA = -89843.891604)
I set the date to 2013-12-16T15:05:13Z and guess what, it's finally automated! Sent an update to JAMF and hopefully they will fix this soon.
Just a crasy idea - could you try to set the timezone on this computer to MN? Maybe its a storage timezone/timing issue?
@jomo, that doesn't seems related as the Pacific Time Zone is used for the configuration files and OS X Installer.
@martin][/url I altered the IAEndDate and tried setting it to a day before and then tried again with setting it to a day after the current time. Neither worked. I then set the IAEndDate to about 13 minutes before the install attempt and it worked fine. Do we know what the installer considers to be "stale"? 15 minutes, an hour, a day? It doesn't make much sense unless JAMF is running this incorrectly and setting an incorrect date on IAEndDate. The policy we have reboots the computer immediately after it sets everything up, so the longest I can think would be 4 minutes between the policy running and the installer beginning. I can't imagine that this is getting stale. If a work around is to set this via policy to something in the near past we can, but I just need a workable time frame.
I did determine that the time zone (of the OS X Installer) is set to Pacific even though the computers are Central. This means that the current time of the computer when creating IAEndDate is 2 hours off already for us. However, in my tests, I have changed it to 10 hours before current time and it works properly. This doesn't make much since.
Have not tried yet this but maybe this is a workaround. Create a script that runs "after" the policy and does the following:
#!/bin/sh
ia_end_date=`date -v-12H +"%Y-%m-%dT%H:%M:%SZ"`
defaults write "/OS X Install Data/OSInstallAttr.plist" IAEndDate $ia_end_date
Martin,
I've uploaded a script that's very similar to what you have here that resolves this issue.
I've posted the script to: https://jamfnation.jamfsoftware.com/viewProductFile.html?id=1&fid=679
We've also filed a defect on this and have verified that the impact is that any system that is located in a timezone ahead of UTC would be affected by this issue.
Thanks to everyone on this post for helping us narrow down the issue.
Nick
Hi Nick,
Thanks for the update. I downloaded your script and the one thing I noticed it that it does not change the time or day. I have not tried it yet but the script I've posted will set the time 12 hours earlier to make sure we are within the AIEndTime.
hmm.....i just tested it here too. @nick Script doesn't change the date entry and therefore the upgrade still fails.
Then i tested Martin's script and that works for me. automated upgrade is running without asking questions. thanks for all the work you guys have put in this!
Not sure why there's any date formatting in the scripts:
bash-3.2$ d=date
bash-3.2$ defaults write com.foo SomeDate -date "$d"
bash-3.2$ defaults read com.foo
{
SomeDate = "2013-12-19 14:07:18 +0000";
}
