Casper Imaging + 10.10.2 = No Block Copy

[cbrewer]

Anyone seeing issues with Block Copy Imaging while on 10.10.2? I've tried 10.10.2 NetBoots sets as well as an external drive running 10.10.2. My imaging process fails to block copy and drops back to the slower "installing." My previous NetBoot set was running 10.10.0 and I didn't see this problem. I'm running 9.63 and my distribution points are SMB.

[danielc29]

I'm having the same problem with 10.10.2 running from the NetSUS. I used AutoNBI to create the boot image. I created my 10.10.1 netboot image the same way but didn't have this issue. JSS on 9.6. I went back to my 10.10.1 netboot and was going to recreate the 10.10.2 netboot thinking I did something wrong.

[RobertHammen]

What is your source for the OS? I use AutoDMG to make never-booted up-to-date base OSes. Have a 10.10.2 one but have yet to image a machine with it. Only glitch I've ever had with this approach in the past is forgetting to set the priority of the OS image to 1...

[danielc29]

I downloaded OSX Yosemite.app and ran it through autoDMG first. I used the created DMG to deploy 10.10.2 and to build the NBI. The DMG deployment from imaging deploys perfect. I didn't have any issues with it until I tried to netboot with the new NBI

[cbrewer]

I'm also using AutoDMG to build my source OS's. To be clear, though, it doesn't which never-booted base image I'm trying to deploy. I attempted to install a 10.9.5 image while booted to 10.10.2 with the same result - no block copy.

[MeagerGnome]

I noticed this yesterday with my new AutoDMG 10.10.2 dmg. Reverted to Casper Imaging 9.61 and it works fine now.

[cbrewer]

I've tried Casper Imaging 9.61, 9.62 and 9.63 here all with the same results. For me it seems that running Casper Imaging on top of 10.10.2 is the common problem, regardless of Casper Imaging version.

[kstrick]

I'm having a similar issues with my 10.10.2 netbooy - Didn't see the issue on my 10.10.1 netboot with same version of casper imaging.

[timdambrosio]

Same problem for me. Made 10.10.2 base image with AutoDMG which works fine for deployment from a 10.10.1 netboot set. Used that same 10.10.2 base image to make a netboot set and I don't get any block copy action when deploying the same image.

[MeagerGnome]

@cbrewer, I should have mentioned that my NBI with Casper Imaging 9.61 is based on 10.10.1. I believe you are correct about it being related to the NBI version, not the Casper Imaging version or the OS being deployed.

[jescala]

Just chiming in here. I'm seeing the same behavior since I upgraded my NBI to 10.10.2 using 9.63.

[dmueller]

I'm seeing the same behavior using an external boot drive with 10.10.2. It installs the image DMG instead of doing a block copy. Booting with a 10.10.1 disk and the same (current) Casper Imaging app does the block copy fine.

Regards,

[bthomason]

I can't do target mode imaging.

[joecurrin]

Using 10.10.2 with AutoDMG, and we aren't having any issues. Do any of you attach any packages to your base image? We have a small package run to write a plist, which marks who created the image. It is worth a shot throwing on a small package to see if that fixes your issue.

[maccentric]

It looks like it has nothing to do with target mode or netboot, it has to do with Casper Imaging running on a host OS with the version 10.10.2, that is what I am seeing with my testing. Block copying is not working

As long as you have casper imaging running in a host OS that is not 10.10.2 (eg. 10.10.1) than block copying will work

So I reverted back to 10.10.1 and I am imaging my machines via TMI and Netboot to 10.10.2 with no problems.

[powellbc]

To clarify, other than slower imaging speeds, are there any other deleterious effects of installing vs. block copy when imaging?

[bthomason]

I'm attempting to do a 10.10.1 host with Casper Imaging, I will post my results.

[RobertHammen]

Can confirm it seems to be Casper Imaging having an issue imaging 10.10.2, when booted from 10.10.2. It does a "file-by-file" copy, rather than a block copy. Has anyone reported this to JAMF yet?

[maccentric]

yeah reported to JAMF

[kstrick]

@powellbc I think the main downsides are---
- Speed
- Restore partition may not copy

I think that Casper Imaging may be switching to another method as it sees some obstacle to using block copy....
(I think it is possibly stepping down to ditto, instead of using something like ASR, or maybe it's just ASR in a lower mode?)

[maccentric]

Block copy is block-for-block, the resulting destination is precisely like the original (this is simply impossible with a file-level clone) and the speed is one giant file being copied piece by piece... a lot faster.

When block copy can not happen then it enters a file-level copy... file by file and OS X has millions of files, so there is a longer wait.

[powellbc]

Thanks for the info guys. The restore partition thing is a deal breaker. I need to somehow get my hands on a 10.10.1 installer it sounds like.

[strider_knh]

From my testing I am having problems using Casper Imaging on a 10.10.2 station, regardless of what OS version I am laying down.

I use Target Boot imaging mostly. My source station is running 10.10.2 and tried to lay down a few imaged as a test. Used Casper Imaging 9.62.
1) 10.101.2
2) 10.10.1
3) 10.9.3

All three times it did the install and not the black copy. Each time it would finish but when I rebooted the target station it would not load the OS. Each time it would start and then just sit there. For the 10.10 stations it would sit at the black screen with the Apple logo and progress bar half way.

I then performed the same installs using a Mac OS 10.9.5 station and each one performed a block copy and the OS booted after the restart.

[maccentric]

@strider.knh it is your source station.
Can't be 10.10.2

Remember your OS that Casper imaging is running on can't be 10.10.2

I can lay down any OS version as long as I have Casper imaging running on a computer or NetBoot image that is 10.10.1

[cbrewer]

Jamf just confirmed this is an issue. Their words:

"After they looked into it they determined there was some legacy version checking code that actually interfered with version 10.10.2. The code has been removed and things should be back to normal with the release of version 9.64."

[adamlalicker]

So we just have to wait? Do we know when the release will be?

[nessts]

I think its more devious than just the block copy, i was noticing package failures different ones each install, and without casper when booted to 10.10 and installing, i went to a 10.9.3 image and installed the OS, and packages and it works fine. So, I am not sure we should be blaming JAMF because of problems with 10.10.x

[bentoms]

@adamlalicker, there is no need for a 10.10.2 NBI as no hardware will ONLY boot to that version. So reverting to a 10.10.1 NBI should work.

[#29]

Since Yosemite, a lot of modern hardware ships with the internal storage preconfigured as CoreStorage. Saw a full-up image (booted from Mavericks, but Casper Imaging 9.63) taking forever today and realized it was doing file-by-file copies. Stopped it, ran Disk Utility, saw the machine was CoreStorage (it likely shipped with Yosemite), reverted it to JHFS+, and reformatted the drive, and Casper Imaging 9.63 did a block copy. So who knows if that has anything to do with it...

[CorpTech]

I've been running into the same errors as everyone else with 10.10.2 as the host machine.

It just does that installing package as opposed to the block copy. I've done everything I can possibly think of and I cannot get this resolved at all.

Just for more background, I use Target Mode imaging.

I've been working with support and my TAM for 3 days now and they think it has something to do with the antivirus. I'm using Sophos and have never had an issue until now, even when we were using Symantec. I highly doubt antivirus could possibly play into this, but maybe someone else out there can confirm this.

I was able to image ok using a boot volume with 10.10.1 and using Casper off of that. So I think I can agree that 10.10.2 is the root cause here.

On that same note, is there any official word on when an update or fix is going to be in place? I can get by for now, but it would be nice to at least have a timeline as to where this sits.

[emily]

Per my account manager:

There is a defect with a machine running 10.10.2 that it will not block copy - D-008472.

So at the very least keep an eye out for D-008472 in future release notes.

We use a USB boot disk for Casper Imaging… I re-formated it with 10.10.1 and it works fine. Casper Imaging 9.63 just doesn't like 10.10.2 for some reason.

[bentoms]

@RHammen, https://macmule.com/2015/01/02/casper-imaging-corestorage-volumes/

[scottb]

Confirmed that 10.10.2 as a boot source is the block copy problem (or one of them).
Went back to 10.9 5 boot source and it was OK.
JSS 9.62.

[CorpTech]

anyone heard when the fix (9.64) might be coming out?

[emily]

@CorpTech my account manager stated that it should be a bug fix in the release of 9.64. Just look for D-008472 in future release notes.

[RobertHammen]

I'm guessing, based on previous release history, we'll see an update within weeks, not months. JAMF have been trying to squash bugs in the 9.6.x chain without hopefully introducing too many new ones ;-).

[powellbc]

In case anyone missed it, 9.64 is now out:

[D-008472] Fixed an issue that caused an OS X v10.10.2 DMG with a priority of “1” to copy excessively slowly when using Netboot or Target Mode Imaging.

[nessts]

i saw it and now cannot image at all with 9.64. I will try to get back with a resolution, but be careful out there.

[scottb]

Well that's comforting...

[CorpTech]

I haven't tried imaging yet, but that is not cool at all.