9.7 and imaging

Yep, it broke mine. It tries to install the OS dmg as a package rather than doing a block copy. I've already alerted my TAM.

I just did a block copy image, in target imaging mode from SMB share. seemed to work well to me.

where has the QA team gone? that seems like a pretty big bug (checking an image workflow now).

@sardesm

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:

Image Reboot Logs Into Temporary Adobe Install Account

Thanks!
Amanda Wulff
JAMF Software Support

my quick test worked, but I used an older C.Imaging app.

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.

Just had this issue on a 2012 MBAir w/ 10.10.2 (rebooted, and it seemed to have patch to 10.10.3 though) and 9.7. Got around it by going back to C. Imaging 9.6

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 I rolled back to 9.65 as suggested, and it works fine...
So there is some sort of defect with 9.7 in my case.

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.

They need to fix this asap, killing my workflow process.

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.

@bentoms

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.

@gtucker I'm not sure of the difference between 9.65 & 9.7, & what you were doing with CreateUserPKG.. But I've followed an unchanged workflow since v7.

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.

@guidotti

Having the exact same issue you described with 9.7

going back to 9.65

This is very frustrating - not getting anywhere fast. The posts by @CGundersen looked hopeful so I followed a similar pattern:

• Casper server running 9.71
• Downloaded 10.10.3 install from AppStore
• Ran installer App through AutoDMG, excluding the download for iTunes 12.1.2
• Ran output from above through AutoCasperNBI (associated with Casper 9.65 as per above posts)
• Deployed to NetBoot Server

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:

1. 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.

2. 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.

@KarmaIT so when erasing 1st, it's block copying? Otherwise it's installing?

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.