10.9.1 not universal, Late 2013 Retina Models build 13B3116

@jthurwood Have you tried holding the OPTION key and selecting the NBI?

When i select the option key Faux Netboot is listed, when i click on it it shows the Apple logo and boots to the Internal HD.

@jthurwood Ahh...maybe start a new thread using the NetSUS tag? I only stumbled onto this thread since I was subscribed. I usually search for tag. :)

Are the NETSUS server and the MBP on the same VLAN? Same IP range? If they are not on same VLAN then you'll need IP Helpers in place on the switch.

Can you NetBoot any other devices using any other NBI sets from that NETSUS?

You mentioned using SIU from a 10.9.1 Server. Have you tried hosting the NBI on that 10.9.1 server temporarily to make sure the NBI is good? I'd put the client and that server on the same subnet, heck the same switch if possible, and try getting the machine to netboot from there. At least you'd be able to tell if the NBI is working.

Ive just tested the NBI on our 10.9.1 Server and it does exactly the same thing, must be something wrong with the NBI???

That's where I'd start. Below is the process I use to create an NBI. All of this is done on the same machine. It is time consuming, and it requires an external drive (or two partitions on the internal), but I've had almost zero problems when doing it this way.

1. Use Internet Recovery to put the machine back to factory, or use a machine that is fresh out of the box.
2. Run thru the system setup process and then run Software Updates until there are no more updates.
3. Boot to Restore and plug in your external drive (or partition your internal).
4. Restore the OS to that external drive (or internal 2nd partition).
5. Run thru system setup process on the external drive (or internal 2nd partition) and run Software Updates until there are no updates.
6. Enable the root user on the external drive (or internal 2nd partition) and login to the root account.
7. Install Casper Imaging and any other utilities that you want.
8. Setup the root user login the way you want it: set the desktop, setup the dock, set Casper Imaging to start at boot and make sure the preferences for Casper Imaging are set.
9. Restart machine and make sure that Casper Imaging launches.
10. OPTIONAL: if you are using a JDS in your environment, open Safari and navigate to your JDS (https://jds.yourdomain.com). You will receive a certificate warning, click Show Certificate and make sure to Trust The Cert.
11. Remove anything from Applications and Utilities that you do not want or need on the system.
12. Boot the machine from the internal drive (the original setup partition).
13. Open a Terminal window and navigate to the /var/vm folder on the external drive (or internal 2nd partition) and remove the contents of the folder (rm -rf *.*).
14. Close the Terminal.
15. Open the CoreServices folder on the internal drive (/System/Library/CoreServices/).
16. Locate SIU and open it.
17. Using the external drive (or internal 2nd partition) as the source, create a new NetBoot image.
18. Upload the NBI folder to your NetBoot server.

I've used that process, or one very similar to it, for the last 5 years and have had very few problems, if any, with my NBI sets. When I do have a problem, it's generally because I've tried to cut a corner somewhere.

You can do a search on JAMFNation for information about slimming down NBI sets and find more stuff you can remove (like the Caches folders and other things).

Give that a try creating a new NBI and let us know if that helps.

10.9.x ones are 35MB so won't TFTP to the older macs. If I remove unused kexts and build the image the kernalcache is under 32MB and EVERYTHING boots !!!!

@Lotusshaney what kexts are you removing? I'd like to test this out

@stevewood that's almost the exact process I use to create a new .nbi. Its worked for almost 4 years now :)

I also now feel more justified in keep a stable of dmgs, 1 for each model that comes through the door.

My netboot runs a script to restore whateveros came with that model and a launchdaemon with quick add pkg. Then it names the drive and reboots. Daemon runs quick add and a Casper policy does the rest.

CI has too many limitations so I abandoned that one long ago, and it seems apple abandoned us long ago with any sort of universal build of anything. Just easier to use ASR to restore whatever build works. New macs come in, get named, and same launchdaemon gets applied. We cut down our imaging time from 45 mins to about 5 this way.

For those concerned that this is a new trend with Apple - I believe this situation happened with both Lion and Mountain Lion as well, where forks still existed after the "x.1" update, most likely because development on these updates begins before the release of the primary "x.0" gold master to the public. I also remember the forks being resolved by the time the "x.2" updates were released.

I'm removing the atto raid ones, old ATI ones and a fee of apples like Bluetooth, DVD, CD etc

Guys, wouldn't just enrolling the computer with the OS that comes on it be a much better way to tackle this?

It is, at least for those of us that have workflows to support that methodology. The issue comes in when that computer has to be reimaged or re-provisioned. What then? Since you have to boot it from SOMETHING that is not the internal drive, whether that be a netboot drive, external thumb drive, etc. you can run into this problem.

If it was easier to customize a recovery partition and use that, this might be a moot discussion. So far I've not heard of anyone that's been able to get a recovery partition to the point where it can run CI, or scripts that use a multitude of different tools, etc. Please correct me if I'm wrong community.

he issue comes in when that computer has to be reimaged or re-provisioned. What then? Since you have to boot it from SOMETHING that is not the internal drive, whether that be a netboot drive, external thumb drive, etc. you can run into this problem.

actually, this is really only a problem for net boot. We use USB boot sticks, the 3116 build without any mods will boot everything off of usb.

Yes! The 2013 Mac Pro build 13B4116 appears to boot all our models. MP/MBPr/MBA/MBP/iMac/Macmini. Good news on the NetBoot/DeployStudio front. Hope to see a combo 10.9.2 update one day.

In the spirit of Bill Maher (re Lance Armstrong & Sheryl Crow), Apple needs to find a way to unfork OS X. Maybe bring OS X patch development back onshore where the competent/capable can clean up the mess.

Apple released yesterday 10.9.2... does anyone know if this version unforks 10.9.1?

My Retina and minis that have updated are all 13C64!

Waiting for the new Pro to show up.

It seems that it is now an unforked version everything I have updated is now on 13C64.

New: iMac, MacbookPro, Macbook Air

Combo updater is out, agnostic image now possible. Thank you Apple.

I had a gut feeling that's how things were going to roll. ;-) If new hardware is released right around when the gold master of a new version of OS X is released, don't expect it to be unified into the update cycle until the x.2 release, because usually the x.1 release is already under development internally before the gold master is released to developers. It seems like they refuse to add new hardware driver support into an OS X update once they start testing the builds internally. That's been the pattern now since Lion was released.

@acdesigntech you have a copy of that netboot script? I am trying to automate my netboot and imaging process so I can assign imaging duties to level 1 techs. I like the idea of new machine comes in, strip what I dont need, and just install applications via policy

I have yet to see a solution that does this as far as booting to a stripped down netboot image. Or did you mean something else? Currently I just rely on our pretty strict policy on models that are purchased and provisioned to shield us from the netboot problems of others.

@wyip has anyone found a solution other than altering the kexts on 10.9 images? I heard TFTP has a new implementation to 4GB. this is such a manual process. UGH!

Unless Apple fixes the firmware in the affected Macs or fixes system image utility to be more selective when making the kernelcache there is not much we can do apart from slim the kernelcache after the .nbi folder has been made