Yosemite image on new machines, require disk repair?

irod87
New Contributor

So I have 105 new macbook pro's I am setting up. I pulled one out of the box. Set it up with apps,binding,printers,settings etc. I then target booted it to my imac and launched composer. I then created a new base image and captured the macbook hard drive. I then loaded it to casper admin. Categorized it as a Base Image with a priority of 1. At this point all should be ready.

I opened a second machine never booted and did a netboot to Casper. Chose the base image I made and chose to erase the current HD. The process goes through but after reboot I get a circle with a line through it. I was able to 'fix' this by going to internet recovery and running disk utility. I then ran a permission repair and a disk repair and reboot. It then restarted to my working image.

Where did I mess up?

2 ACCEPTED SOLUTIONS

RobertHammen
Valued Contributor II

What version of Casper Suite are you running? Strongly suggest Casper Imaging 9.65 with 10.10.2 and later.

Might also be an issue with the older NetBoot image. I try to image like OS from like OS, i.e. Mavericks with Mavericks, Yosemite with Yosemite.

View solution in original post

bentoms
Release Candidate Programs Tester

@irod87 9.64 was pulled due to many issues, better update to 9.65 ASAP

View solution in original post

16 REPLIES 16

kilodelta
New Contributor III

Generally, when I've seen this happen, it's because Casper Imaging has been unable to perform a block copy or ASR image restore, and has reverted to a file-by-file copy - which breaks permissions.

So, that raises a few questions:
- What version of Mac OS is your Netboot based on
- What kind of distribution point are you imaging from
- When imaging, does Casper Imaging say it's doing a block copy for the OS, or that it's installing a package?

irod87
New Contributor

My netboot is running on Mavericks while my installs are Yosemite.

My distribution point is a local server

Casper says its doing a block copy.

If I choose to repair the permission options in Casper Imaging will this help?

irod87
New Contributor

Anyone have any suggestions for me to try?

RobertHammen
Valued Contributor II

What version of Casper Suite are you running? Strongly suggest Casper Imaging 9.65 with 10.10.2 and later.

Might also be an issue with the older NetBoot image. I try to image like OS from like OS, i.e. Mavericks with Mavericks, Yosemite with Yosemite.

irod87
New Contributor

Looks like im using 9.64. I think im going to try and make the upgrade to Yosemite on my Netboot to see if that helps.

tnielsen
Valued Contributor

May I make a suggestion and create a thin-imaging process for this. Leave the OS that comes with the computer on there and apply packages ontop of it.

bentoms
Release Candidate Programs Tester

@irod87 9.64 was pulled due to many issues, better update to 9.65 ASAP

irod87
New Contributor

I will update to 9.65 first since that a quick check. I normally do thin imaging. I may try that as I continue to work through the pile. Thanks

irod87
New Contributor

@bentoms You hit the nail on the head. I upgraded to 9.65 and imaged a batch and they worked as intended. It was that buggy 9.64.

yancyg
New Contributor

We have a similar issue with a new set of 40 MBP imaged with 9.64 composer - we are working on a new image with 9.65 on a JSS installed on 10.8.5 OSX server. Work on our older MBP, but not the new MBP.

bloree
New Contributor II

@RobertHammen

Strongly suggest Casper Imaging 9.65 with 10.10.2 and later.

Just curious. Did I miss a fix or workaround? I thought 10.10.2 had the issue of not block copying. Because of this, all of our NetBoots are running on 10.10.1 which is starting to be a PITA with new hardware coming in pre-imaged with a 10.10.2 supplemental build.

RobertHammen
Valued Contributor II

@Loree Yes you did, you can most definitely block-copy 10.10.2 when booted from a 10.10.2 NetBoot image if you're using Casper Imaging 9.65. I just did 100+ machines for a client last week. Also, have another client using 9.65, even though their JSS is still 9.63. Works fine, the jamf binary is downgraded after enrollment.

JPDyson
Valued Contributor

Just affirming the 9.65/10.10.2 fix - seems to solve this issue for me. I was getting everything owned by 99 instead of 0 on the destination drive, and while a repair would "fix" it, a Recovery partition wasn't created as a result. No issues since 9.65 & 10.10.2.

RobertHammen
Valued Contributor II

Yep, a side effect of the file-by-file copy instead of block copy = no Recovery Partition.

LRZ_Jamf
Contributor

FYI: I've seen this happening with 9.62 and 10.10.0(+2Updates) built with AutoDMG and AutoCasperNBI.
I can't say if it happens again with 9.65 but i'll test it within the next few weeks :)

Okay just seen 9.7 comin ;) Gotta do it with that then :)

RobertHammen
Valued Contributor II

Watch out, if you use http distribution points, and have packages with spaces in the names, 9.7 seems to not deal well with them. 9.65 has some issues with mounting distribution points. And 9.64 was buggy and pulled by JAMF.

You can use the 9.65 Imaging app with an older version of the JSS; I have more than one client using this approach, meaning they can image 10.10.x clients but don't have to upgrade the JSS due to possible issues.