Strange JDS and NetBoot block level imaging issue

[chriscollins]

I have a 10.9.1 diskless Netboot image, a 10.9.1 Server configured as both an AFP distribution point, and a JDS for testing purposes.

The issue is when I image with a configuration that has an ASR image and it goes to do a block level copy of the base OS image to the drive, if I choose the JDS version of the distribution as the share point to get data from, the block level copy stops part way through.

After investigating the net boot machine while its doing the block level copy I can see in activity monitor in the Network sent/received that as its pulling down the image its uploading a ton of data (usually about half what it is pulling down, but if its pulling data at 80MB.sec, then its uploading 40MB/sec which is crazy). It's doing this because it's writing some large amount of data to the net boot's root volume which is effectively writing to the shadow file on the server. As its doing this, the net boot's root volume completely fills up after only getting a few gigs into the ASR image writing to the physical hard drive and whatever its caching to the root volume, it causes the imaging to just halt and stop as it stops pulling data down form the JDS because it runs out of room to cache whatever data its caching.

If I pick the AFP version of the share point, I don't see any of this filling of the hard drive, the network sent/sec in Activity Monitor stays normal and the root of the net boot volume is not fill ing up quickly. It runs perfectly fine.

I can reproduce this every time.

Anybody have any ideas?

[bajones]

I have this exact issue, however I have no useful input. I'm interested to see what comes of this.

EDIT: Perhaps I do have useful input... My server is running OS 10.8.5.

[chriscollins · Accepted solution]

Hey bajones, just got a response from JAMF support. Turns out its a known defect in the software (D-005796). So currently a JDS cannot be used as a distribution point for net boot based imaging. They don't have a timetable on a fix at the moment. They suggest using a traditional AFP/SMB share point for the time being. I have the JDS in that particular building set up as both a JDS and an AFP based distribution point and am manually syncing the packages from the JDS directory to the AFP based directory locally on that server to avoid having to re-replicate the packages from our master distribution point in another state. Will be somewhat of a pain but need the automated replication and bandwidth throttling capabilities of the JDS for the initial replication.

[bajones]

Good to know. Seems like that should have been noted in the Known Issues section of the release notes for any of the 9.x releases.

[stevehahn]

Anyone know if there was any resolution to this? I really don't want to have to manually replicate all my stuff to a fileshare...

[Josh_Smith]

Echoing Steve's question above....Does anyone know if a JDS is compatible with NetBoot now? Is a standard file share the preferred distribution point method?

[were_wulff]

@Josh.Smith

This is still an open defect under ID D-007061.

D-005796 was closed out with the fix being to expand the NetBoot image, but as that doesn't always work, Development re-opened it under D-007061. If referencing these to your Technical Account Manager, please use D-007061.

Some users have had luck expanding their NetBoot image to 15, 20, or 25GB, but for some even this hasn't worked and the only way around it at the moment is to use an AFP/SMB file share as the master distribution point.

@stevehahn posted a thread on this topic here, and it's got a few more replies (as well as a couple longer ones from me) that might be useful for you.

Amanda Wulff
JAMF Software Support

[Josh_Smith]

Great, thanks for the quick response Amanda.