10.9.1 not universal, Late 2013 Retina Models build 13B3116

[hkim]

Mavericks is still forked, 10.9.1 for Late 2013 Retina models using 13B3116.

ARGH!

[mm2270]

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.

[nkalister]

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

[tkimpton]

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

[nessts]

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?

[donmontalvo]

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

[#7]

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

[analog_kid]

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

[#9]

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

[mattbomarc1]

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.

[ImAMacGuy]

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.

[barnesaw]

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.

[tkimpton]

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

[CasperSally]

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.

[ImAMacGuy]

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.

[donmontalvo]

@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

[tkimpton]

@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

[Chris_Hafner]

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

[Chris_Hafner]

Double Post... weird!

[bkerns]

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!

[nessts]

@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.

[bkerns]

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.

[JPDyson]

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.

[Chris_Hafner]

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.

[Chris_Hafner]

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

[Chris_Hafner]

Tripple... what the heck!

[nessts]

Again the only problem may be that when 10.9.2 comes out it may not install on a non 2013 MBPr that has a build version of 3116 and you wont know that until the day it comes out. My computers that are non-MBPr from this year with 2093 on it do not see the 10.9.1 update, if you try to install the 42 version it says you need to have OS 10.9 installed and if you try to install the 3116 update it says wrong architecture or something like that. The point is neither update runs on the the computers running the 2093 image if they are the wrong hardware. I hope that makes it clear. This could be a one time problem and 10.9.2 may (we can only guess) pull things together. Or maybe Apple has found one more point of control they want to enforce on us by making sure each computer is running the version of OS it should be running. For instance to stop somebody from getting iWork for free on old hardware. Just a guess and unknown if its a problem going forward, but there is probably a reason for what they are doing, beyond just screwing with the enterprise and the things that we find to make things work.

[#28]

It isn't a huge crisis, but it is sloppy and does create some extra work for some.

Also on the annoyance list: both downloads from Apple, the retina specific and the general 10.9.1, have the exact same filename. That is just lazy.

[mm2270]

@nessts][/url Its possible that may be a problem, but that should only apply to the delta update. The Combo updater should install on anything, even if you used a build on it that wasn't really intended for that hardware. That's basically what we'll be doing since we also are using a universal build that boots everything, but isn't the one necessarily intended for each piece of hardware. We block the delta updates on our SUS's anyway, because they generally aren't as safe. So we'll post the Combo in Self Service for users to install when they're ready to do it. But the Combo will be the only update available to them unless they go out of their way to download the delta directly from Apple and install it manually.

I agree that this isn't a major problem, but I still don't give Apple a pass on this, because I feel it was unnecessary to fork it. I gave them a pass on 10.9.0 and the new hardware because the new hardware wasn't officially out at the time of introduction.
But now ,many weeks later they could have unified this. I'm not willing to just let it slide because Apple will continue to do this every time unless we explain to them in concrete terms that this creates extra unnecessary work for us. We're all stretched thin trying to keep up with changes to the OS and hardware. Why should we just accept that Apple makes it harder than necessary?

[donmontalvo]

@JPDyson wrote:

So 13B3116 does boot everything.

Confirmed this yesterday, updated our Deploy Studio Runtime HD image using a Late 2013 MBPr and all updates applied. The USB thumb drive was able to boot old/new model iMacs, MBP/MBPr, Mac minis, etc. I wouldn't create an agnostic BaseOS image, but just confirming it's fine for DeployStudio/NetBoot/etc.

Don

[Munkeee]

arg!!!!

[clifhirtle]

double post.

[clifhirtle]

I think I know the answer to this, but as a general rule, how do you guys handle situations where you do not have that new hardware, but still need to build out an updated monolithic? Dev site still only lists 13A603 as OS X download.

[mm2270]

Well that's kind of the problem isn't it? You can't really get your hands on those special builds unless you have the specific hardware that requires it. Hence why I still contend that Apple not having a universal build is a PITA. In a case like that, you'd probably have to build your NetBoot or base image off of whatever the latest hardware you have, and then know that you'll need to update/rebuild it later once you do get the new hardware in.

There's been a lot of resistance internally here on using a 'no-imaging' approach, but I'm going to use this to push the issue again. I feel like we'll never get off of this crazy roller coaster ride until we give up on trying to create a universal image and just use whatever the Mac ships with.
Of course, that doesn't account for times when a Mac has to be nuked and paved…. ugh.

[nkalister]

yeah, we "thin-image" (though I think gneagle might call it a slim but still fat image, lol) new machines. we leave the shipped os in place, and install our tools onto that.
For reimages, if the OS is forked, we have a config for each fork. Hardware specific installers are captured from Internet Recovery. it's not awesome, but it's not the worst, either.

[Chris_Hafner]

We kind of sit in the middle here. For example, we purchased a new 15" MBPro retina to help combat this, but then the Late 2013 13" MBPro Retina came out. So, we told the user (BYOD here) that we were going to need to keep the computer for a few days for testing before we could deploy it. I know that's not an option for everyone, but it is the easiest way to get a new one. I suppose we could buy a new one and sell the 15" unit on ebay for 80% of the price as well. Oh well...

As for the imaging approach I've used in these circumstances... so. Let's break this out here. I DO customize my base OS packages ALWAYS, but I DO NOT create any sort of monolithic image, nor is it advisable. So, I take said new forked computer. Make the few changes to it that I would make to my Base OS.dmg. Then I boot it form something with Casper Imaging (you can always clone the computer onto an external for these purposes if you have to) and run Casper Imaging minus the OS.dmg. That's essentially the "thin-imaging" approach but you've still got a brand new, nice clean install.

[donmontalvo]

@mm2270][/url wrote:

There's been a lot of resistance internally here on using a 'no-imaging' approach, but I'm going to use this to push the issue again.

"No-imaging" (or whatever it's called) may be the trend, but it's not the end-all, be-all solution for imaging Macs. BaseOS image is still needed if a drive dies, something that happened here recently and it took 6+ hours for Internet Recovery to finish installing Mavericks (YMMV based on [too] many variables).

@nkalister wrote:

For reimages, if the OS is forked, we have a config for each fork. Hardware specific installers are captured from Internet Recovery.

We did that when 10.9.1 dropped, two BaseOS images (one for MBPr and one for non-MBPr), and one DS/NBI using the MBPr flavor. So far so good.

Don

[Chris_Hafner]

Yep! Fortunately its been a while since i ended up with a forked unit that had a total drive failure but it's good to be prepared. Some of you with larger installations probably see this far more often.

P.S. I'll also admit to building .nbi's from developer resources.

[dwsak]

OK, this might be a dumb question, but suppose I wanted to make a separate image for the Retina... how do I even download the installer for the Retina image? When I go to app store to download mavericks (as I did for the new MacBookAirs) it says the update is not applicable to the system.

[clifhirtle]

@dwsak generally you need the actual new hardware for the App Store to allow you to download the branched OS X versions. However I may have just found a way around that...

Can anyone here confirm if 13B42 is the 10.9.0 version that shipped with the new Retina MacBook Pro 15s?