Posted on 12-16-2013 01:35 PM
Mavericks is still forked, 10.9.1 for Late 2013 Retina models using 13B3116.
ARGH!
Posted on 01-21-2014 09:27 AM
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???
Posted on 01-21-2014 09:45 AM
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.
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.
Posted on 01-24-2014 02:58 PM
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
Posted on 01-25-2014 03:58 PM
@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.
Posted on 01-26-2014 05:30 AM
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.
Posted on 01-28-2014 10:23 AM
I'm removing the atto raid ones, old ATI ones and a fee of apples like Bluetooth, DVD, CD etc
Posted on 01-29-2014 10:07 AM
Guys, wouldn't just enrolling the computer with the OS that comes on it be a much better way to tackle this?
Posted on 01-29-2014 11:26 AM
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.
Posted on 01-29-2014 11:32 AM
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.
Posted on 02-17-2014 08:44 AM
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.
Posted on 02-26-2014 11:50 AM
Apple released yesterday 10.9.2... does anyone know if this version unforks 10.9.1?
Posted on 02-26-2014 12:04 PM
My Retina and minis that have updated are all 13C64!
Waiting for the new Pro to show up.
Posted on 02-27-2014 01:35 PM
It seems that it is now an unforked version everything I have updated is now on 13C64.
New: iMac, MacbookPro, Macbook Air
Posted on 02-27-2014 01:36 PM
Combo updater is out, agnostic image now possible. Thank you Apple.
Posted on 02-28-2014 01:58 PM
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.
Posted on 06-19-2014 08:50 AM
@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
Posted on 06-19-2014 10:19 AM
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.
Posted on 06-19-2014 01:57 PM
@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!
Posted on 06-19-2014 02:47 PM
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