Skip to main content

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.

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.


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


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


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.


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


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.


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.


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.


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


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


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,


I can't do target mode imaging.


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.


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.


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


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


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?


yeah reported to JAMF


@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?)


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.


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.


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.


@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


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


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