Imaging 9.22 Runs Past Packages and Tries to Restart

[mcrispin]

Running 9.22 with Mavericks Netboot 10.9.1 w/ RAM Disk "hack", testing with multiple mac (not the forked Retina), NetBoot is not built from the fork, but the common 10.9.1, Casper Imaging in 9.22, distribution point is connected via AFP on an HFS+ file share, a few things we noticed:

1. "Erase Hard Drive" doesn't.
2. Base Install gets applied, then at a random point in the configuration, Casper Imaging will just start running through the rest of the packages without installing, then try to restart the machine. No consistency as to when this starts, some DMGs get applied then one "breaks" and the rest fail.

Casper doesn't think anything has failed, the logs show nothing. Console logs are also providing no information on the client. Netboot itself has been flushed / restarted. Cannot duplicate with previous Netboot from Casper 9.1 under Mountain Lion (which also has RAM disk hack).

So using the ML (10.8.5) netboot works, Mavericks doesn't. Definitely understand this could be an Apple issue and not Casper. Simply wondering if anyone has seen this behavior before and trying to get clue to perform further regression. Using a different distribution point yields same results in both cases.

Anyone seen this?

[jhalvorson]

Yes, I have seen this. In my case, it was because the "Erase Hard Drive" option was failing when we were reimaging existing Macs that had FileVault2 enabled. All new system worked fine and their hard drive could be erased via Casper Imaging. The solution for imaging systems with FileVault2 enable has been added a script to the desktop of the NetBoot image. I posted the script here: https://jamfnation.jamfsoftware.com/discussion.html?id=5763 Once the drive has been 'nuked and paved' via the script, we still select the option to "Erase Hard Drive" within Casper Imaging. It's probably not necessary, but I want our techs to make it a habit.

[mcrispin]

Good catch, unfortunately, none of the machines showing this behavior have FV2 enabled. Appreciate the feedback though.

[jhalvorson]

When the device is net booted, are you able eject the internal hard drive? If the Netboot OS is not able to release the internal HD, then operations like erasing the HD will fail.

If the disk can't be ejected then either diskless mode or the RAM disk isn't working properly. Another issue I have seen is some of my net boot images will insist on running spotlight indexing and I think that gets in the way of erasing the drive.

[mcrispin]

Spotlight indexing has been disabled, as much as it can be.

The HD can be ejected manually without problem, however we see an intermittent issue where the erase disk function doesn't do its job, though the base install copy seems to proceed at a pace that would suggest it is working as expected.

[russeller]

Have you tried looking at the free space in the net boot image? I'm not sure, but you may need to expand the netboot disk image. Something like this...

$ hdiutil resize -size 20g /path/to/netboot/netboot.dmg

I'm not sure if this is true, that Casper Imaging could be caching packages during imaging process. Can you watch the Netboot disk size during imaging and see if it is getting to 0 bytes when it fails?

[clrlmiller]

Under 10.8 Server's Tool "System Image Utility" the NetBoot image is barely enough size to load and would often run out of space for virtual memory. This often caused our Imaging process to fail midway through when running 10.8 as the NetBoot OS. 10.7 didn't have this issue and I don't know yet about 10.9

I've used these following three steps to expand the NetBoot.dmg file produced by 10.8. This resolved any issues with the NetBoot image running out of space for virtual memory and Imaging worked through without problems afterwards. It's not my work but I thought I'd share. Pay attention to the names of the Images produced and be sure to revert the new, edited Image to the original filename prior to use.

Convert images to read-write with:
hdiutil convert Image.dmg -format UDSP -o Image.rw.dmg

Resize partitions with:
hdiutil resize -size 50g Image.rw.dmg

Convert back to read-only with:
hdiutil convert Image.rw.dmg -format UDRO -o Image.dmg

The solution is originally from here: https://discussions.apple.com/thread/4604107?start=0&tstart=0

[mcrispin]

Thanks for all the replies - I do in fact increase the size of the NetBoot for this very reason in the same exact manner as @clrlmiller mentioned.

As much as I have been able to regress the problem, it would appear the U Utah RAMDisk hack might be the culprit. I have temporarily removed in from our standard NetBoot set and have no been able to duplicate the problem with any consistency. We're going to let this exist for a couple of weeks and see where we are.

Thanks again to everyone.