10.9.1 not universal, Late 2013 Retina Models build 13B3116

I've given up on Apple. I'm becoming convinced they keep the OS forked to annoy us, but would never admit it.

Honestly this is simply becoming lazy programming on Apple's part. I find it impossible to believe they couldn't roll the same changes into the Combo updater. Apple has smart people. They can figure this out.

especially since all the dev builds of 10.9.1 were universal. worst christmas present ever, apple.

Maybe they started Christmas early and thought people can wait until 10.9.2 :(

oh just for fun, if you used say the 13A2093 build on a 2012 MBPr or MBA when you may get the following:

sudo installer -target / -pkg /Volumes/WIP/BaseUpdates/OSXUpd10.9.1.pkg installer: Cannot install on volume / because it is disabled.
installer: This update requires OS X version 10.9 or later.

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.9
BuildVersion: 13A2093

Although it did install on my 2012 13" MBP with the same image on it. Who knows what kind of stupid choice I made by using that image. :)

Software update does not see an OS X update available either... Oh and the Generic build version is 13B42 which is different than the last seed we tested, whats the point of the seed program?

This is what Apple gets for offshoring their updates. Ugh.

http://www.apple.com/feedback/macosx.html </obligatory>

This is most definitely disappointing, though has happened at least once in the past.

Link to the Late 2013 rMBP-specific update: http://support.apple.com/kb/DL1712

OS X Mavericks 10.9.1 Update for MacBook Pro with Retina Display (Late 2013)

This update is recommended for all 13-inch and 15-inch MacBook Pro with Retina Display (Late 2013) systems. It includes all updates from OS X Mavericks 10.9.1 plus system specific enhancements to improve the stability and compatibility of your Mac.

Improved support for Gmail in OS X Mail, and fixes for users with custom Gmail settings
Improves the reliability of Smart Mailboxes and search in Mail
Fixes an issue that prevented contact groups from working properly in Mail
Resolves an issue that prevented VoiceOver from speaking sentences that contain emoji
Updates Shared Links periodically when open in the Safari Sidebar
For detailed information about this update, please visit: http://support.apple.com/kb/HT6065

This was a great way to end my Monday around 4:30. Way to go Apple. I hope everyone takes a few minutes and leaves some feedback like I just did.

Thanks for the heads up, I was looking forward to this patch to unify (dare I say even excited to get to work this morning because of it)... (geez I am a nerd). Feedback submitted, and I will also let my Apple Rep know how displeased we are.

Having some trouble figuring out why this is such an existential crisis, really. I just added both to Casper Admin and set the "Install only if available in Software Update" flag. We all had a basic 10.9 installer already, right?

Sure, if you're trying to do monolithic imaging it's a bit of a deal-breaker (maybe more of a deal-bruiser), but hardly a reason to lose your cool and professionalism over.

@barnesaw i agree, i think ive spread the tetchiness :(

I wouldn't say it's an "existential crisis" but I totally agree it's "lazy programming on Apple's part" but nothing is stopping them from getting away with it.. unfortunately.

It's a time dump, multiple netboot images, syncing across multiple servers. I was/am implementing some geektools into it, so I now have to do that work twice for the NBIs. Testing thoroughly two nbi's and two base images; the syncing across to our overseas server is an exercise in patience (often taking 48-72hrs for a single netboot image, assuming no hiccups that cause me to start over) to which with forked images, now has to be completed twice. The JDS will at least replicate the base image over.

Is it the end of the world? No, but it still is doubling the workload going into the holidays.

I think most people are just frustrated and this is seen as a safe place to vent.

@jwojda][/url][/url][/url wrote:

I think most people are just frustrated and this is seen as a safe place to vent.

Yeap, Apple needs to hear it, so it helps to submit feedback, post in forums, Twitter, mailing lists and IRCs.

http://www.apple.com/feedback/macosx.html
http://www.macenterprise.org/mailing-list
http://osx.michaellynn.org/freenode-osx-server/
https://devforums.apple.com/community/mac
https://twitter.com/AAPL_PR

Don

@donmontalvo you absolutley right..just hard to get motivated after a stressful exchange upgrade with the jss going down 4 times a day :(

Will make a last push to make a proper effort before I hit the Gin

Well... because I am a glutton for punishment; I do prefer to have a universal .nbi and a mostly universal base OS package. For this one, I've decided that I'm going to make a universal .nbi just because. There are plenty of great ways NOT to have to do this. Nor is there a huge need (as .nbi's can be created easily for any model of mac and just as easily, automatically assigned to such a group). So please understand that I've created a universal 10.9.1 .nbi with Casper Imaging 9.22.

FYI, just verified. My new nbi universally boots all mac's capable of running ANY form of 10.9

OK, so I kind of cheated. I took a 2013 late MBPro retina (13") with a fresh OS. Applied the new 10.9.1 update. Took a 2012 13" MacBook Pro (non-retina) running a base for my .nbi. Upgraded that one to it's version of 10.9.1 Then I cheated. I put the 2012 MBPro into target disk mode, and applied the 10.9.1 RETINA upgrade to the 2012 MBPro via the 2013 retina. (I hope I haven't been confusing).

Since the retina 10.9.1. update supposedly includes all the 10.9.1 stuff plus the additional bits for the retina I figured that this would work and it does. FYI

Double Post... weird!

We used AutoDMG 1.2.1 with the 13B42 base, and applied the MBP update package (http://support.apple.com/kb/DL1712) as an "Additional package". This resulted in a vanilla 10.9.1 image that can boot universally. Just thought I'd put it out there that this was successful for us in case it helps anyone else!

@bkerns what build version do you wind up with?
I am finding that using the 2093 build version on the wrong hardware prevents either of the current updates from being able to install on non-13"MBPr that it should be on. Future updates may not be so restrictive or they may not, since we have no communications about this, I would suggest living in the forked up world.

It does end up reporting as the 13B3116 build, which I would expect. Thats good info to have. I'll have to do some checking on how the updates work/don't work.

So 13B3116 does boot everything. This doesn't change too much; consider your scenarios:

In Place Upgrade (10.8-10.9): You're not concerned with the Late 2013 models (which require 10.9 anyway). So an in-place upgrade package can still be built around 13B42 if you want to go straight to 10.9.1 with a single package.

Re-Image/Break-Fix: Your base for re-images can be 13B3116; this boots anything that Mavericks will boot (it's only the installer that does a pre-req check); again, straight to 10.9.1, single image.

Update (10.9-10.9.1): Your SUS will handle which update to apply for clients already running 10.9. This is only troublesome for cases where you manually push such updates via Policy, in which case you have some (mildly annoying) scoping to do.

Now, the one situation I don't deal with currently is NetBoot; however, as has been pointed out, 13B3116 should still boot everything in site.

I might be missing something here, but on paper I don't see a huge hurdle. More of a nag.

I agree. I don't see it as a huge problem at all. It's just annoying. Honestly, I tend to like figuring out ways to solve things that annoy people even if it's not that important. You're quite correct, though, in regards to dealing with the forked OSs.

Doubled... again. I'm doing something funny here.

Tripple... what the heck!