Fontd Crippling Imaging Process

[bse_college]

Hi everyone,

I have just started imaging my school's fleet of 440 MacBook Airs through Netboot imaging and the imaging speed is maxing out at 15MB/s. When I open Activity Monitor I see that the process 'fontd' is writing between 30-40GB of data to the drive of each device during the block copy of our DMG. Our DMG is 37GB and the machines are writing at leat 70GB in total prior to the reboot at the end of the Casper Imaging workflow.

If I manually kill the fontd and fontworker processes the imaging speed immediately jumps back to normal (i.e. at least 80MB/s).

Our Netboot image is made with AutoCasperNBI with no customisations whatsoever so I really don't understand what could be causing fontd to be going crazy or initiating at all.

Please help!

[djdavetrouble]

Hey man, I had weird issues like this, and it was because permissions somehow were funky on the nbi. I had made it on a dev box, and copied around via afp to different netboot servers. I ended up rolling a new nbi on the machine I was serving it from, since I was unsure of which step was messing it up. The issue cleared right up.

[sdagley]

@bse_college Not that I have an answer for the fontd issue, but is there any reason you're not using Target Mode Imaging in Casper Imaging to image your MacBook Airs via Thunderbolt? If you're running Casper Imaging from an MBA with a local copy of your Distribution Point the imaging performance over Thunderbolt should be much better than via NetBoot over ethernet.

[bse_college]

@sdagley Our Apple Consultant said that our network infrastructure and JDS are 'incredible' and so there would be little if any difference in doing so. We have other tasks that we need at the same time so there is certainly not any wasted time.

[bse_college]

@djdavetrouble How did you fix the funky permissions? We have used the same netboot image for 2 years flawlessly and the issue has only just arisen.

[sdagley · Accepted solution]

@bse_college Not to disagree with your Apple Consultant, but simple math would indicate that imaging a MacBook Air from another MacBook Air connected via 20Gb/s Thunderbolt could be much faster than Netboot imaging a MacBook Air connected via a 1Gb/s Ethernet. It's a little dated now, being pre-Thunderbolt 2 and referencing USB Ethernet adapters, but Apple even published a White Paper recommending Thunderbolt imaging for MacBook Air deployments: Imaging the MacBook Air Leveraging Thunderbolt

I'm moving away from a monolithic image deployment, but when I did my school's 1200 MacBook Airs last summer with an image around the same size as yours it was taking approximately 4.5 minutes to write the image to the target MacBook Air. Note that I was using DeployStudio to do the imaging, binding to Casper occurred as part of the DeployStudio cleanup script on first boot (along with machine naming, and binding to AD) which itself takes about 5 minutes. Since I image all my machines by myself I wanted a workflow that ran as fast as possible, and this was it.

Not that you have to abandon Netboot imaging, I'm just saying that until the Imagepocalypse that @rtrouton recently wrote about happens, you might want to look at alternatives if you'd like imaging to go faster.