Skip to main content

Until recently, we have been using Mac mini servers with Lion installed on them as our Casper Imaging stations. We could NetBoot over USB and image without issue, aside from occasionally long boot times on Thunderbolt machines. However, when we upgraded one of our minis to 10.8, we began to have issues with Casper Imaging.

Our configuration was set up to run a shell script which would use command-line tools to perform a block copy of our selected image to our Macs. It worked without issue on all of our machines, be they MacBooks, MacBook Airs, or iMacs. However, after the upgrade, the shell script would occasionally be skipped by Casper Imaging and it would jump directly to the second item in the configuration. It would finish installing the other items in the configuration and reboot, as normal. However, due to the script being skipped the computer had not actually been imaged at all.

As a test, I created a new configuration that simply used Casper Imaging to perform the block copy (the script was no longer necessary for our workflow, anyway). However, Casper Imaging will still skip the block copy occasionally (my last test resulted in 2 failures out of 7 machines) and move on to the next item in the configuration. It also throws up an error about a NilObject and then crashes the Casper Imaging interface.

It seems to me as though the Mac mini may suffer from some sort of communication issue with the computer we are imaging due to a change in AFP in 10.8, but I must admit that I'm simply guessing. We have a second mini that has also been upgraded to 10.8 and it suffers the same fate. They both also occasionally fail to NetBoot computers. This seems to be more prevalent when we try to NetBoot 10 or more machines at once.

Has anyone else experienced this issue? My mini was set up from scratch as a Mountain Lion machine and the previous one was upgraded from Lion. Any thoughts?

I suspect you might be running into the issue were the Netboot isn't really using diskless mode and so it can't format the internal hard drive, hence appearing like it skipping the first step.

Here's one way to test: Netboot any number of Macs. Try to drag the internal HD to the trash to see if they can be unmounted. If they can't, then it's because the shadow file is being stored on the internal drive and not diskless.

I wasn't experiencing this issue with our 10.7 and 10.8, but then at some point it started happening. So I had to implement the RAM disk instructions as has been mentioned by others.

Check out: https://jamfnation.jamfsoftware.com/discussion.html?id=5544

They reference these instructions: http://www.macos.utah.edu/documentation/administration/setup_netboot_service_on_mac_os_x_10.6.x_client.x_client/setup_netboot_service_on_mac_os_x_10.6.x_client-diskless_netboot.html

You can read though it all and follow the steps to edit the rc.netboot yourself. Or the short cut is to download their edited "rc.netboot" file that's prepared for you. That same file works for our 10.8, 10.7, and 10.6 netboot images.

From my experience, although it's related to Diskless not being recognized, it had more to do with the fact that NetBootClient0 was not being shared properly and thus the cache wasn't being written to it causing Netboot to crash.

My fix was to clear out the contents of NetBootClientsX Turn off Netboot. Turn off File Sharing. Delete the Netboot shares listed. Turn on File Sharing. Turn on Netboot. The shares should recreate themselves automatically. Try to run Netboot again.

This happened once in a while in 10.7, but it's more of a problem in 10.8.

Thanks for your help. jhalvorson's response totally fixed it. I just forgot to come back and say anything until now. :-D

Terms & ConditionsCookie settingsAccessibility statement