10.9.1 not universal, Late 2013 Retina Models build 13B3116

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.

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.

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

@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

arg!!!!

double post.

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.

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.

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.

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.

@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

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.

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.

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

@dwsak][/url][/url We downloaded the machine specific installer on the Late 2013 MacBook Pro Retina. For the non-Retina installer, we used a non-Retina model to do the same. Then it's all AutoDMG...of course the same applies, run it on the MBPr for an image that will work with MBPr, and run it on non-MBPr for an image that will work with all other models.

https://github.com/MagerValp/AutoDMG/releases

FWIW, the MBPr booted all the Macs we tested on (iMac/MP/MBPr/non-MBPr/Macmini) so fine for NBIs and DS Runtime HDs. For those times when "no-image" (or whatever the politically correct term is now for imaging without touching the OS) is not an option, we would deploy MBPr for that model, and the non-MBPr image for all other models.

Don

@clifhirtle

I have the new hardware (late 2013 MBP Retina), but app store still says that Maverics is does not apply to that hardware. System already has Maverics but I want the installer (installESD) so I can build an image for it. Downloading from the app store works for other models. Up until now I was always building one image for all models, this is the first time I've run into this problem.

Also, FYI, 13B42 is what I have on my test late 2013 MacBookAir and my external drive, it won't book the MBP Retina

@clifhirtle: No, the MBP (Retina, 15-inch, Late 2013) shipped with a forked build of 10.9.0 just for that model: 13A3017.

@dwsak][/url][/url I believe you have to first download Mavericks and then that Apple ID should display Mavericks going forward on your other Macs. At least that's been the case here.

EDIT: OK, so it looks like the Install OS X Mavericks.app that was on the newest MBPr was actually copied off a non-MBPr model. My apologies for the bad assumption. I tested again on a new MBPr and previous posters were right, you get an error when trying to download Install OS X Mavericks.app from the Mac App Store. Since AutoDMG requires the non-existing MBPr Install OS X Mavericks.app, we're going to make an MBPr image using JAMF's article ([https://jamfnation.jamfsoftware.com/article.html?id=313), the old school way. Thanks Apple.
Don

@donmontalvo when I try to follow the process in that article you mention, it still won't install. It says 'OS X Mavericks cannot be installed on this computer'. I think there must be 2 separate versions of 'Install OS X Mavericks.app', and I can't seem to get a copy of the one that works for the MBP Retina.

I can confirm what @bkerns noted, that 13B42 upgrades to 13B3116 through SW update. And if what @JPDyson reports about 13B3116 universally booting is correct, the following may be a moot point, however:

I can also confirm that hacking a few VMWare Fusion config files appears to permit faking a late 2013 MacBook Pro enough to nix the need for procuring new hardware every time Apple branches its OS code.

@dwsak Yep I updated my post earlier today. :)

10.9 is fork in two builds for macbook pro retina 13 inch 13A2093 and 15 inch 13A3017.Now is 13B3116 for 13 inch and 15 inch , Apple is advancing

@donmontalvo: "Since AutoDMG requires the non-existing MBPr Install OS X Mavericks.app,"

Actually, the latest versions of AutoDMG will also take an InstallESD.dmg file instead of an "Install OS X" app. This means that you just need to capture the 13B3116 InstallESD.dmg file from a Retina MBP using Internet Recovery, and then you can use that. Very convenient. (Okay, not very convenient, but it's somewhat more convenient than other methods, like the one that you outlined above.)

@clifhirtle: "hacking a few VMWare Fusion config files appears to permit faking a late 2013 MacBook Pro" – I'd be very interested in learning more about this. Did you use instructions like these? – http://www.insanelymac.com/forum/topic/292170-how-to-spoof-real-mac-in-vmware/

I also just noticed that Casper Admin won't run on build 13B3116, it says 'requires Mac OS X 10.4 or later'. I guess we're not the only ones blind-sided by the multiple versions of 10.9.1.

Going forward, it sounds like Internet Recovery is going to be the only official way to re-image. I kind of saw this coming but it looks like the new hardware released after 10.9 is Apple's final stake in the ground. I imagine some scientist stuck in a research outpost Antarctica trying to do an internet recovery over some slow satellite connection. I guess they should switch to PCs.

Sounds like I really need to look into AutoDMG, I'm still using Composer. (Supporting Apples is only supposed to be a fraction of my job, I've been trying to just stay with what's worked in the past, not a whole lot of time to explore all the other options...)

what version of admin is that dwsak? 8.73 is running on 3116 for me, so is 9.22.