I’ve let your Technical Account Manager know that you’re having difficulties with this, and he should be reaching out to you soon.
We’ll want to get some more information on what workflows are in place and dig into the details a bit more, and since a lot of that could contain identifying information, it’s not something I’d want to ask that you post here.
I did find an older thread revolving around the Adobe Temporary Installer account seeming to hang the imaging process; if you haven’t seen it already, I’d recommend taking a look as the workarounds mentioned in those threads may help here:
JAMF Software Support
I've noticed lack of block copy (SMB) in 2 test environments using Casper Imaging 9.7 and 10.10.2. The NBI(s) were created using AutoCasperNBI v1.1.4
I haven't been able to test more recent builds of AutoCasperNBI or NBI's created using manual methods. Older builds using version 9.65 of Casper Imaging working as expected.
FYI, I am using 9.7 (Both JSS and imaging) on a 10.10.2 NBI and all is working very very well. Block copy works, complied images work, and the new ability to create and deliver restore partitions. This is via AFP though. I have also tested all of these versions against AutoCasperNBI (1.1.7 pre-release) and they're 100% good to go.
I've been out of the office, so haven't had a chance to work with our test environment. However, I did a bit of work in my home lab ...
After running the latest 10.10.3 release through AutoDMG, and updating AutoCasperNBI-created .nbi to match (i.e from aforementioned 10.10.3 AutoDMG build), block copies are good to go with JSS v9.7, Casper Imaging v9.7 and SMB (and AFP) shares. I'm testing/successful with both NetSUS and BSDPy for NetBoot service.
For me, the issue seemed to be with 10.10.2 (at least the 10.10.2 builds I've been using) and Casper Imaging v9.7 (v9.65 worked as expected). It didn't seem to be an issue of AFP vs SMB, as I created an AFP share, replicated and still didn't have any block copy love. That said, previous 10.10.x were such a bag of hurt that I'm just going to focus on 10.10.3 and not look back.
For what it's worth, I had to roll back Composer and Casper Imaging to 9.65. Re-created my 10.10.3 BaseOS in Composer 9.65 (no Recovery Partition in dmg), laid down new BaseOS image using Casper Imaging 9.65. That worked.
I am having this issue with using Casper Imaging from an external Thunderbolt drive.
Booting to a primary partition on the external (updated to 10.10.3 as was on 10.9.4, didn't help).
I'm using Casper Imaging 9.7, and it says: Block copying (takes about .5 seconds), then goes to erasing drive after the block copy, even though it is supposed to erase before the block copy. Then it tries to install my AutoDMG created 10.10.3 installer after the erase. I'm sort of at a loss, as I have never experienced this before. I will try rolling back to Casper Imaging 9.65 and see what happens.
So much for not looking back, lol ...
Back at work, I found that with iTunes 12.1.2 added to AutoDMG build, block copies would fail (pattern that @guidotti lists above would take place). The success I was having at home with 10.10.3 and Casper Imaging 9.7 didn't include any additional updates or software. As soon as I removed iTunes from build, block copies were good. I didn't get a chance to swap out Casper Imaging (revert to 9.65), but I expect that will be the workaround for now.
update: replaced Casper Imaging v9.7 w/ 9.65 in NBI's and all OS configurations block copy
Running Casper 9.7 JSS, JDS, and Imaging:
It seems during the imaging workflow, any packages added to the FirstRun section of the process (packages marked "Install on reboot") spontaneously change from the original PKG icon to the Adobe Install PKG icon during the FirstRun preparation. I also noticed that "defaults read /Library/Preferences/com.apple.loginwindow "autoLoginUser"" returns "adobeinstall" as the autologin user. I install no adobe products during my imaging workflow.
This broke my actual autologin user I created with CreateUserPkg to facilitate the rest of my imaging process. I now have to install this user pkg "At reboot" (during FirstRun) rather than during imaging because the user account does not get created properly otherwise.
I have since added a script to be run "At reboot" during the FirstRun that corrects '/Library/Preferences/com.apple.loginwindow "autoLoginUser"' to my intended user and autologin is functional again. This is a pretty serious bug. I am unaware of what other effects installing regular packages as "Adobe Install" packages there might be.
I had to go back to Casper Imaging 9.65 on everything and also change my SMB distribution point URL to use the IP address instead of the DNS name. After that, all my stuff started working properly again...for now...
@gtucker that's normal.
PKG's set to be installed at reboot do change icon to be Adobe style when cached locally, & the account that Casper creates to install items marked as "Install At Boot Volume During Imaging" is called "adobeInstall" & is set to auto-login as it.
So what you're seeing as a serious bug is normal behaviour of the suite.
Oh really? Interesting. I was forced into installing my createuserpkg's on the FirstRun because casper 9.7 would not install any createuserpkg's that were configured for autologin. The pkg install would fail during the workflow and derail the rest of the process. Imaging with 9.65 installs the createuserpkgs fine during imaging and not during FIrstRun.
Also completely broken for imaging from a pure JDS environment where you haven't enabled AFP. In our case, this is a deal breaker. We've decided to abandon Casper Imaging completely at this point. Our NetBoot image now includes a custom scripted process, utilizing cocoaDialog, to use asr to image the drive (if needed) directly over https and a custom ultra-thin provisioning package that utilizes the First Boot Package Install hosted on @rtrouton git repository.
First Boot Package Install: https://github.com/rtrouton/First-Boot-Package-Install
asr restore --source https://jds.server.com/CasperShare/os_image.dmg --target /dev/disk0s2 --erase --noprompt
Edit: Quick warning about the above ASR command. Make sure you know what you're doing when you run it. It erases and re-images a drive (disk0s2) without asking for any confirmation.
Another option many be to install the CreateUserPKG PKG & then as part of a post install policy set the autologin to that user in the com.apple.LoginWindow.plist.
This is very frustrating - not getting anywhere fast. The posts by @CGundersen looked hopeful so I followed a similar pattern:
When I fire up the NetBoot and deploy a config through Imaging, the OSX build that is in that config goes to "Installing" rather than the block copy mode with associated progress indicator.
Aside from it being slower to deploy the image, I just don't trust the Install mode as much (rightly or wrongly).
An update to this with 2 findings.
We are in the process of deploying 25 new iMacs.
I've noticed that:
The new iMacs ship with their disks showing as being set up as a Logical Volume Group (I believe this might be something to do with CoreStorage?). Each iMac contains a single 500GB SSD. Selecting the option in Casper to erase the disk prior to install nukes the Logical Volume Group and the disks then just show up normal hard drives. I mention this just in passing and is possibly not particularly pertinent to this thread.
Secondly, with the setup that I describe in my post above, if I wipe the drive using Disk Utility and then deploy the configuration from NetBooted Casper, I get the "installing" mode of OS DMS deployment. However, to my relief, if I select the option within Casper to wipe the disk prior to deploying, the block copy works fine. Happy Days. That is with Casper 9.65 (as mentioned in previous post). I will try with Casper 7.1 and report back.
Hurrah. All working beautifully again now on both 9.65 and 9.71.
Fully up to date on every front:
- brand new spanky Retina5k iMacs
- Casper 9.71
- OS on Netboot and for Deployment = 10.10.3
I can pick up where I was with this deployment configuration setup about 3 days ago. Fix for me seems to simply be ticking on the "erase drive before install option" rather than using the Disk Utility erase. Perhaps it is well known that this is the required process.
I'm interested to investigate the CoreStorage part (mentioned in 1 above) as this is new to me but as far as the issue on this thread goes, all is good here.
Guys, Casper Imaging has always worked that way as long as I can remember.
I always have to check erase disk or it will not do a block copy.
I thought that was just how it worked.
Does 9.71 imaging fix those issues we were having with 10.10.3 or do we still need to bake in 9.65 imaging?
Fair enough. I still think it was worth spelling out my situation as there are people above (e.g CGundersen) having problems with 9.7 and also here https://jamfnation.jamfsoftware.com/discussion.html?id=13184 whereas it seems to work fine for me. Perhaps they are falling into the same trap.
Right, so the issue there is twofold. There were problems with Casper Imaging prior to 9.65, and there were also problems with OS X 10.10.2. Their interaction was catastrophic for some folks, including me. Once we got to 10.10.3, Casper Imaging 9.65 worked straightaway, but 9.7 fails. That's why I was wondering if 9.71 fixed anything. I am out of the office today and can't test until Monday.
I've found that 9.71 Casper Imaging does indeed fix issue I was having with block copies (e.g AutoDMG with updates/extra software as part of build). Testing was with SMB distro, BSDPy hosted NetBoot and AutoCasperNBI-generated NBI.
edit: block copies good with 9.72 as well
just got this.
I hope that this email finds you doing well!
I wanted to reach out regarding our 9.71 release that came out yesterday afternoon. It has come to our attention that there are a couple of items that were intended to be in the 9.71 release that were marked as resolved in the release notes that are not fixed. These items are D-008880 and D-008907. Both of these items are related to the http download of packages and scripts from a traditional file share. We are currently working on determining how this occurred and also working to get an updated release out to you as soon as possible. Though we do not have an exact timeframe, this is currently of the utmost importance. We should have a new release available within the coming days that will address these items.
Please feel free to let me know if there are any questions on this. JAMF Software sincerely apologizes for the inconvenience that this has created. We just wanted to bring this to your attention as soon as we could.
Manager, Commercial Accounts
Just tried netboot imaging with 9.71. Erase with Disk Utility and install base image and it hangs at Installing Package. Erase drive with Casper Imaging, block copy and all is well. Only seems to affect the imaging of a newly erased drive as I can apply my thin image configuration normally. Images on the NetSUS appliance served over AFP (I think, not sure if AFP is the default on the NetSUS appliance. Doesn't seem to be a setting that can be changed.)